The benefit of being lazy is that if the program intentionally terminates early, hits and error, or just has a control flow that misses all the threaded activity, then we can safely skip the overhead entirely.
I'm wondering though, if by spawning the threads earlier its possible to hide more of the overhead of their creation?
bwf
@ak47 I'm not sure on this, but I'm not sure how much of a benefit there would be to spawning the threads earlier. You mentioned some good reasons in you post regarding the benefits of being lazy, but since we're maintaining a thread pool, the only real overhead we would observe is when the threads are created. Once the program hits steady state or has been running for a while, the bit of overhead for the threads when they were initially spawned seems like it would be rather negligible.
paluri
@ak47 I agree with @bwf. Unless you are talking about an insanely small workload (in which case, you should probably question your decision to use multiple threads), the cost of initializing the threads will be amortized out.
rokislt10
The general idea is that you would have many more tasks than you have workers (a concept that has been reiterated multiple times). That way, even if your tasks do not have very high arithmetic intensity, the amount of time it takes a worker to accomplish its tasks will heavily outwiegh the amount of time it needs for overhead.
ChandlerBing
Why does Cilk launch exactly as many worker threads as execution contexts in the machine, and not more (to ensure good workload balance)?
Faust
This is just a guess, but each worker thread has overhead (it's own queue). I think it is more important to have a small multiple more of independent data, than threads.
haodongl
@ChandlerBing I agree with @Faust, and Cilk also has "work-stealing" policy to divide work among processors, which ensures that all processors are utilized efficiently.
I'm curious about when the threads get spawned.
The benefit of being lazy is that if the program intentionally terminates early, hits and error, or just has a control flow that misses all the threaded activity, then we can safely skip the overhead entirely.
I'm wondering though, if by spawning the threads earlier its possible to hide more of the overhead of their creation?
@ak47 I'm not sure on this, but I'm not sure how much of a benefit there would be to spawning the threads earlier. You mentioned some good reasons in you post regarding the benefits of being lazy, but since we're maintaining a thread pool, the only real overhead we would observe is when the threads are created. Once the program hits steady state or has been running for a while, the bit of overhead for the threads when they were initially spawned seems like it would be rather negligible.
@ak47 I agree with @bwf. Unless you are talking about an insanely small workload (in which case, you should probably question your decision to use multiple threads), the cost of initializing the threads will be amortized out.
The general idea is that you would have many more tasks than you have workers (a concept that has been reiterated multiple times). That way, even if your tasks do not have very high arithmetic intensity, the amount of time it takes a worker to accomplish its tasks will heavily outwiegh the amount of time it needs for overhead.
Why does Cilk launch exactly as many worker threads as execution contexts in the machine, and not more (to ensure good workload balance)?
This is just a guess, but each worker thread has overhead (it's own queue). I think it is more important to have a small multiple more of independent data, than threads.
@ChandlerBing I agree with @Faust, and Cilk also has "work-stealing" policy to divide work among processors, which ensures that all processors are utilized efficiently.