[Beowulf] Re: Re: Home beowulf - NIC latencies
Many of your questions may have already been answered in earlier discussions or in the FAQ. The search results page will indicate current discussions as well as past list serves, articles, and papers.
Jim Lux James.P.Lux at jpl.nasa.govWed Feb 16 13:52:26 PST 2005
- Previous message: [Beowulf] Re: Re: Home beowulf - NIC latencies
- Next message: [Beowulf] Re: Re: Home beowulf - NIC latencies
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Beowulf] Re: Re: Home beowulf - NIC latencies
- Next message: [Beowulf] Re: Re: Home beowulf - NIC latencies
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Beowulf mailing list
