3 ms·
> If you have 48 runnable threads from 48 different tasks running on your machine, you'll get pretty much linear performance increases Only if the tasks are t
by jallmann 12y ago
> If you have 48 runnable threads from 48 different tasks running on your machine, you'll get pretty much linear performance increases
Only if the tasks are trivially parallelizable. Any sequential dependencies among those tasks limit the effectiveness of parallelization. This is exactly what Amdahl's Law says.
> my humble laptop can do 8 threads at once, it's about time we started building office suites and browsers to take advantage of these processors.
Multiple browser tabs or open office documents are trivially parallelizable (eg, processes). The work within those tabs or documents is not linearly parallelizable -- running JS/macros, handling input, rendering, etc. Existing browser/office suites already do a pretty good job of splitting these tasks up, but they can't be split up arbitrarily into $core_count chunks.
- rbanffy 12y ago> Only if the tasks are trivially parallelizable Which is a very common scenario on web and application servers, specially if you design your web applications to be scalable. > Multiple browser tabs or open office documents are trivially parallelizable They would be if I could pay attention to more than one tab or document at any given time. In reality, I spend most of my time with full-screen apps and there is little point to keep other tabs or documents running.
- joosters 12y ago> Which is a very common scenario on web and application servers, specially if you design your web applications to be scalable. Doesn't matter. You can (and probably will) still hit horrible bottlenecks in the network stack. Another flashback to developing on the 64+ Niagara cores. We were running an embarassingly scalable web application - loads of independent concurrent requests - but the Solaris OS just couldn't keep up. Has your NIC driver been optimised to scale for tens/hundreds of CPUs, I wonder?