It’s easy to think that 64-bit WebAssembly would run better on 64-bit hardware, but unfortunately that’s simply not the case. WebAssembly apps tend to run slower in 64-bit mode than they do in 32-bit mode. This performance penalty depends on the workload, but it can range from just 10% to over 100%—a 2x slowdown just from changing your pointer size.

@dysfun sorry what; how?!

@q @dysfun possibly because emulating a 32-bit address space on a 64-bit machine is easy (just allocate 4GB, you’ve got plenty of address space going spare, no need to actually map the pages until it becomes relevant) whereas you need to do something much more clever to emulate a 64-bit address space

@Gaelan @q no, it's the bounds checks they didn't have to do on 32 bit because they could just allocate 4GB vmem and then all 32 bit addresses were within bounds.

@dysfun @Gaelan and we can't just let the CPU memory manager do this?

@q
@dysfun @Gaelan it needs to be a separate addressing space essentially which no CPU supports on 64 bits

Otherwise you'd have the issue that some addresses point to invalid wasm addresses, but valid host addresses

@q @dysfun @Gaelan the webassembly is running in the same address space as your trusted code

@erincandescent @Gaelan @dysfun couldn't it... not?

@q @Gaelan @dysfun trusted code here includes the VM

@erincandescent @Gaelan @dysfun ah right shit yeah...

computer's fucked

@charlotte @Gaelan @q @dysfun ...I do not want to think about my web browser accessing /dev/kvm to display a website :(