emscripten WebAssembly backend and 64-bit integers

[Floh]

Hi, quick question:

When compiling to WebAssembly via Binaryen with "-s WASM=1 BINARYEN_METHOD='native-wasm'", will 64-bit integers be handled 'correctly', or will the resulting WebAssembly code split the 64-bit operations into 32-bit ops?

The reason I'm asking is that I'm currently rewriting my 8-bit emulator, and I'm currently relying on fast 64-bit operations in the tick-callback that's executed about a million times per second (I'm packing all CPU pins into a 64-bit integer, hand that to the tick callback, the tick callback inspects and modifies the pins, and hands them back to the CPU emulation).

I'm seeing two things that are suspicious: (1) the resulting code is about 3..4x slower than native x86-64, which is a bit unusual, and (2) I'm not seeing a performance difference betwee asm.js and WASM (I would expect that the asm.js version is slower since it needs to emulate the 64-bit stuff).

The CPU emulation is very sensitive to things like inlining and memory accesses (e.g. very small changes can cut the performance in half in the natively compiled version), so the 32-bit vs 64-bit is only one of the possible reasons I'm looking into.

The project is here if anyone's interested: https://github.com/floooh/chips

The performance-critical Z80 opcode decoder is here: https://github.com/floooh/chips/blob/master/chips/_z80_opcodes.h

This repository contains tests and example emulators: https://github.com/floooh/chips-test, however these are not yet ready for emscripten, I'm currently testing this in the "chips" branch of my multi-system home computer emulator: https://github.com/floooh/yakc/tree/chips

Once I'm doing more detailed performance investigations for asm.js/wasm I will most likely create simpler tests (I'd really like to know why the web versions are 3..4x slower for this type of code, another reason could be all the bit-twiddling operations on 8- and 16-bit integers).

Cheers,

-Floh.

[Alon Zakai]

It should emit correct native i64 operations when emitting wasm (with either compiler backend). Unless you're on a quite old version (at least 6 months or so). Can verify by building with -g and looking for i64 in the wast.

Emulator loops might be slow for other reasons, like JS engines being less optimized on them. I've seen issues with register allocation for example. Do you have a benchmark version of that code that's easy to build and compare?

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Floh]

Alright, thanks for the info :) I'll try to work towards a benchmark that's easy to build for WebAssembly. I think the Z80 ZEXDOC test would be a good candidate, but this needs to run for a up to a few minutes uninterrupted, so it would need to run in a pure JS engine like node.

Thanks!

-Floh.

[Jukka Jylänki]

Given that you're able to build to both native and wasm, it'd be great
to have an automated run that does the same steps, and then take the
web build through Gecko Profiler (https://perf-html.io) and the native
build through e.g. AMD CodeXL, and compare how the resulting profiles
differ.

From past experience I do remember that such large functions with huge
switch cases/function bodies can make a register allocator in the
browser "give up" and revert to simple linear allocation without any
backtracking. The z80_exec function looks something like that, so it
would be good to confirm if the profiling hotspots are biased towards
that function in the WebAssembly build. You can try experimenting with
-s OUTLINING_LIMIT=x (and perhaps -Oz) to see if that might affect the
behavior.

>>> email to emscripten-disc...@googlegroups.com.

>>> For more options, visit https://groups.google.com/d/optout.
>>
>>

> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to emscripten-disc...@googlegroups.com.

[Floh]

Thanks for the suggestions jj!

>>> email to emscripten-discuss+unsub...@googlegroups.com.

>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to emscripten-discuss+unsub...@googlegroups.com.