Slashdot Mirror
U.S. Helps Finance New Cray Development
Durinia writes "SGI has announced a few details on their next Cray vector supercomputer. The press release is mostly about them getting government support for the R&D. It does, however, mention that it will be combining the powerful Cray vector processors with SGI's ccNUMA architecture for big-time scalability."
A supercomputer doesn't have what you'd consider an operating system. It's a front-end computer that does all I/O, provides the usual operating system services, and controls the supercomputer. Linux is perfectly practical for the front-end. It would be nice to see a Linux in there.
Bruce, what are you talking about? I suspect you haven't seen a Cray machine for quite some time.
Most of the current Cray vector machines (like our T90) have their own OS (UNICOS) and IO subsystem. The IO's in a physicially separate box, like in a classical mainframe, but it's still part of the machine. There are generally a couple workstations (usually Suns) attached directly to the machine, but those are system consoles and monitoring stations. A Linux box might be appropriate for one of these monitoring stations, but that's about it. And if you think a Linux machine could handle the I/O that a Cray's capable of, you're insane. We're talking multiple GB/s.
The idea for the SV2 (as it was explained to us at a Cray User Group workshop last fall) is that it piggybacks on an MIPS-based SN1 (next generation SGI Origin ccNUMA machine). That implies IRIX (with features ported from UNICOS), not Linux. I doubt Linux on Intel or MIPS will be ready for the kind of prime-time SGI's going to be selling the SV2 for by the time they ship.
(Before you flame me for putting down Linux in this particular context, consider the following: I've been using Linux as my primary OS at home since '93, and I'm one of the guys working on the Beowulf cluster of SGI 1400Ls at OSC. I'm rooting for Linux too, but it's not always the right answer.)
"My life's work has been to prompt others... and be forgotten." --Cyrano de Bergerac
you need to remember that all these assumptions on the hardness of cracking keys depend on the fact that NP-Hard problems are not tractable in polynomial time...
this is only a conjecture as for now.
laurent
---
Dev elpizw tipota, dev phoboumai tipota eimai lephteros http://euclidian.org
Vector processing has one big advantage over massively parallel processing. Essentially, if you have a uniprocessor vector machine, and any appreciable amount of your code is vectorizable, you reduce total CPU time as well as wall-clock time. With massively parallel systems, you always pay for reduced wall-clock time with increased CPU time to synchronization overhead. A search on Amdahl's Law should turn up some interesting reading.
Looking back at some of my old documentation (~1990), I have these stats for a Cray Y-MP with a memory cycle time of 6 ns, and 2 FPUs/CPU:
1 CPU : peak throughput 333 MFLOPS
8 CPUs: peak throughput 2667 MFLOPS
These throughputs assume 100% vectorizable code. For the single CPU Y-MP running LINPACK with a vector size of 300 gets you 187 MFLOPS. However, with a LINPACK vector size of 1000, the throughput is 308 MFLOPS, which is approaching the peak throughput pretty closely.
I wish I had something that stated just how deep the vector registers are on a Y-MP. I suspect it's somewhere close to 100 (i.e., 100 stage pipeline!).
Anyway, this post is too long. Bye now.
Bill Wilson
The Keeper of Cheese
I'm a little amused by people asking for a comparison of the costs of a Cray SV2 compared with a Beowulf. For a certain class of applications, they remain dominant and some groups are willing to pay the extra premium for that niche, regardless of the absolute costs (and don't forget the cooling/storage/manpower multipliers). Much like a train (vector computers) is suited for different terrain than buses (shared-mem) or trucks (SMP), vector computers provide very cost effective REAL computing power, often obtaining 50-60% of peak performance whereas you'd be lucky to see beyond single digits for MMPs (and before I get roasted, I'd qualify that by noting decent compilers and reworking algorithms often overcome initial technical limitations).
:-).
As for the US support of Cray, well, jaded veterns of comp.sys.supercomputer and HPCC practitioners are well aware of the historical situation with federal funding, technical advantages and bang-for-buck comparisons with Fujitsu and NEC vector computers. For people interested in what the Japanese are doing, I believe NEC are planning on introducing a 1 Teraflop machine with the goal of hitting 5 Teraflops for their Whole Earth Simulator project . Some scientists' idea of heaven is a dedicated vector box and for their purpose and types of code, it is a valid desire.
The SV2 is a curious beast, effectively the first stage in the merging of the Origin cc-NUMA memory subsystem and vector chips. You can think of it as a hybrid box allowing various combination of graphics pipes, MIPS/Merced nodes and vector nodes. The gripe of some people is that they are looking for a successor to the top-end T90 and they are impatient. However, developing at the high end is always trickier than people expect (witness Merced) as you need to increase capabilities along a multitude of dimensions (memory latency, I/O subsystem, heat dissipation, networking) rather than relying from the automatic boost from Moore's Law. Unfortunately there are very few applications which demand absolute performance regardless of actual cost.
To paraphrase crass consumerism, if you have to ask about the price, you can't afford it
LL
For *some* problems, Cray is not the answer. For others, it is the *only* answer. Any *big* problem using lots of "vector operations" (see Bruce's post, it's kind of like the extra instructions that are just now getting added to the PC-style computers for multimedia, but *much* better) and lots of RAM at once and stuff is made for a Supercomputer. Oh, and anything that scales well to multiple processors, they have techniques of doing this too.
:|
:)
Supercomputer != Beowulf! Network latency sucks in comparison, for tasks like this. Only readily paralellizable tasks that *don't* need lots and lots of RAM at once, and *don't* benefit greatly from the vector operations are better for Beowulf. In fact, some cryptography problems have been mostly solved on regular computers and then finished on a Cray, *because* the Cray did that stage of the problem so much better.
Of course, it won't be Cray without Seymour.
It must have been nice to build a supercomputing couch, though, back in the day.
pb Reply or e-mail; don't vaguely moderate.
I'm one of the other posters who was wondering on the price/performance comparison.
One could very well chalk up the price difference towards reducing communications/messaging latency between computing units, cooling solutions, memory architectures, etc.
And hasn't it already been shown, for at least brute force algorithm cracking techniques, that massively parallel computing does work? So that a Beowulf is okay for such a system?
Of course this is different than using a more elegant and efficient algorithm to handle encryption/decryption attacks, but that is out of my/our ken as well.
-AS
-AS
*Pikachu*
It's also called "SIMD" (Single Instruction Multiple Data), and yes, it's been around forever.
It was discovered by some chip makers a couple of years ago (*grin*).
"Thank you Seargent...you may put away your tank."
---- Please be nice in case my Slashdot karma ~= my real life karma.
Thanks
Bruce
Bruce Perens.
Well how about a Beowulf cluster of G4s? Say using the publicized 1 gflop performance of the Velocity Engine, you'd need 1000 of them to get 1 teraflop and 10,000 to hit the 10s of teraflops, and multiples of 10,000 to hit a comparable multiples of 10s of teraflops.
That's $1600 each, or $16,000,000 per tens of teraflops.
It may be cheaper on PIIIs, but it would also take more PIIIs as well.
I'm assuming it's a headless network at $1600 each, btw.
-AS
-AS
*Pikachu*
Cheers,
ZicoKnows@hotmail.com
Bruce
Bruce Perens.
The way the market has been going recently, it was beginning to look as though US vector supercomputers were dead, and only the Japanese were still advancing them. The T90 was the last major vector machine, but had memory synchronisation problems with more CPUs. The SV1 had some interesting specs, but I don't know of any site which actually installed one - certainly press releases were thin on the ground.
Parallel machines, such as the Cray T3E, IBM SP2+, and to a lesser extent Beowulf clusters just give so many more Gflops/$. But as has been pointed out they are completely unsuited for some problems, for which you simply need all you power concentrated in a small number of CPU's.
My guess is that there is not enough market for a new US vector supercomputer, and the US government are stepping in so not to become dependent on imported hardware. If most SV1 installations are government, it might explain why we've heard so little about them.
BTW, many older supercomputers were single-user machines, which required a front end running a mutli-user operating system to schedule jobs. However all recent machines, including the C90, T90, T3E and I suspect the SV1 and SV2 run their own operating system (they are self hosting). In this case it is UNICOS, a Cray Unix which is gradually being merged with SGI IRIX.
Actually, I think the vector pipes on a Y/MP are something like 8 or 10 units deep.
These computers are designed for one type of calculation - matrix algebra, which requires simple processing (multiply, add, invert) on enormous 2D arrays of numbers. The important point: the working set of these problems is often the size of the matrices, so caches are ineffective. Cray vector machines do not have ANY data cache between the vector units and main memory.
The feature of most vector machines that no-one has really pointed out yet is the way the memory system keeps those vector units fed. Unlike a microporcessor which relies on 2 or more layers of cache, the vector machine is quite capable of streaming data from memory fast enough to keep the processor 100% busy.
The vector instruction results in a number of vector fetches being issued to the memory controller, which is told to fetch a strided vector from memory (start at address x, every ith word, n words in total). The memory controller issues requests to individual banks in an overlapping fashion. Like the vector FPU, after it gets over its latency it starts banging the words out once per clock cycle.
The way this is done is to have a huge interleave in the memory - Cray T90's use either 1024 or 2048 banks. So long as any one bank is not hit more than one per 100ns or so (the cycle time of the memory) the memory controller is capable of delivering multiple streams of 64 bit words at full clock speed (T90's can have up to 32 CPU's). Typically, to ensure this, arrays in programs are structured to stride along the first dimension (FORTRAN remember) or where this isn't possible, the array dimensions are chosen to be prime numbers.
The thing that sets these machines apart is not processor speed - the peak speed in MFlops on an NEC SX-5 is only about 2-3 times that of an Alpha AXP. The thing that makes them special is the memory bandwidth to sustain that performance.
To use my favourite automotive analogy, if a PC is a small hatchback, then a supercomputer is an 18-wheeler, not a Ferrari.
Just wondering, because another post wanted to compare one to, say, a Beowulf cluster.
If you use a G4 PowerMac and their highly advertised 1 gflop rating as a base, at $1,600 each, to reach a 10 tflop rating you would need 10,000 networked machines, so for each 10 tflops would be spending $16,000,000. I don't know how the comparable PIII or Celeron would perform though, or at what price.
16 mil is a lot to spend. But for government purposes it may just be a drop in the bucket.
-AS
-AS
*Pikachu*
It was always said in the supercomputing community that the US government would never let Cray die. Buying in supercomputers from Japan, the only other source of big iron, just wouldn't wash with the likes of the NSA.
First it was blocking the NCAR deal, and now this.