4 ms·

Sun at some point built a CPU that could run java bytecode "natively". That sounds nicer than it actually is when you realize that most practical optimizations

Sun at some point built a CPU that could run java bytecode "natively". That sounds nicer than it actually is when you realize that most practical optimizations happen at run time in Java. WASM is very similar in that it typically gets executed by a jit and that compilers don't try to optimize too much ahead of time. WASM is optimized for loading quickly in a JIT. It also shares the issue that it needs to run on a very wide variety of hardware architectures. So it is not optimized for any particular one.

deleted 5y ago
[deleted]
mst 5y ago
There were also ARM variants that could run a bunch of JVM bytecode natively - https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle
- monocasa 5y ago
  It was only really competitive against interpreters. It was aimed at a gate count niche that couldn't expect a JIT, for instance feature phones or JavaCards.
  - Stephanemw 5y ago
    +1 on the features phones - I worked on quite a few of them that had Jazelle acceleration for J2ME. Solid 60fps on those 206MHz CPUs and the bottleneck was actually the display pipeline!
- jillesvangurp 5y ago
  Thanks, that's what I was referring to.
varjag 5y ago
WASM isn't specifically meant to be JIT and there is no compelling reason to. One prime use is ahead of time native compilation from easy to translate intermediate representation.
- jillesvangurp 5y ago
  WASM specifically intended to run in just about any CPU. Which makes JIT compilation a particularly valid strategy to run it. Hardware accelerating the unoptimized WASM bytecode would have a lot of limitations since compiler does not know what hardware it is going to be running on. So, it can't do any hardware specific optimizations that a normal compiler would do.
  - j-pb 5y ago
    A single compiler pass that takes the WASM and optimises it for your machine is still AOT compilation. What makes the JIT a JIT is not it's ability to execute bytecode optimised for the platform, but to perform optimisations for your current input problem with its memory and execution characteristics. E.g. stuf like polymorphic inline caching or dynamic decompilation. Wasm is pretty well AOT compilable, and I don't see a reason why a WASM CPU shouldn't run a hybrid aproach of a hardware AOT step, with WASM kinda being it's microcode.
    - codeflo 5y ago
      > with WASM kinda being it's microcode Not to be too pedantic, just because you make a good point that's worth clarifying: I think you meant WASM being the processor's *ISA*, which is translated to microcode instructions that are more optimized for actual execution. Exactly like an Intel CPU isn't "really" executing x86 instructions anymore.
      - j-pb 5y ago
        You're correct, my brain skipped a couple steps when writing that sentence ^^', thanks for the clarification!
    - pjmlp 5y ago
      It doesn't need to be like microcode, it suffices to be like portable excitable format. This was pretty common in big iron, and survives to this day on IBM and Unisys mainframes. Also some Java vendors take this approach by AOT .class files into native code for embedded deployment, as an option.
flohofwoe 5y ago
There was a short time window in browsers where WASM was actually AOT compiled, instead of the tiered compilation model that seems to be common now. I actually preferred the AOT compilation because it meant that there was no JS-like warmup phase until the code reaches full speed. This was a problem for large WASM blobs though because compilation took too long, and instead of "encouraging" people to write small WASM blobs, the browser makers "caved in" and moved towards a more JIT-like model (first pass is "compile fast but run slowly", and then compile hot functions with an optimizing compiler again).
- pjmlp 5y ago
  With application frameworks like Blazor, Uno, Flutter, Composer, Unity taking the place of Flash, Java Applets and Silverlight, trying to force people to write smaller WASM modules was doomed to fail anyway.
posterboy 5y ago
The Optimizer could still output bytecode, which sounds theoretically nice for homomorphy, turtles all the way down (I am not a logician, mind)
teh_klev 5y ago
If anyone's interested, this was the issue of Byte magazine that wrote about Sun's Java CPUs: https://archive.org/details/eu_BYTE-1996-11_OCR https://archive.org/details/eu_BYTE-1996-11_OCR I actually owned that copy, but sadly and stupidly gave it away with the rest of my Byte collection that dated from 1983 until Byte's demise.
- marshray 5y ago
  I have a mostly complete set of BYTEs from the late 70's into the 90's. Thank you for reminding me why I haul them around every time I move. I would love to donate them but can't think of anywhere worthy.

