4 ms·
Thank you for your answer, interesting read! > Why would LuaJIT be the best? It was one example out the group of best ones, sorry for not being clear enough.
by fredrikholm 3y ago
Thank you for your answer, interesting read!
> Why would LuaJIT be the best?
It was one example out the group of best ones, sorry for not being clear enough.
> Also, memory layout is a completely different problem space, don’t judge JIT compilers on that.
Exactly; you're stuck with the memory floor the language provides you with, JIT or not. This means a fixed minimum cost (resources, heat, electricity etc) that would otherwise not be there.
> On numerical code they are very competitive with AOT compiled, low-level languages
How competitive? I've never seen a benchmark show a JITed language compare to the equivalent program in C, with the few exceptions where the C implementation was written in such a way as to enable the author to say "we're faster than C".
> most real life code in C/C++/Rust whatever will also happily chase pointers, so the difference is again, not as stark as some benchmark may tell you
Oh most definitively. On the other side of that same coin, most real life code in JS/Java/C#/PHP/Ruby consume orders of magnitude more resource than their lower level counter parts.
Often, a lot of that is due to writing idiomatic code in languages where idioms are expensive (eg. `[... new Set(arr)]` in JS), which often also means that underlying libraries and frameworks also use these idioms. Even worse when libraries like lodash/ramda become popular and you have another order of magnitude more overhead compared to the equivalent for loops.
You could of course optimize that, just like you could optimize your C/C++/Rust/Zig program.
> You are right that deoptimizations can be expensive, when they go wrong, or in the worst case go into some cycles
If what you're saying is true than that's great news! My own experiences (>decade ago) of observing other teams experiment with JITed languages showed more pessimistic worst case outcomes (embedded engineers trying out embedded scripting languages).
- xgdgsc 3y agoI' ve seen quite a few posts like https://users.rust-lang.org/t/a-performance-problem-compared-with-julia/51871 https://users.rust-lang.org/t/a-performance-problem-compared... , https://discourse.julialang.org/t/why-is-julia-faster-than-c-for-quicksort/102669 https://discourse.julialang.org/t/why-is-julia-faster-than-c... ... And many are from average programmers writing Cpp/Rust vs Julia, this is really good news for scientists/engineerers who need quick experiments.
- kaba0 3y agoJulia is a good example for a language with JIT that doesn’t follow the stereotypical OOP layout, so its memory overhead will be only that of the runtime (which is definitely not zero, but nor is it too big). > Oh most definitively. On the other side of that same coin, most real life code in JS/Java/C#/PHP/Ruby consume orders of magnitude more resource than their lower level counter parts. Java is actually within the compiled language’s groups’ results with regards to energy efficiency. A good GC can allow to be very power efficient and tradeoff memory for running the CPU — only has to run the GC when it really is close to filling up. After running, it can free the former region in one `nop` by declaring the former region as unused (at least in the moving GC kind).