4 ms·

This isn’t true. GC’d languages can be as fast or faster than C. Especially LuaJIT.

by shawn 8y ago

learc83 8y ago
>Especially LuaJIT. In the general case that can't really be true, because the Lua interpreter is written in C. With regards to GC languages in general, if you spend a lot of time working around the GC by doing things like object pooling, which is really just reinventing manual memory allocation, you can get close to a non GC language in terms of performance. GC languages are obviously fine for plenty of use cases, and for some use code snippets they can be faster, but there is no way to make a GC free--there's going to be some overhead no matter what you do.
- 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?

This isn’t true. GC’d languages can be as fast or faster than C. Especially LuaJIT.

by shawn 8y ago

This isn’t true. GC’d languages can be as fast or faster than C. Especially LuaJIT.

>Especially LuaJIT. In the general case that can't really be true, because the Lua interpreter is written in C. With regards to GC languages in general, if you spend a lot of time working around the GC by doing things like object pooling, which is really just reinventing manual memory allocation, you can get close to a non GC language in terms of performance. GC languages are obviously fine for plenty of use cases, and for some use code snippets they can be faster, but there is no way to make a GC free--there's going to be some overhead no matter what you do.

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?