Linked by Thom Holwerda on Fri 19th Mar 2010 13:00 UTC, submitted by Jim Lynch
Permalink for comment 414450
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
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
Linked by Thom Holwerda on 04/18/13 11:21 UTC
More Features »
Sponsored Links



Member since:
2005-07-08
This doesn't address the main problem, which is that user software is not pervasively threaded.
Assigning each processor to a process doesn't fix the single-thread performance ceiling, and it doesn't let single-threaded processes utilize more than one processor when those resources are available.
I don't see what problem this approach intends to solve. Next to user programs, modern OS kernels tend to be comparatively brilliant at multi-threading (not that there's no room for improvement), and nothing in this proposal endows existing user programs with shiny new powers of parallelism.