4 ms·

According to the w2c2 readme "Coremark 1.0: ~7% slower than native" so within the generated code performance sounds quite good. What I'm curious about is how h

According to the w2c2 readme "Coremark 1.0: ~7% slower than native" so within the generated code performance sounds quite good. What I'm curious about is how hard it is to build a library target via this method and how much overhead there is in calling the generated code. Maybe someone who knows WebAssembly has some idea? Do call parameters need to get turned into JSON and back? Can I pass in a pointer to writable memory?

flohofwoe 4y ago
'Primitive types' like integers and floats can be passed to the other side directly as function parameters without marshalling. For memory access I can only describe how it works in the browser environment with Emscripten (for lack of experience with other WASM integrations): The WASM heap is exposed as a Javascript ArrayBuffer object (or more correctly that ArrayBuffer object is the WASM heap, created on the JS side and handed to the WASM side at startup), with per-primitive-type array views (for instance for byte access there's a global "HEAPU8: Uint8Array" object on the JS side). Since WASM currently only has 32-bit pointers, pointers can be passed safely to the Javascript side as JS 'numbers' without loss of information. This 'number pointer' can then be used as array index to read and write data in the WASM heap from the JS side. Don't know how it works in WASM engines outside the browser, but I suppose it's similar (e.g. a shared heap between the native side and WASM), except maybe that you can also pass 64-bit integers around without data loss. But in no case there needs to be any JSON- or Protobuf-style 'parameter serialization' involved. This old blog post might contain some more information: https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/ https://hacks.mozilla.org/2018/10/calls-between-javascript-a...

flohofwoe 4y ago

'Primitive types' like integers and floats can be passed to the other side directly as function parameters without marshalling. For memory access I can only describe how it works in the browser environment with Emscripten (for lack of experience with other WASM integrations): The WASM heap is exposed as a Javascript ArrayBuffer object (or more correctly that ArrayBuffer object is the WASM heap, created on the JS side and handed to the WASM side at startup), with per-primitive-type array views (for instance for byte access there's a global "HEAPU8: Uint8Array" object on the JS side). Since WASM currently only has 32-bit pointers, pointers can be passed safely to the Javascript side as JS 'numbers' without loss of information. This 'number pointer' can then be used as array index to read and write data in the WASM heap from the JS side. Don't know how it works in WASM engines outside the browser, but I suppose it's similar (e.g. a shared heap between the native side and WASM), except maybe that you can also pass 64-bit integers around without data loss. But in no case there needs to be any JSON- or Protobuf-style 'parameter serialization' involved. This old blog post might contain some more information: https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/ https://hacks.mozilla.org/2018/10/calls-between-javascript-a...