3 ms·
beyond the aforementioned embarrassingly parallel problems I don't think we'll see much performance increase once we reach the point where each app/process is r
by nazgulnarsil 17y ago
beyond the aforementioned embarrassingly parallel problems I don't think we'll see much performance increase once we reach the point where each app/process is running on its own core.
- jrockway 17y agoWell, sure. Most apps are waiting for IO -- waiting for the network, waiting for the disk to read a file, or waiting for the user to do something. No multi-core processor is going to speed that up. However, many algorithmic problems parallelize well. It's just that it doesn't really matter for "desktop users". (See also: the popularity of netbooks.)
- nazgulnarsil 17y agoOTOH I do fully expect software to continue to bloat as developers increasingly do less with more.
- joe_the_user 17y agoWell, this is standard behavior but ... "Doing less with more" has often been cost-effective given the relative cost of programmers versus machines. A change in that cost-equation will quite possibly result in different decisions being made. Demand for more efficient programming seems likely to thus increase.
- JulianMorrison 17y agoOn my Linux machine, not even a server but just a desktop, there are 111 running processes. There's room for growth in multi-core yet.
- tl 17y agoHow many of those processes are small / simple enough that you can fit dozens of them on a single core with no performance loss? On my dual-core box, top shows very few programs registering 1% of CPU usage. Of those, only firefox needs it often.
- wmf 17y agoDon't you mean there are 111 sleeping processes? It's unlikely that a desktop would have so many runnable processes.
- JulianMorrison 17y agoAh, my use of "running" was misleading. That's just a crude line count of the "ps ax" listing. (And I probably counted the header line - d'oh!) Yes, most are sleeping.