I'm excited that it's going to be a Cray, as they have the best memory-to-processor architecture.
Scientific problems can be subdivided, but there will always be heavy communication between the processors. In particular global communication (a global sum for instance) is a killer. The more processors, the slower this operation will run, so for a big enough machine, this can actually dominate the cost. You get to a point where adding more processors does not make you any faster!
The Cray has a beautiful architecture, where one processor can put data straight _into_register_ on another processor. No cache and network delays. This is freakin' awesome. In Cray's presentation about the X1 they have an ocean simulation code that keeps scaling way beyond IBM, HP, &c machines, precisely because of the efficiency in global operations.
My disappointment is that they are only aiming for 50Tflop. The Earth Simulator hit 37 two years ago! This is no progress.
Victor.
Your CFD code is probably of a completely different nature than the Linpack benchmark. Most CFD is closer to Blas 1 which has no cache reuse, while Linpack is completely Blas 3, which is lots of reuse if you can code it the right way.
If I'm not mistaken, the G5 still has only a single precision AltiVec, while SSE2 is double precision. That means the G5 gets no help from the AltiVec (the linpack benchmark is double precision).
And if you're in East Tennessee where the Appalachian trail starts, try to visit the old Graphite Reactor in Oak Ridge. Built in 1943 or so, the oldest one after the experimental Fermi reactor in Chicago. Very cool to see all the old controls and the reactor room. (Oak Ridge was, like Los Alamos, a city built for atom bomb research.)
Do enquire way in advance, because it's part of Oak Ridge National Lab, which is a whole lot less accessible these days than it was before 9/11. It used to be drive up, walk in. Now there are guards everywhere. You probably have to book your visit.
Yes, floating point calcs are inexact. That's why numerical mathematicians for agest (well, since 1960-something) have been doing error analysis of programs. Basically, you show that your algorithm will not stray too far under small errors. Some algorithms that look entirely plausible do stray far, so those don't get used.
Packages that work exact (maple, mathematica) can run only at a fraction of the speed of numerical packages, so big simulations (how high should this airplany engine be mounted) are simply not done that way.
Anything like *what*? Octave is a very good Matlab clone (except that it doesn't do sparse data out of the box), but it has not symbolic math built-in. Maple and Mathematica are best for symbolic math, not so good for numerical work.
Different products completely.
(Matlab can have symbolic math, but I think they only give you a toolbox for accessing maple, which you need to purchase separately.)
V.
Slashdot Mirror
He was writing an _Algol68_ compiler as part of his Ph.D. work in _astronomy_?! I'm not worthy! I'm not worthy!
I'm excited that it's going to be a Cray, as they have the best memory-to-processor architecture. Scientific problems can be subdivided, but there will always be heavy communication between the processors. In particular global communication (a global sum for instance) is a killer. The more processors, the slower this operation will run, so for a big enough machine, this can actually dominate the cost. You get to a point where adding more processors does not make you any faster! The Cray has a beautiful architecture, where one processor can put data straight _into_register_ on another processor. No cache and network delays. This is freakin' awesome. In Cray's presentation about the X1 they have an ocean simulation code that keeps scaling way beyond IBM, HP, &c machines, precisely because of the efficiency in global operations. My disappointment is that they are only aiming for 50Tflop. The Earth Simulator hit 37 two years ago! This is no progress. Victor.
Your CFD code is probably of a completely different nature than the Linpack benchmark. Most CFD is closer to Blas 1 which has no cache reuse, while Linpack is completely Blas 3, which is lots of reuse if you can code it the right way. If I'm not mistaken, the G5 still has only a single precision AltiVec, while SSE2 is double precision. That means the G5 gets no help from the AltiVec (the linpack benchmark is double precision).
And if you're in East Tennessee where the Appalachian trail starts, try to visit the old Graphite Reactor in Oak Ridge. Built in 1943 or so, the oldest one after the experimental Fermi reactor in Chicago. Very cool to see all the old controls and the reactor room. (Oak Ridge was, like Los Alamos, a city built for atom bomb research.) Do enquire way in advance, because it's part of Oak Ridge National Lab, which is a whole lot less accessible these days than it was before 9/11. It used to be drive up, walk in. Now there are guards everywhere. You probably have to book your visit.
Yes, floating point calcs are inexact. That's why numerical mathematicians for agest (well, since 1960-something) have been doing error analysis of programs. Basically, you show that your algorithm will not stray too far under small errors. Some algorithms that look entirely plausible do stray far, so those don't get used.
Packages that work exact (maple, mathematica) can run only at a fraction of the speed of numerical packages, so big simulations (how high should this airplany engine be mounted) are simply not done that way.
V.
Anything like *what*? Octave is a very good Matlab clone (except that it doesn't do sparse data out of the box), but it has not symbolic math built-in. Maple and Mathematica are best for symbolic math, not so good for numerical work. Different products completely. (Matlab can have symbolic math, but I think they only give you a toolbox for accessing maple, which you need to purchase separately.) V.