12 ms·
IMHO if you need to break down a task well enough to run on a supercomputer, there isn't a lot more to do to make it run on a regular server farm. edit: Actual
by simi_ 11y ago
IMHO if you need to break down a task well enough to run on a supercomputer, there isn't a lot more to do to make it run on a regular server farm.
edit: Actually, in the scenarios you'd use a supercomputer for, the added latency and overhead (shoddy servers, network, etc.) would most likely make the run time orders of magnitude higher.
- apawloski 11y agoMaybe for embarrassingly parallel tasks, but if you require nontrivial interprocess communication, a server farm can't compete with the interconnect of a modern supercomputer.
- deleted 11y ago[deleted]
- deleted 11y ago[deleted]
- dekhn 11y agoThis is not remotely true for a wide range of codes that matter to the supercomputing industry.
- jakub_h 11y agoAnd by "codes", you mean specific legacy software artifacts written in FORTRAN (note that I'm not even spelling it as Fortran)? Of course that's a problem.
- dekhn 11y agoWhere to begin? There are many existing valuable codes written in FORTRAN. They work, it's not worth the investment to replace them with something else. Second, many of the codes are in C++, not FORTRAN. Not clear that's any less of a problem.
- apawloski 11y agoWrite in any language you want; that's irrelevant to the nature of the computations being done here. By codes they mean -- at the minimum -- pretty much anything that requires frequent communication between any or all nodes as a necessary part of computation. (For example, simulations across a large 3D space, where the changing states of particles on node A directly impacts the states of particles on adjacent nodes.)
- dekhn 11y agoYou can't write your code in any language you want on a supercomputer. Also, there is a wide range of literature about communication patterns for supercomputer apps; my argument is that often times, to solve the problem that matters, you may not actually need to run the simulation you think you do. It's more that people are just used to running that way. For example, with MD, you can run 1 sim parallelized over 100 machines using tightly coupled communication (doesn't necessarily mean the forces and positions of every particle have to be shared between node decompositions) or run 100 sims over 100 machines, with no communication except for input and output files. The latter can often answer the same question far more cheaply.
- apawloski 11y agoI'm somewhat confused -- I thought we were arguing similar points? I don't want to drag this out, but where do you see the language constraint? You need an MPI binding, sure, but what else?
- dekhn 11y agoNo, the people who run the clusters won't let you run any language just because it has an MPI binding. They invest a lot in ensuring peak performance, and right now, only C++ and FORTRAN can achieve that. Very few, if any, major supercomputer centers support Java codes.
- apawloski 11y agoOh, you're talking about a policy limitation, not a technological one. (And if you're talking about the DOE or NSF/Teragrid/XSEDE clusters, then you're probably right. Haven't touched those in years -- and even when I did, I wasn't doing anything crazy.)
- ska 11y agoNo, that means specific problem domains that are not easily partitioned, and where latency or affinity are the primary performance constraints. There are still some fortran libraries in large scale use for this sort of thing. They are still in use because they are very good, and replacing them would be very expensive for little gain.