Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename hw_concurrency to available_parallelism. #419

Merged
merged 1 commit into from
Dec 5, 2024

Conversation

sunfishcode
Copy link
Member

Following the general computer-science meanings of the terms "concurrency" and "parallelism", rename thread.hw_concurrency to thread.available_parallelism, because it's about the number of threads that can execute in parallel.

This differs from the existing JS API of navigator.hardwareConcurrency, so add a note mentioning the correspondence.

Following the general computer-science meanings of the terms
"concurrency" and "parallelism", rename `thread.hw_concurrency` to
`thread.available_parallelism`, because it's about the number of threads
that can execute in parallel.

This differs from the existing JS API of [`navigator.hardwareConcurrency`],
so add a note mentioning the correspondence.

[`navigator.hardwareConcurrency`]: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/hardwareConcurrency
@yoshuawuyts
Copy link
Member

yoshuawuyts commented Nov 25, 2024

As the person who added std::thread::available_parallelism to Rust, you'll be unsurprised to learn I'm in favor of this change. The terminology we used there was actually based on @aturon's PhD thesis on concurrency. Here is the motivation section I wrote at the time:

Rationale

The API was initially named std::thread::hardware_concurrency, mirroring the C++ API of the same name. We eventually decided to omit any reference to the word "hardware" after rust-lang/rust#74480 (comment). And so we ended up with available_concurrency instead. For a talk I was preparing this week I was reading through "Understanding and expressing scalable concurrency" (A. Turon, 2013), and the following passage stood out to me (emphasis mine):

Concurrency is a system-structuring mechanism. An interactive system that deals with disparate asynchronous events is naturally structured by division into concurrent threads with disparate responsibilities. Doing so creates a better fit between problem and solution, and can also decrease the average latency of the system by preventing long-running computations from obstructing quicker ones.

Parallelism is a resource. A given machine provides a certain capacity for parallelism, i.e., a bound on the number of computations it can perform simultaneously. The goal is to maximize throughput by intelligently using this resource. For interactive systems, parallelism can decrease latency as well.

Chapter 2.1: Concurrency is not Parallelism. Page 30.

"Concurrency is a system-structuring mechanism. Parallelism is a resource." — It feels like this accurately captures the way we should be thinking about these APIs. What this API returns is not "the amount of concurrency available to the program" which is a property of the program, and thus even with just a single thread is effectively unbounded. But instead it returns "the amount of parallelism available to the program", which is a resource hard-constrained by the machine's capacity (and can be further restricted by e.g. operating systems).

@lukewagner
Copy link
Member

Agreed! It's good to see the prior art for available_parallelism. I suppose let's let this sit for a bit to collect feedback, but then I'm quite happy to merge.

@lukewagner
Copy link
Member

(I forgot above, but cc @abrown)

Copy link
Contributor

@abrown abrown left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is the right change to make, especially if other languages are doing this. The sole reason I named this hw_concurrency initially was to line up with the JS version of this. Given that this functionality has moved to the component model, just documenting that relationship and using the new name seems fine.

@lukewagner lukewagner merged commit a0bc232 into WebAssembly:main Dec 5, 2024
1 check passed
@sunfishcode sunfishcode deleted the sunfishcode/parallelism branch December 5, 2024 15:34
liigo added a commit to liigo/component-model that referenced this pull request Dec 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants