Should we include thread.hw_concurrency?

[abrown]

The section describing the thread.hw_concurrency instruction argues that something like this is necessary for some parallel algorithms (e.g., data parallel ones) to perform optimally. That section also discusses some of the fingerprinting concerns of such an instruction. What do you think — is thread.hw_concurrency necessary?

[conrad-watt]

I think it's harmless to include, but in theory a minimal proposal could leave it out - on the Web, the value of hardwareConcurrency can be fed in (as an import or as a set global), outside the Web some appropriate WASI API could provide this value.

[lukewagner]

I can appreciate the general use case of: I have some data-parallel kernel, how many threads should I run it on?

My initial knee-jerk reaction is to worry that making this an instruction is a virtualizability hazard and thus we should go the import route as Conrad suggests. That being said, once you have a way to measure time (noting that, once you have threads+shmem, you have a high-res way to measure time even without importing time), you can measure hardwareConcurrency empirically, so it's a bit of a fig leaf to say that requiring it to be an import makes it virtualizable. So I won't claim that it shouldn't be an instruction on that ground.

There's also more subtle questions that you can see outlined in this Firefox bug and the moz.dev.platform threads it links to that ask whether we should have something more nuanced than a single hardwareConcurrency number. The net result of that whole multi-year mini-debate was "hardwareConcurrency is good enough for browsers for now". But it might be worth considering these questions more-carefully in a wasm context as wasm is being deployed in more diverse contexts, and so maybe it might be a good idea to postpone adding it in an MVP?

[abrown]

Now that everyone is suggesting to "post-MVP" it, I'm more motivated to argue for it 😁 I see this feature now as a "developer experience" feature. I would expect those of who are actually writing data-parallel kernels (or want to) to vote for this feature to avoid hacking around trying to measure concurrency or using custom toolchain features to get an import providing this information. And some of these developers presumably may want to run their code in standalone engines, where the JS hardwareConcurrency property is not available. I had always imagined standalone engines having some way to limit how many threads a module could spawn (e.g., a --max-concurrency flag or a new function in a resource limiter API). And this highlights what the differences could be between this proposal and the browser hardwareConcurrency property — we don't really need this to mean "return the number of CPUs" (or "logical CPUs", etc., etc.) but rather "return the number of threads that this module may be able to run concurrently."

[rossberg]

Agreed that both usability and implications of this are unclear enough, and that this should be post-MVP material.

[yamt]

+1 for post-MVP.