[Beowulf] Re: Re: Home beowulf - NIC latencies

Jim Lux James.P.Lux at jpl.nasa.gov
Wed Feb 16 16:52:26 EST 2005


At 12:03 PM 2/16/2005, Robert G. Brown wrote:
>On Wed, 16 Feb 2005, Vincent Diepeveen wrote:
>
>
>This (if true) is a shame, and is likely due to the assumptions that
>have gone into the implementation of the commands, some of which date
>back to big iron supercomputer days where the hardware was VERY
>DIFFERENT from today but ABSOLUTELY UNIFORM within a given hardware
>platform, so that "universal" tuning was indeed possible.  Maybe it's
>time to reassess these assumptions.  I am therefore trying to suggest
>that instead of "fixing" the collectives to work better for optimal
>latency at the expense of bw or vice versa (without even MENTIONING the
>wide array of hardware the same command is supposed to "transparently"
>achieve this miracle on) it might be better to work the other way -- add
>some very low level primitives that do little more than encapsulate and
>manage the annoying aspects of raw interfaces while still permitting
>their "direct" use.



>THEN implement PVM and MPI both on top of those low level primitives --
>why not?  The differences are all higher order interface things --
>ultimately what they do is move buffers across buses and wires, although
>the process would be made a lot easier if there were a shared data
>structure and primitives to describe and perform common tasks on a
>"cluster" between them.  A coder could then choose to "use a compiler"
>(metaphorically the encapsulated primitives) for some or all of their
>code and accept the default optimizations, or "use an assembler" (the
>primitives themselves) to hand-tune critical parts of their code,
>without having to leave the nice safe portable bounds of their preferred
>parallel library.  If done really well, it would accomplish the long
>discussed merger of PVM and MPI almost as an afterthought with teeny
>tweaks (perhaps) of the commands, since they would be based on the same
>primitives and underlying data structures, after all.

Isn't this what "self tuning" kinds of packages (ATLAS?) do?  Or, at 
another level, what those horrible MAKE scripts do that attempt to address 
every possible instruction set, hardware, glibc, etc. variation in 
existence (or that some bright soul took it into his mind to come up with 
one weekend after getting home from a Grateful Dead concert).



>Just dreaming, I guess. Possibly hallucinating.  That bump on the head,
>y'know.
>
>    rgb
>
>--
>Robert G. Brown                        http://www.phy.duke.edu/~rgb/
>Duke University Dept. of Physics, Box 90305
>Durham, N.C. 27708-0305
>Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu
>
>
>_______________________________________________
>Beowulf mailing list, Beowulf at beowulf.org
>To change your subscription (digest mode or unsubscribe) visit 
>http://www.beowulf.org/mailman/listinfo/beowulf

James Lux, P.E.
Spacecraft Radio Frequency Subsystems Group
Flight Communications Systems Section
Jet Propulsion Laboratory, Mail Stop 161-213
4800 Oak Grove Drive
Pasadena CA 91109
tel: (818)354-2075
fax: (818)393-6875


_______________________________________________
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf



More information about the Beowulf mailing list