let's see some numbers [LWN.net]

let's see some numbers

Posted Apr 28, 2008 16:30 UTC (Mon) by zooko (subscriber, #2589)
Parent article: Interview with Donald Knuth (InformIT)

I generally agree with Knuth that the current excitement about multiple cores and new parallelism techniques is unfounded. But rather than argue theory, can we generate numbers? Does anyone have a machine in which they can swap out a CPU for another of like architecture but a different number of cores? Then we can measure the times to do things that we actually care about -- things like boot-up time, time to launch applications, speed of web browsing, responsiveness when using local interactive applications like text editors.

My guess is that these measurements would be slightly better or slightly worse (yes -- worse) when the multiple-core CPU is in, but probably they would be within the margin of error.

This wouldn't prove, of course, that some future software invention wouldn't make the system use multiple cores to advantage (nothing can disprove that hypothesis), but it would give us a way to find out if such an invention ever does work.

Other ways to measure besides "human holding stop-watch" might include LatencyTop or the recently announced Phoronix Test Suite.

In the meantime all of those people that are buying multiple core CPUs for their workstations, laptops, personal servers, etc. are probably just throwing away money.

My blog entry: https://zooko.com/log-2008.html#d2008-04-28-multiple_cores_considered_wasteful

Regards,

Zooko

(Log in to post comments)

let's see some numbers

Posted Apr 28, 2008 20:28 UTC (Mon) by drag (subscriber, #31333) [Link]

You can probably go into the kernel and disable support for more then one or two cores, then
enable them later and see if there is any difference. On a quad core machine, of course. Which
is pretty affordable nowadays, in terms of development machines.

let's see some numbers

Posted Apr 29, 2008 6:44 UTC (Tue) by graydon (subscriber, #5009) [Link]

For what it's worth, I regularly run testsuites and build jobs that are embarrassingly
parallel, so when I purchased a quad-core for work this fall, make -j made a nearly linear
improvement on this particular bottleneck in my work cycle. Didn't make me any smarter or
quicker with emacs, but made a half hour cycle between major edits collapse to about 7
minutes. That was very noticed. I'll happily support buying 256 cores on the same line of
reasoning, when they're available, because 7 seconds is much better than 7 minutes!

(And this is a tolerably fast job; I've had embarrassingly parallel workloads that take
*weeks* on the provided hardware. That's when you start snooping around for cross-organization
job queues and whatnot, to steal idle time from other machines.)

I'll grant that developers are probably not who the multicore "revolution" is aimed at. But
the numbers I've seen suggest that transaction-bound network servers of various forms see a
good win too: particularly those that were built around some sort of process-pool or
thread-pool model. More of the parallel thingies run at the same time. QED.