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