[Beowulf] The Walmart Compute Node?

[Robert G. Brown]

On Thu, 8 Nov 2007, Jim Lux wrote:

> In general, a N GHz processor will be poorer in a flops/Watt sense than a 2N 
> GHz processor.
>
> The power draw is a combination of a fixed load plus a frequency dependent 
> load, so for the SAME processor, running it at N/2 GHz consumes more than 50% 
> of the power of running it at N GHz.
>
> If you go to a faster processor design, the frequency dependent load gets 
> smaller (smaller feature sizes= smaller capacitance to charge and discharge 
> on each transition).  The core voltage is also usually smaller on higher 
> speed processors, which also reduces the power dissipation (smaller number of 
> joules to change the voltage from zero to one or vice versa).  So, in 
> general, a 2N GHz processor consumes less than twice the power of a N GHz 
> processor.

In ADDITION to this is the fact that the processor has to live in a
house of some sort, and the house itself adds per processor overhead.
This overhead is significant -- typically a minimum of 10-20 W,
sometimes as much as 30-40 (depending on how many disks you have, how
many and what peripherals, how efficient your power supply, how many
fans you have).  Another complicating factor is that over the life cycle
of the processor it seems that when they are first released in silicon
they are very hot, but as they advance through steppings and VLSI takes
a step and they reengineer this and that they cool off somewhat, even as
the clock speed is advanced.  So you can't just look at the power draw
of a processor (say) six years ago at 1 GHz and multiply by three to
guestimate the power draw of a 3 GHz processor now, which is a good
thing as we'd have processors burning maybe 300 watts.

100 watts seems like a pretty solid upper bound for what anybody
releases a processor at, IIRC from over the various times I've looked at
per-processor draw (and I don't remember seeing any that spec'd out over
something in the low to middle 90's).  I'm guessing that this is a
physical limitation in terms of how much heat you can lose with a big
heat sink and fan, recalling that the E-Z Bake oven used to bake
brownies and cookies on the power output from a single 100 W bulb.  I
don't know if current multicores violate this rule -- I'd be a bit
surprised if they did, though, especially if it is a heat sink issue.

This has all been true since the very earliest days of beowulfery, and
from literally the 2.0.0 kernel on and the very first dual processor
boxes (my good old dual pentium pros) were cheaper in both FLOPS/$ and
FLOPS/watt (all things being equal, for EP tasks that were CPU bound,
not memory or network) than two UP pentium pros.  I'm sure that it is
still true now with multiprocessor multicores -- if your code isn't
network or memory bound in an SMP configuration (however SMP is
accomplished in terms of sockets vs cores) then higher clock is better
than lower clock, more processors/chassis (and hence fewer chassis
needed to reach any given number of FLOPS) is better than fewer, where
"better" means cheaper in gross power draw per FLOPS or IPS.  Often
better means cheaper in both system cost and administrative cost, but
CPU prices are of course highly nonlinear in e.g. clock speed and it is
almost always false for bleeding edge clocks where a single CPU can cost
as much as an entire system built on a "sweet spot" CPU in the same
family, for a 10-20% gain in clock speed.

   rgb

>
> Complicating this all is:
> a) A significant fraction of the load in a PC is all the other stuff that's 
> toggling back and forth, like memory address and data lines.  This will be 
> driven more by the FSB speed, which might be the same for the two processors.
> b) You may have a lower core voltage, but the regulator making that voltage 
> may or may not be as efficient.
> c) Power supply efficiency can vary a LOT from model to model.  All the way 
> from 50% for a really crummy design to 95% for a good design.
> d) Faster processors aren't necessarily architecturally identical to slower 
> processors. They may have different pipeline depths, different microcode, 
> different ALU strategies, etc.  It's not just a matter of shrinking the masks 
> and turning up the clock.
>
>
> Jim
>
>
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit 
> http://www.beowulf.org/mailman/listinfo/beowulf
>

-- 
Robert G. Brown
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone(cell): 1-919-280-8443
Web: http://www.phy.duke.edu/~rgb
Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977