Fwd: [Beowulf] small-footprint MS WIn "MinWin"

[Nathan Moore]

Your message misses the point.  If you're running an architecture that has
thousands of cpu cores on it, it is a colossal waste to run the normal set
of schedulers and deamons on every core.  The efficient use of such a
resource is to only bother with multitasking and the user experience on
nodes that the user will access - ie the compile/submit node.

With BGL/BGP you write code in C, C++, or Fortran and then send it to a
special compiler (a variant of xlc or xlf).  Given that a small job on a
Blue Gene is 512  nodes, you code will include MPI calls.  The core itself
is a PowerPC variant, so if you want to get into fancy stuff like loop
unrolling and the like its not a stretch if you're already familiar with
hand-coding for a Power architecture (think P-series, or Apple's G3/4/5
chip).  If you're unambitious :), IBM has a fast-math library for the Power
series that works pretty well...

In some sense BGL is the essence of a "compute" node.
NT Moore


On 10/24/07, Robert G. Brown <rgb at phy.duke.edu > wrote:
>
> On Wed, 24 Oct 2007, Robert Latham wrote:
>
> > On Mon, Oct 22, 2007 at 02:37:15PM -0400, Robert G. Brown wrote:
> >> If we really, truly, wanted to run our programs as fast as they
> >> possibly could, we wouldn't really use "a kernel" at all.  We would
> >> write bootloaders that ran our applications, each one custom
> >> compiled for a very specific hardware platform, directly on the
> >> hardware.
> >
> > This is pretty much exactly what IBM has on their bluegene compute
> > nodes.
>
> And I'll bet it isn't terribly easy to repurpose that computer as a
> consequence.  As in they probably require something like an assembler
> prologue and epilogue for any running static linked binary, and when I
> say static, I mean that ANYTHING that you might want to do had better be
> in that binary -- the binary probably needs to include its own small
> libc and/or libm or just be written in raw assembler throughout.
>
> IBM is rich.  They can afford to write a large, complex program in
> assembler or a "kernel-like" compiler-supported environment with
> assembler wrappers on a one-off basis, just to advertise their genius
> and product line.
>
> Normal mortals, however, no longer code much in assembler (even if in
> principle they know how), want the convenience of shared libraries (even
> if they aren't as fast as static linked, unrolled libraries), enjoy
> having a kernel to manage devices and interrupts and scheduling and
> timing and memory.
>
> The cool thing is that to the hard-core beowulf builder, this IS an
> extreme option, and all the other options discussed on this thread in
> between are there too.  So if you positively must be the fastest,
> expense be damned, boot into your task and strip out all the
> non-task-related code.  If the task requires a wheel you'll have to
> build it, possibly out of assembler, but when you are done and have
> hand-optimized it, you will be right up there as close to theoretical
> maximum performance as is possible for the task.  If you want to code in
> a day all by yourself what would take a team of programmers weeks to
> code the other way, having a kernel, a compiler, libraries are all nice.
> Similarly you have management tradeoffs that may or many not include
> single user operation (with a kernel) running X or not, running whole VM
> environments around your task(s) or not.  You get to do the cost-benefit
> calculation, taking into account your own time, abilities, and
> resources, and decide.
>
>    rgb
>
> >
> > ==rob
> >
> >
>
> --
> 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 <http://www.phy.duke.edu/%7Ergb>
> Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit
> http://www.beowulf.org/mailman/listinfo/beowulf
>



-- 
- - - - - - -   - - - - - - -   - - - - - - -
Nathan Moore
Assistant Professor, Physics
Winona State University
AIM: nmoorewsu
- - - - - - -   - - - - - - -   - - - - - - -

-- 
- - - - - - -   - - - - - - -   - - - - - - -
Nathan Moore
Assistant Professor, Physics
Winona State University
AIM: nmoorewsu
- - - - - - -   - - - - - - -   - - - - - - -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20071024/e3aee9d1/attachment.html>