deleted 5y ago

[deleted]

mst 5y ago

There were also ARM variants that could run a bunch of JVM bytecode natively - https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle

monocasa 5y ago
It was only really competitive against interpreters. It was aimed at a gate count niche that couldn't expect a JIT, for instance feature phones or JavaCards.
- Stephanemw 5y ago
  +1 on the features phones - I worked on quite a few of them that had Jazelle acceleration for J2ME. Solid 60fps on those 206MHz CPUs and the bottleneck was actually the display pipeline!
jillesvangurp 5y ago
Thanks, that's what I was referring to.

varjag 5y ago

WASM isn't specifically meant to be JIT and there is no compelling reason to. One prime use is ahead of time native compilation from easy to translate intermediate representation.

jillesvangurp 5y ago
WASM specifically intended to run in just about any CPU. Which makes JIT compilation a particularly valid strategy to run it. Hardware accelerating the unoptimized WASM bytecode would have a lot of limitations since compiler does not know what hardware it is going to be running on. So, it can't do any hardware specific optimizations that a normal compiler would do.
- j-pb 5y ago
  A single compiler pass that takes the WASM and optimises it for your machine is still AOT compilation. What makes the JIT a JIT is not it's ability to execute bytecode optimised for the platform, but to perform optimisations for your current input problem with its memory and execution characteristics. E.g. stuf like polymorphic inline caching or dynamic decompilation. Wasm is pretty well AOT compilable, and I don't see a reason why a WASM CPU shouldn't run a hybrid aproach of a hardware AOT step, with WASM kinda being it's microcode.
  - codeflo 5y ago
    > with WASM kinda being it's microcode Not to be too pedantic, just because you make a good point that's worth clarifying: I think you meant WASM being the processor's *ISA*, which is translated to microcode instructions that are more optimized for actual execution. Exactly like an Intel CPU isn't "really" executing x86 instructions anymore.
    - j-pb 5y ago
      You're correct, my brain skipped a couple steps when writing that sentence ^^', thanks for the clarification!
  - pjmlp 5y ago
    It doesn't need to be like microcode, it suffices to be like portable excitable format. This was pretty common in big iron, and survives to this day on IBM and Unisys mainframes. Also some Java vendors take this approach by AOT .class files into native code for embedded deployment, as an option.

flohofwoe 5y ago

There was a short time window in browsers where WASM was actually AOT compiled, instead of the tiered compilation model that seems to be common now. I actually preferred the AOT compilation because it meant that there was no JS-like warmup phase until the code reaches full speed. This was a problem for large WASM blobs though because compilation took too long, and instead of "encouraging" people to write small WASM blobs, the browser makers "caved in" and moved towards a more JIT-like model (first pass is "compile fast but run slowly", and then compile hot functions with an optimizing compiler again).

pjmlp 5y ago
With application frameworks like Blazor, Uno, Flutter, Composer, Unity taking the place of Flash, Java Applets and Silverlight, trying to force people to write smaller WASM modules was doomed to fail anyway.

posterboy 5y ago

The Optimizer could still output bytecode, which sounds theoretically nice for homomorphy, turtles all the way down (I am not a logician, mind)

teh_klev 5y ago

If anyone's interested, this was the issue of Byte magazine that wrote about Sun's Java CPUs: https://archive.org/details/eu_BYTE-1996-11_OCR https://archive.org/details/eu_BYTE-1996-11_OCR I actually owned that copy, but sadly and stupidly gave it away with the rest of my Byte collection that dated from 1983 until Byte's demise.

marshray 5y ago
I have a mostly complete set of BYTEs from the late 70's into the 90's. Thank you for reminding me why I haul them around every time I move. I would love to donate them but can't think of anywhere worthy.