By: Linus Torvalds (torvalds.delete@this.linux-foundation.org),
Room: Moderated Discussions
none (none.delete@this.none.com) on June 10, 2020 6:47 am wrote:
>
> Their performance is "low" because from the ISA point of view the differences cost a lot to
> translate.
No.
Been there, done that.
Their performance is low because outside of benchmarks, repeat rates are often in the tens or hundreds.
Making SW translation overhead ludicrously high, even when you don't any big ISA differences.
Your translation caches would need to be persistent and absolutely enormous to overcome that simple basic issue, and then you'd need cache lookup and coherency logic that is much more expensive than just doing the hardware.
You can't win.
You can't even break even.
The sad part is how SW JIT's generally don't look particularly great even in benchmarks. And see above about how those are the only situation where they could effectively work fairly well in the first place.
In the spirit of the times, "cold code matters".
A lot.
Amdahl hasn't gone away, and if you're 100x worse on cold code (because either JIT overhead or not translating it - doesn't matter), then even if only 1% of the code you run is cold...
So give it up, people.
A JIT is not a replacement for hardware. Never will be.
And btw, don't get me wrong. That statement doesn't make JIT's useless or evil. When I say "A JIT is not a replacement for hardware" I mean exactly that, and nothing else.
JITs are great, but they are complementary to great hardware, not replacements for it.
If you want to run legacy code or scripting languages or whatever, and performance isn't your primary issue, a JIT is absolutely the way to go.
So using a JIT to still run programs for another architecture is fine, as long as it's not the primary goal of the new hardware.
Because you shouldn't fool yourself. It will be relatively slow. A JIT is simply fundamentally not the way to beat HW, and it's not a way to beat statically compiled code.
A JIT is a way to get flexibility that may not be reasonable to do in hardware (or in compiled software, for that matter - some languages and problem sets simply have dynamic features that are not great for static compilations and run-time generation can be a great way to "fix" a dynamic problem with a particular solution).
But performance on a static problem - whether that problem be a fixed ISA or some static code base - is not their strong point.
And that's pretty darn fundamental.
Linus
>
> Their performance is "low" because from the ISA point of view the differences cost a lot to
> translate.
No.
Been there, done that.
Their performance is low because outside of benchmarks, repeat rates are often in the tens or hundreds.
Making SW translation overhead ludicrously high, even when you don't any big ISA differences.
Your translation caches would need to be persistent and absolutely enormous to overcome that simple basic issue, and then you'd need cache lookup and coherency logic that is much more expensive than just doing the hardware.
You can't win.
You can't even break even.
The sad part is how SW JIT's generally don't look particularly great even in benchmarks. And see above about how those are the only situation where they could effectively work fairly well in the first place.
In the spirit of the times, "cold code matters".
A lot.
Amdahl hasn't gone away, and if you're 100x worse on cold code (because either JIT overhead or not translating it - doesn't matter), then even if only 1% of the code you run is cold...
So give it up, people.
A JIT is not a replacement for hardware. Never will be.
And btw, don't get me wrong. That statement doesn't make JIT's useless or evil. When I say "A JIT is not a replacement for hardware" I mean exactly that, and nothing else.
JITs are great, but they are complementary to great hardware, not replacements for it.
If you want to run legacy code or scripting languages or whatever, and performance isn't your primary issue, a JIT is absolutely the way to go.
So using a JIT to still run programs for another architecture is fine, as long as it's not the primary goal of the new hardware.
Because you shouldn't fool yourself. It will be relatively slow. A JIT is simply fundamentally not the way to beat HW, and it's not a way to beat statically compiled code.
A JIT is a way to get flexibility that may not be reasonable to do in hardware (or in compiled software, for that matter - some languages and problem sets simply have dynamic features that are not great for static compilations and run-time generation can be a great way to "fix" a dynamic problem with a particular solution).
But performance on a static problem - whether that problem be a fixed ISA or some static code base - is not their strong point.
And that's pretty darn fundamental.
Linus