Quoting Douglas Roberts <[EMAIL PROTECTED]>: > If you go to any of the supercomputing centers such as NCSA, SDSC, or PSC, > you do not see parallel java apps running on any of their machines (with the > occasional exception of a parallel newbie trying, with great difficulty to > make something work). The reasons: > > 1. there are few supported message passing toolkits that support > parallel java apps, > 2. java runs 3-4 times slower than C, C++, Fortran, and machine time > is expensive, and finally > 3. there are well-designed and maintained languages, tookits and APIs > for implementing HPC applications, and || developers use them instead of > java.
I expect in the next few years some supercomputing niches will start to use hypervisors like Xen. By paying the 20% cost or so this will allow queueing systems like LSF to bring jobs on and off line with uniform checkpointing. It will remove the need for ad-hoc checkpointing code in applications by allowing any executable to be stored (much a laptop does when it goes to sleep) and/or migrated from one system to another. I would be very happy I could submit a job and have it run indefinitely to completion...instead of having it kicked out every 6-12 hours for manual restart or a procedure where I have to write scripts to figure out where things stand and adaptive resubmit. 20% is nothing compared to that inefficency! While there are well-designed and maintained languages for HPC (MPI and OpenMP), they are only the most basic of infrastructure. MPI is a pain to use and OpenMP requires a big SMP system. Maybe when there are Hypertransport cables and implementations of languages like Fortress or Chapel life will be better. (e.g. Infiniband hasn't resulted in useful and used distributed shared memory systems.) ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
