A group of people I associate with found a SW development environment that they fell in love with.  After a year or so they outgrew the environment (performance-wise; not, unfortunately, experience-wise).  They rushed headlong into a campaign to expand the computational capabilities of their "happy place".  The resulting undirected activities produced a year's worth of mostly wasted effort, after having pursued an ill-advised parallelization scheme that was intended to increase the size of problem they could run with a "New HPC-Happy Place".

So here's the cautionary bit:  what the above-mentioned group *should* have done once they bumped up against the computational wall that was an intrinsic feature of their selected development environment was to stop.  Regroup.  Determine what the next performance level was intended or desired to be.  Then, they should have developed a set of requirements that bounded the desired performance characteristics of the new improved system.  Then, they should have researched what existing and near-term parallel technologies had a good chance at satisfying those requirements.  Instead of doing this, unfortunately, they rushed head-long into the first attractive-sounding opportunity that surfaced (not a a multi-core box, in this case; rather, one of the team members decided to attempt to produce a Java-based re-imp of MPI).  These guys have wasted a year so far with little to show and few near-term prospects.

Making the transition from a serial application to a parallel version is a process that requires a fair degree of formalism, if the goal of the project is to produce a production-ready version that can handle the larger problems.  On the other hand, if an on-going research project is all that is intended  (Ohh! Let's see where this goes!  Ooh, I spot another Holy Grail over there!), than a different approach entirely is suggested.

--Doug
--
Doug Roberts, RTI International
[EMAIL PROTECTED]
[EMAIL PROTECTED]
505-455-7333 - Office
505-670-8195 - Cell

On 10/8/06, Marcus G. Daniels <[EMAIL PROTECTED]> wrote:
Carl Tollander wrote:
>     Buy one or two reasonably well tricked out multi-core machines
> early, don't go nuts on the HPC
>     requirements until we have a better handle on how to get one or two
> machines to make use of those
>     cores for the kinds of problems we expect to want to address.
>
Or something like this that takes Socket F Opterons...

http://www.microway.com/navion8.html

An upgrade to a quad core Opteron would make that a 32 processor system.
And you'll need to think about air conditioning once you got this many
processors.
A couple tons at least.

============================================================
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




============================================================
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

Reply via email to