Yeah, same silly things programmers do in real world statically compiled code. Bad choices for something like data type and bad compiler options. A JIT can figure out negative numbers can't happen and optimize accordingly. It might know about the CPU model that didn't even exist when the static code was compiled.
back
1 comments
And how do you expect a JIT to "figure out" negative numbers can't happen and optimize accordingly where a static compiler could not?
It can do simple control flow analysis and data flow analysis and generate the constraints out of that. It doesn't even need to be right, if there's a proper guard condition in the generated code.
Interestingly, you brought up two things that are typically categorized as static analysis. Keep in mind GCC does figure out the values will never be negative and its run-times destroy all the JIT competitors listed on that page. Also, static compilers can and do generate code with guard conditions.
Yes. They're all compilers. Static compilers just limit themselves to generating and caching code just once, one size fits all. Dynamic JITs can do all that and adapt at runtime.
You could even statically compile a binary and JIT on top of that based on runtime profiles. That would probably be the winning combination performance wise.
How does this follow from you implying a JIT advantage for this use case and me asking exactly what the JIT advantage is? I think you are just arguing to win at this point.
The JIT advantage is the runtime information. Only benchmarks will always run the code in same way. Any useful piece of software runs under different conditions in different invocations and situations.
JIT can remove code from inner loops that is unnecessary for the current invocation. It can also use any instructions available on the CPU it's running on. It can use more registers if the CPU has them.
JIT advantage is higher performance, which is mostly untapped today.
I don't care about winning any points. I just want people to understand it's not black and white. JIT as an acronym causes them to jump to conclusions without even thinking about it.
Statically compiled code is suboptimal for all but the idealized case the code was compiled for. It has to take general case into account. Wasting cycles checking the condition that's always false anyways for current problem. Setting up the inner loop that's executed just once or twice every time.
A JIT can spend a few microseconds optimizing for that and running the code for 10 milliseconds. Instead of running the generic statically compiled case for 20 milliseconds. JIT can produce code more native than the "native" statically compiled presentation.