5 ms·

The point of a tracing JIT is that it runs code in an interpreter, then generates machine code for loops and hot spots. By doing this at runtime you can take ad

by shawn 8y ago

The point of a tracing JIT is that it runs code in an interpreter, then generates machine code for loops and hot spots. By doing this at runtime you can take advantage of knowledge that a C compiler doesn't have. This is why LuaJIT is often faster than C.

learc83 8y ago
>This is why LuaJIT is often faster than C LuaJIT can be faster than C for some code. Just like C can be faster than someone's naive hand coded assembly. That doesn't change the fact that in the general case C is still faster, and there are classes of critical high performance code that have to be written in C (or Assembly, Rust, or even Fortran). Sometimes, manual memory management is necessary to get acceptable performance (also determinism is occasionally required). All else being equal, GC is always going to be slower than non-GC because a GC introduces unavoidable overhead. I've worked in this space btw and I've never seen any evidence that LuaJIT is actually faster than C for anything outside of very specific micro-benchmarks.
- shawn 8y ago
  What benchmark would convince you? It's easy to dismiss any evidence as a very-specific micro benchmark.
  - learc83 8y ago
    Multiple large programs written in LuaJIT that have better performance than the same programs written in optimized C. The vast majority of benchmarks I've seen are down to LuaJIT performing specific optimizations out of the box that the C compiler used in the comparison can perform but doesn't. In particular the last time I looked at LuaJIT vs C++ benchmarks, the C++ compiler flags weren't set allow the use of SIMD instructions by default, but LuaJIT does. There was another recent example I saw where LuaJIT was calling C functions faster than C in a benchmark. Then someone pointed out what the LuaJIT interpreter was actually doing, and how to implement the same speed up in C. Java people made the same arguments years ago: "Java is just as fast or faster than C++". You'll notice that after 20 years of comparisons, no one who writes high performance code for a living makes that claim.
    - shawn 8y ago
      Java is just as fast or faster than C++ most of the time. No one who writes high performance code for a living makes that claim. It's true though. https://lmax-exchange.github.io/disruptor/files/Disruptor-1.0.pdf https://lmax-exchange.github.io/disruptor/files/Disruptor-1....
      - learc83 8y ago
        Java is fast enough that the increased programmer productivity of the GC and other features wins out in many cases. People aren't choosing Java over C++ because it results in generally more performant code. How many AAA game engines are written in Java?

by shawn 8y ago

learc83 8y ago

>This is why LuaJIT is often faster than C LuaJIT can be faster than C for some code. Just like C can be faster than someone's naive hand coded assembly. That doesn't change the fact that in the general case C is still faster, and there are classes of critical high performance code that have to be written in C (or Assembly, Rust, or even Fortran). Sometimes, manual memory management is necessary to get acceptable performance (also determinism is occasionally required). All else being equal, GC is always going to be slower than non-GC because a GC introduces unavoidable overhead. I've worked in this space btw and I've never seen any evidence that LuaJIT is actually faster than C for anything outside of very specific micro-benchmarks.

shawn 8y ago
What benchmark would convince you? It's easy to dismiss any evidence as a very-specific micro benchmark.
- learc83 8y ago
  Multiple large programs written in LuaJIT that have better performance than the same programs written in optimized C. The vast majority of benchmarks I've seen are down to LuaJIT performing specific optimizations out of the box that the C compiler used in the comparison can perform but doesn't. In particular the last time I looked at LuaJIT vs C++ benchmarks, the C++ compiler flags weren't set allow the use of SIMD instructions by default, but LuaJIT does. There was another recent example I saw where LuaJIT was calling C functions faster than C in a benchmark. Then someone pointed out what the LuaJIT interpreter was actually doing, and how to implement the same speed up in C. Java people made the same arguments years ago: "Java is just as fast or faster than C++". You'll notice that after 20 years of comparisons, no one who writes high performance code for a living makes that claim.
  - shawn 8y ago
    Java is just as fast or faster than C++ most of the time. No one who writes high performance code for a living makes that claim. It's true though. https://lmax-exchange.github.io/disruptor/files/Disruptor-1.0.pdf https://lmax-exchange.github.io/disruptor/files/Disruptor-1....
    - learc83 8y ago
      Java is fast enough that the increased programmer productivity of the GC and other features wins out in many cases. People aren't choosing Java over C++ because it results in generally more performant code. How many AAA game engines are written in Java?