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 <[EMAIL PROTECTED] > 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@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 - - - - - - - - - - - - - - - - - - - - -
_______________________________________________ Beowulf mailing list, Beowulf@beowulf.org To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
