More food for thought, as I've been thinking about this:
1. std::thread::hardware_concurrency
This is the number of threads that can execute in parallel, no?
2. "Memory-level parallelism"
How many memory operations can be "outstanding" at once - seems comparable to a single core issuing multiple disk reads. The memory operations aren't really serviced simultaneously, they just have overlapping lifetimes.
You can have concurrency without parallelism per the definition of the article - on a single processor system with timeslicing, for example.
SIMD systems effectively give you parallelism without concurrency - only one instruction is executing, but it's operating on multiple dataflows.
Your linked definition of "concurrency limited" seems to refer to utilisation. In the scenario described, how effectively the processor can be utilised depends on how many concurrent tasks it has in progress so it has something to do while one of them is waiting for a cache miss.
Comments
More food for thought, as I've been thinking about this:
1. std::thread::hardware_concurrency
This is the number of threads that can execute in parallel, no?
2. "Memory-level parallelism"
How many memory operations can be "outstanding" at once - seems comparable to a single core issuing multiple disk reads. The memory operations aren't really serviced simultaneously, they just have overlapping lifetimes.
For more fun, some people refer to the case where performance is limited by the amount of memory-level parallelism available as "concurrency-limited": https://sites.utexas.edu/jdm4372/2018/01/01/notes-on-non-tem...
You can have concurrency without parallelism per the definition of the article - on a single processor system with timeslicing, for example.
SIMD systems effectively give you parallelism without concurrency - only one instruction is executing, but it's operating on multiple dataflows.
Your linked definition of "concurrency limited" seems to refer to utilisation. In the scenario described, how effectively the processor can be utilised depends on how many concurrent tasks it has in progress so it has something to do while one of them is waiting for a cache miss.