Current EMSDK Node version out of date?

[Steven Johnson]

AFAICT, the current EMSDK (1.39.19) uses the finalized opcodes for the
simd128 feature set, but the version of Node that is included in the
EMSDK does not. This makes for amusing runtime errors if you try to
compile wasm and test via Node.

- If this is in fact the case (and not a stupid config error on my
part), may I suggest that the EMSDK release notes point this out?
(Maybe most folks aren't relying on Node for wasm-testing purposes,
but it's handy and seems like it would be in sync, since it's
included...)

- Is there any ETA for when a stable version of Node with final
wasm-simd support will be available?

- If there is no ETA, are there other fast (non-browser) command-line
wasm implementations that would be suitable for testing (ie up to date
with the final spec)? (WABT's wasm-interp tool would be great but is
too slow for some of my purposes)

[Thomas Lively]

FWIW I usually run SIMD tests using V8's debugging shell d8. You can get nightly builds of it easily from JSVU (https://github.com/GoogleChromeLabs/jsvu). It doesn't have all the Node APIs, so it may not suit your needs for end-to-end testing of full applications, but I've found it useful for testing SIMD codegen. Node nightly does not have a recent enough version of V8 to work yet, but there is an experimental version of node that automatically pulls in the most recent V8 at https://github.com/nodejs/node-v8. I've never used it, but it's worth a shot if d8 is too limited for you.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAM%3Ddnvc9HJtUQ69mb_RNXKRxq9Quz8tfQy6v7s04oMvpLu2Efw%40mail.gmail.com.

[Sam Clegg]

Yes, this is a little odd, but I believe its basically WAI.   The node we ship with emscripten is mostly for running the JS tools that we have in emscripten.    We want it to be relatively stable for this reason but also so that emscripten is known to work versions of node in the wild.  We don't want to end up accidentally depending on ToT node features for the normal workflow.  We also happen to use it for a lot of our internal testing too, to be sure that most of our output also runs in stable/old version of node.   However we also use d8 and other runtimes as needed. 

Even if we update to the latest version I believe node is relatively slow at pulling in new v8 versions so even the latest version might not contain the pcodes that you want.  So I think Thomas is probably right that using jsvu to install tot versions of various command line runtime might be the way to go.

I wonder if we can detect this problem and report it in a nicer way though?   Perhaps if you build with wasm + simd support we could try to give better errors when running on incompatible vms?

cheers,

sam

On Fri, Jul 10, 2020 at 5:31 PM 'Steven Johnson' via emscripten-discuss <emscripte...@googlegroups.com> wrote: