[Beowulf] Re: vectors vs. loops
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.govThu May 5 10:18:11 PDT 2005
- Previous message: [Beowulf] Re: vectors vs. loops
- Next message: [Beowulf] Re: vectors vs. loops
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> >with the chickens the same money would buy. Not to mention the risk of >mad oxen disease... would that not be "Mad Ox Disease"? <grin> But Avian flu is much more contagious than Max Ox, so it might wipe out your flock. Perhaps 5%-10% would survive, being immune... so you'd still have some compute capacity, while your entire ox is dead. Maybe there IS a lesson here? genetic diversity in clusters is a good thing! (manifesting itself as different distros, different OSes, different CPU architectures). >The list tends to be tolerant as well of discussions of big iron, of >"oxen", of vector processors, of storage arrays, of networks, of shared >memory designs, of message passing software, of all sorts of HPC issues >even though the list address is NOT "hpc at hpc.org". It has come to be >more or less synonymous with HPC because of the enormous success of >cluster computing economically to the extent that it now dominates HPC, >but the two aren't really the same thing. It tends to be LESS tolerant >the further out there one goes away from the COTS part (especially if a >point is made obnoxiously), though, as the bulk of us are here because >of that mix of hardware addiction, infinite needs, and finite budgets, >and appreciate that this list is ABOUT COTS clusters if it is about any >single unifying factor. It has been known to (gently) ridicule even >COTS clusters that were built for the wrong reasons or with a silly >design process (usually as a showcase piece for some major vendor in >cahoots with some perhaps understandably greedy University department >somewhere, a hammer in search of a nail and a top 10 slot on the Top 500 >list). We also are very aware of Santayana's aphorism about history and repetition. Knowing what went before is very useful. If I hadn't thrown away all those old copies of Datamation from the 60s and 70s, I could probably make a good living writing columns and articles for the cluster trade press by just copying and changing a few names. "Today, Framostat Corporation introduced a New Batch Scheduler for OS/360, including dynamic job queue priority" or "Justify the ROI on your new system with improved job cost accounting systems. The new system accounts for CPU seconds, KiloCoreSecs, and I/O channel bandwidth, allowing efficient distribution of total system costs among your users" All clever and elegant architectures start to gradually get more complex and feature laden, until someone comes along with something radically new that fixes the problem. But even technical elegance isn't it's own reward. Nobody will argue that Intel's x86 CPU architectures are more elegant and clean than Motorola's 68K, but Moto's not making PC processors anymore, and Intel is. (A pox upon the segment register, and all it's ilk) I suspect that when Dave Cutler came to Microsoft to build Win NT, he had a vision of a nice clean multitasking operating system like RSX-11M or VAX/VMS or TOPS-10/20. But no, it had to retain compatibility with the CP/M heritage of MS-DOS and Windows, so that got grafted on, then this, that, and the other thing got rolled in (sometimes for decent technical reasons, sometimes as an anticompetitive measure). And nobody will claim that, underneath it all, *nix is any less freighted with the baggage of days gone by than WinNT, or, for that matter, whatever IBM's MVS is now called. They're all hideously complex, mind bendingly arcane at anything more than a superficial level, and so radically different in philosophy, that moving back and forth between them (which I have to do on occasion) is tedious and slow. Why can't we all just program little Rabbit Semiconductor superZ80's running uCOS? (http://www.rabbitsemiconductor.com/) 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: vectors vs. loops
- Next message: [Beowulf] Re: vectors vs. loops
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Beowulf mailing list
