6 ms·

A rule of thumb:If you see "faster than C" claims its either poor C or they use different code path/algorithm thats not equivalent to C code. A FFI that is fa

A rule of thumb:If you see "faster than C" claims its either poor C or they use different code path/algorithm thats not equivalent to C code. A FFI that is faster than native, isn't FFI but some other mechanism that more direct - in this case bypassing the address of the function resolution. 'static inline' is of course even faster. The only C overhead i recall that is legit is libc startup time with glibc, and you can use faster libc alternatives.

gaius 8y ago
Unless it is FORTRAN obviously
- Noughmad 8y ago
  FORTRAN is only faster than C because it doesn't allow aliasing. Use the `restrict` keyword in C and you should get FORTRAN-like performance.
  - ArneBab 8y ago
    Fortran can give you much better speed at comparable code-complexity, as long as your problem is one which FORTRAN is optimized for, i.e. multidimensional array manipulation or numerical work.
baruchthescribe 8y ago
Another rule of thumb: if you see "faster than C" and the article mentions LuaJIT, then it's correct.
cryptonector 8y ago
TFA is not really about C either. Nor is it about Lua. It's about static vs. dynamic linking and nothing more. It's just irritating and click-baity.
BeeOnRope 8y ago
How is the example in this article and the article is based on not equivalent to the C functionality? Yes, the JIT is able to take advantage of runtime code generation to embed the final loaded address in the compiled assembly, which is something C _cannot do_ or at least does not do in its default configuration to support PIC, symbol interposition and other features. JITs can have all the same support, but because of runtime code generation (which comes with its own costs) the final call-site can be more efficient. So it's a reasonable rule of thumb, but it has plenty of exceptions. Other examples include JITs creating code optimized to the runtime-observed data distribution and JITs efficiently using specific hardware features of the current hardware rather than statically compiling in lowest-common-denominator or trying to use runtime dispatch.

gaius 8y ago

Unless it is FORTRAN obviously

Noughmad 8y ago
FORTRAN is only faster than C because it doesn't allow aliasing. Use the `restrict` keyword in C and you should get FORTRAN-like performance.
- ArneBab 8y ago
  Fortran can give you much better speed at comparable code-complexity, as long as your problem is one which FORTRAN is optimized for, i.e. multidimensional array manipulation or numerical work.

baruchthescribe 8y ago

Another rule of thumb: if you see "faster than C" and the article mentions LuaJIT, then it's correct.

cryptonector 8y ago

TFA is not really about C either. Nor is it about Lua. It's about static vs. dynamic linking and nothing more. It's just irritating and click-baity.

BeeOnRope 8y ago

How is the example in this article and the article is based on not equivalent to the C functionality? Yes, the JIT is able to take advantage of runtime code generation to embed the final loaded address in the compiled assembly, which is something C _cannot do_ or at least does not do in its default configuration to support PIC, symbol interposition and other features. JITs can have all the same support, but because of runtime code generation (which comes with its own costs) the final call-site can be more efficient. So it's a reasonable rule of thumb, but it has plenty of exceptions. Other examples include JITs creating code optimized to the runtime-observed data distribution and JITs efficiently using specific hardware features of the current hardware rather than statically compiling in lowest-common-denominator or trying to use runtime dispatch.