Hacker News Reader

Comment by FrozenVoid | Hacker News Reader

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.

View on HN

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

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.

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.

Unless it is FORTRAN obviously

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.

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.

Reply on news.ycombinator.com