3 ms·

Thank you, I kept waiting for a chart or some numbers that never came. Per usual, we are talking about orders of magnitude difference compared to actually high

Thank you, I kept waiting for a chart or some numbers that never came. Per usual, we are talking about orders of magnitude difference compared to actually high performing code. Another word for that is "slow". Just worlds apart in expectations. Of course the lesson is when it comes to performance, it's extremely hard to make up with tuning what you lose in language design. You can optimize the work all you want but nothing beats designing it so that you don't have to do a good chunk of it in the first place.

Rochus 1y ago
I was actually surprised to see nearly a factor ten between C99 and LuaJIT. In previous measurements (on x86, see e.g. https://github.com/rochus-keller/Are-we-fast-yet/blob/main/Luon/Results.pdf https://github.com/rochus-keller/Are-we-fast-yet/blob/main/L...) there was rather a factor five. So either GCC 12.2 produces much faster code than GCC 4.8, or LuaJIT 2.1 got much slower, or the C99 version of Are-we-fast-yet is much better supported by the CPU cache of the T480 than my previous EliteBook 2530. I don't think that the x86 vs x86_64 makes such a difference (at least I didn't observe this in many other experiments).
pushcx 1y ago
Asking as a newbie in this area, could you share any pointers to language design for performance? I'm aware of the early difference between compiled and interpreted languages. Luau has to be interpreted to meet its security goals, and I'm asking with similar goals in mind, so I guess I'm starting from that significant limitation.
- __s 1y ago
  Lua gets sone perf with simple types that can represent lots of types without pointers easily. Truthiness is also fast since only nil/false singletons are falsy. Whereas Python has ´__bool__´. But look at metatable stuff for how much lua has to check All of these introduce guards in with JIT or inline cache, preferable to have no guard at all This isn't unique to dynamic languages, see C++ map having a layer of indirection forced to support pointer lifetimes of access living past inserts. Whereas Rust doesn't allow borrowing past that, & Go doesn't allow taking address of map value Other examples: C optimizations having to worry about pointer aliasing. Or Go interfaces having to box everything. It used to have small value types be able to avoid boxing for interface value, but dropped when switching to precise GC
- deleted 1y ago
  [deleted]

Rochus 1y ago

I was actually surprised to see nearly a factor ten between C99 and LuaJIT. In previous measurements (on x86, see e.g. https://github.com/rochus-keller/Are-we-fast-yet/blob/main/Luon/Results.pdf https://github.com/rochus-keller/Are-we-fast-yet/blob/main/L...) there was rather a factor five. So either GCC 12.2 produces much faster code than GCC 4.8, or LuaJIT 2.1 got much slower, or the C99 version of Are-we-fast-yet is much better supported by the CPU cache of the T480 than my previous EliteBook 2530. I don't think that the x86 vs x86_64 makes such a difference (at least I didn't observe this in many other experiments).

pushcx 1y ago

Asking as a newbie in this area, could you share any pointers to language design for performance? I'm aware of the early difference between compiled and interpreted languages. Luau has to be interpreted to meet its security goals, and I'm asking with similar goals in mind, so I guess I'm starting from that significant limitation.

__s 1y ago
Lua gets sone perf with simple types that can represent lots of types without pointers easily. Truthiness is also fast since only nil/false singletons are falsy. Whereas Python has ´__bool__´. But look at metatable stuff for how much lua has to check All of these introduce guards in with JIT or inline cache, preferable to have no guard at all This isn't unique to dynamic languages, see C++ map having a layer of indirection forced to support pointer lifetimes of access living past inserts. Whereas Rust doesn't allow borrowing past that, & Go doesn't allow taking address of map value Other examples: C optimizations having to worry about pointer aliasing. Or Go interfaces having to box everything. It used to have small value types be able to avoid boxing for interface value, but dropped when switching to precise GC
deleted 1y ago
[deleted]