Add option to run compiler tests in parallel

[dcodeIO]

Given the --parallel option, the compiler test suite can now spawn one process per logical CPU core and split the tests among them. The goal was to make this 100% interchangeable with a normal run, producing the same output except test ordering. Reduces the time of npm run test:compiler from 32 to 17 13 seconds on my machine using 16 7 workers.

[MaxGraey]

I wonder how this different with worker_threads in performance? I think cluster/child process fork have bigger overhead but separate event loops which could be good for I/O

[dcodeIO]

From what I can tell so far this can be speed up by reducing the number of workers from 16 to 8, matching the number of physical cores, at least on my setup (from 17 to 14 seconds) and by running the std/math and std/typedarray tests, which take the most time, first (from 14 to 12 seconds).

[MaxGraey]

Try also numWorkers = physicalCores - 1.

[dcodeIO]

Ah, right. That's 0.5 seconds faster than half the physical cores :)

[dcodeIO]

Last commit brings it down to 13 seconds without reordering tests.

[dcodeIO]

From a node profile and a CPU profile I learned that most time is spent in either I/O, compiling a JS file, running the compiler or inside of Binaryen, while all cores spike at 100% at first with some dropping earlier than others. That's most likely because the remaining few long-running tests need to finish while some cores are already idle. I also found that running a non-parallel test utilizes one core at 100% and four at about 40%, so some stuff inside of node/V8 is threaded even in this case, even though the process presents itself as single-threaded. Explains why it's not a NUM_CORES times speedup.

[MaxGraey]

What if replace this to instantiateStreaming?

[dcodeIO]

Does that work in node? If you want, feel free to improve this even more :)

[MaxGraey]

wait) I'm totally forgot that node.js does't support instantiateStreaming=)

[MaxGraey]

But we still have async WebAssembly.instantiate. I checked this PR on my machine and all my cpus loads only on ~60-70% so we still have gap for improvements. I guess it should be I/O.

[dcodeIO]

Suggesting to merge this as-is so everyone can try it on their machines, potentially submitting additional improvements. It's not enabled on CI yet, so that should be fine. Wdyt?

[MaxGraey]

sure. Let's do it)