3 ms·

This does exist, we call it Java (or C# or probably a dozen other implementations) The big tradeoff you're making is that you have significantly less time to r

This does exist, we call it Java (or C# or probably a dozen other implementations) The big tradeoff you're making is that you have significantly less time to run your optimizer, since not everybody has a beefy machine or the patience to wait a day for their browser to start first time. You could try doing optimization ahead of time, but I think (I could be wrong here) you would inevitably end up adding in some CPU assumptions if you went much further. This also somewhat conflicts with an advantage of VM based execution, that new optimizations apply to old binaries. I'll also note that hand rolled assembly/SIMD code still beats compilers at the extreme end and you would either have to throw that away, or get all the disadvantages mentioned above without all the advantages

pjmlp 2mo ago
> significantly less time to run your optimizer, Not necessarily, you work around this with JIT caches, which allow the optimiser not to start always from zero. Additionally your can also AOT compile, with or without PGO data. All modern bytecode implementations, at least for Java and .NET, use a mix of JIT with caching/AOT/PGO.
- joha4270 2mo ago
  You can work around this in various ways yes (I'll add dynamic recompilation to your list of workarounds), but you're always going to have the problem of "Somebody downloaded a program and want to run it now"
  - pjmlp 2mo ago
    Yeah, however in that very specific scenario it isn't about any winning SPEC benchmark suit. Adding another workaround, shipping the JIT cache metadata alongside the program, and dynamically sharing it across all devices of the same category, as done in Android.
MiroslavPokorny 2mo ago
I do most of my work in java (https://github.com/mP1 https://github.com/mP1)... so i am familiar with it. Java is a high level language, and the native optimisations are done by the JVM vendor which basically boils down to Oracle today. Some people might write some native code that is faster, but that is hardly the norm. There are many classes of programs that dont work particularly well if written in java, such as video editing or graphics because you know the rest.

pjmlp 2mo ago

> significantly less time to run your optimizer, Not necessarily, you work around this with JIT caches, which allow the optimiser not to start always from zero. Additionally your can also AOT compile, with or without PGO data. All modern bytecode implementations, at least for Java and .NET, use a mix of JIT with caching/AOT/PGO.

joha4270 2mo ago
You can work around this in various ways yes (I'll add dynamic recompilation to your list of workarounds), but you're always going to have the problem of "Somebody downloaded a program and want to run it now"
- pjmlp 2mo ago
  Yeah, however in that very specific scenario it isn't about any winning SPEC benchmark suit. Adding another workaround, shipping the JIT cache metadata alongside the program, and dynamically sharing it across all devices of the same category, as done in Android.

MiroslavPokorny 2mo ago

I do most of my work in java (https://github.com/mP1 https://github.com/mP1)... so i am familiar with it. Java is a high level language, and the native optimisations are done by the JVM vendor which basically boils down to Oracle today. Some people might write some native code that is faster, but that is hardly the norm. There are many classes of programs that dont work particularly well if written in java, such as video editing or graphics because you know the rest.