Linked by Thom Holwerda on Sun 8th Jul 2012 22:54 UTC
Thread beginning with comment 526257
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/24/13 17:26 UTC
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
More Features »
Sponsored Links



Member since:
2011-01-28
whartung,
"Fixed that for ya!"
"If you ain't in cache, you ain't nothin."
Actually, I may be using poor semantics, but I consider memory limited processes (whether from CPU or GPU) to be "IO" bound. After all, those requests have to be serialised over the system bus almost like any other IO. Obviously most programmers treat "memory" as though it's different from IO. While memory IO clearly plays a specific role for the CPU, from a databus-oriented point of view it's not all that special.
Semantics aside, it can be difficult to make SMP systems scale well if memory & IO are the real bottlenecks. I'd consider a CPU-bound process one that makes minimal use of the system bus, including system memory. I find many multithreaded advocates proposing to subdivide problems among tiny light weight threads, but very often they shift a problem from being CPU-bound (which is good for SMP) into one that is memory-bound which offsets the benefits of parallelism.
Even caching is problematic in that x86 processors must implement very strict cache coherency models, which severely limits SMP scalability.