Hacker News Reader

Comment by jillesvangurp | Hacker News Reader

Assembly script is a lot easier to pick up than C++ and Rust; especially for people coming from a typescript or javascript language background (i.e. web developers). And it's not like you are going to get a huge performance benefit using Rust or C++ over assembly script. It's the compiler that makes things fast and the idioms. And basically the compiler toolchain is very similar for assemblyscript.

The only real difference with assembly script is that it's a garbage collected language. Otherwise, it uses llvm and the same set of optimizations you'd be getting with C++ and Rust.

View on HN

> And it's not like you are going to get a huge performance benefit using Rust or C++ over assembly script.

Or do they? Unlike Assembly Script, Rust and C++ use LLVM, which is a lot better at optimizing than binaryen.

What really counts for performance on modern CPUs are memory access patterns, if those are bad, LLVM's optimizer passes won't help much - especially since WASM itself is fairly highlevel too and requires further optimization when translated to machine code anyway.

A more interesting question is instead: does AssemblyScript allow the same control over memory layout as C, C++ or Rust?

I don't think I agree. A debug build of Rust code is often like 40x slower or so than a release build. Those optimizations make a huge difference. Binaryen can only do a fraction of them, so I wouldn't expect AssemblyScript to get close to Rust and C++ (and the benchmarks show that too).

> does AssemblyScript allow the same control over memory layout as C, C++ or Rust?

There's no UB, so in a way AssemblyScript is almost more low level than those, as you have full control over the memory and instructions.

All of that boils down to quality of generated WebAssembly opcodes, nothing prevents an hypothetical AssemblyScript compiler to make use of better optimizations, or being based on LLVM and enjoy the same optimization passes on LLVM IR.

> A debug build of Rust code is often like 40x slower or so than a release build.

Hmm ok, yeah. C++ with heavy stdlib (or generally: template) usage has the same problem (although in my experience it's more like 10..20x slower), but OTH C's debug and release build performance is usually much closer. I guess it's a side effect of generics that they heavily rely on the compiler optimization passes to turn the resulting 'generic mess' into something closer to what a human would write (e.g. remove all the redundant and dead code resulting from 'template resolution').

The main advantage of using Binaryen directly bypassing LLVM is firstly very fast codegen and optimization (Binaryen architecture perfectly utilizes multithreading as opposed to LLVM). In addition, clean and fast debug builds are not clogged with SSA and mSSA noise. That makes debug/release performance not more than 2-4x slower, unlike LLVM where this ratio is 20x-40x as already mentioned. The Binaryen optimizer is improving all the time. It is already better in many places than the same Go's codegen

They probably meant compiling Rust to WASM, not comparing WASM vs native code which is a choice you would make separately to the programming language.

LLVM can compile to webassembly.

Reply on news.ycombinator.com