[HN Gopher] Wasmtime 1.0: A Look at Performance
       ___________________________________________________________________
        
       Wasmtime 1.0: A Look at Performance
        
       Author : mnemonik
       Score  : 57 points
       Date   : 2022-09-06 17:03 UTC (5 hours ago)
        
 (HTM) web link (bytecodealliance.org)
 (TXT) w3m dump (bytecodealliance.org)
        
       | jeroenhd wrote:
       | How do bytecode compilers like Cranelift compare to native images
       | generated out of bytecode that's easier to optimize for pure
       | machine code execution (Java, dotnet)?
       | 
       | Perhaps more relevant: what's the point of taking machine code
       | capable software, compiling it into WASM, and then compiling that
       | back into machine code? A reinvention of FFI perhaps?
        
         | mort96 wrote:
         | Ignoring security for a moment: Say you want to write a web
         | application in Rust. You want to ship your web application to
         | your users. You don't want your users to have to wait for the
         | whole application to compile and download all dependencies; you
         | want to ship some precompiled stuff. What do you ship?
         | 
         | We could have some web standard where we ship native code to
         | the user, which the user's machine then executes directly
         | (using some form of sandboxing). Maybe we could have a standard
         | API so that the operating system's interfaces don't play a
         | role. But you still have to ship x86_64, aarch64, ARM32, RISC-V
         | 32, RISC-V 64, MIPS, PowerPC, etc. And you'll need to support
         | multiple versions of all these different instruction sets; some
         | users may have old x86 machines without SSE, so you need a
         | version of your x86 code with x87 floats rather than SSE
         | floats. And you need one version of your ARM native code with
         | hard floats for machines with FPUs, and one version with soft
         | floats for machines without. And you need to constantly add new
         | variations as new instruction sets or new versions of old
         | instruction sets are released.
         | 
         | I don't trust most websites to get all of this correct. And if
         | websites got it wrong, or if websites ever stopped adding new
         | targets, or ever removed supports for old targets, we would end
         | up with a web which isn't usable on certain CPU architectures,
         | which is the opposite of what the web is all about.
         | 
         | The alternative is that we have some specification for
         | intermediate code which is low level enough to be a universal
         | compile target but abstract enough to be possible to compile to
         | essentially any CPU architecture. That's what WASM is.
        
         | dadoum wrote:
         | > Perhaps more relevant: what's the point of taking machine
         | code capable software, compiling it into WASM, and then
         | compiling that back into machine code? A reinvention of FFI
         | perhaps?
         | 
         | Firefox has some parts which are compiled to WebAssembly, and
         | Mozilla wrote an article about it [0]. They seem to use
         | WebAssembly to sandbox the code and improve security.
         | 
         | [0]: https://hacks.mozilla.org/2020/02/securing-firefox-with-
         | weba...
        
         | klabb3 wrote:
         | > what's the point of taking machine code capable software,
         | compiling it into WASM, and then compiling that back into
         | machine code?
         | 
         | If I understand your question correctly, the point is that wasm
         | becomes _the_ agreed-upon target, so you only need language - >
         | wasm compilation and you can then distribute that artifact
         | everywhere. Then you can either JIT it or recompile it into
         | machine code at the endpoint, as an optimization.
         | 
         | That would help reduce the size of the graph of N languages and
         | M architectures from O(MN) to O(M+N) (similar to the function
         | of IR)
        
           | felixgallo wrote:
           | why would any language besides javascript want to be that
           | maximalist, when they already have either a much better
           | direct native compiler, or their own, purpose-built,
           | mechanically-sympathetic, fully featured interpreter with
           | first-class support and a controllable destiny? We didn't do
           | this with Java back in the day when it was possible --
           | essentially all but a small handful of JVM languages died on
           | the vine -- so what specifically is different this time?
        
             | mort96 wrote:
             | JVM bytecode is, to my understanding, basically just a
             | serialized, desugared Java. It has a concept of classes
             | with constructors and it has objects and references and
             | inheritance and basically all of Java's semantics encoded
             | in it. Languages which aren't "java-like" have a hard time
             | compiling to it. WASM, on the other hand, is more like
             | machine code, so languages which are used to compiling to
             | machine code have a fairly easy time compiling to it.
        
       | jedisct1 wrote:
       | Probably a good time to run a new iteration of the Libsodium
       | WebAssembly benchmarks.
        
       ___________________________________________________________________
       (page generated 2022-09-06 23:01 UTC)