Cray Introduces Adaptive Supercomputing

David Greene writes "HPCWire has a story about Cray's newly-introduced vision of Adaptive Supercomputing. The new system will combine multiple processor architectures to broaden applicability of HPC systems and reduce the complexity of HPC application development. Cray CTO Steve Scott says, 'The Cray motto is: adapt the system to the application - not the application to the system.'"

Comments

Good Motto

[ackthpt]

Cray CTO Steve Scott says, 'The Cray motto is: adapt the system to the application - not the application to the system.'

That's a good motto, but how often do you bend the will of your application, needs or business to the limitations of the application? I've been sitting on something for a couple weeks after telling someone "You really should have accepted the information the other way, because this new way you want it is highly problematic (meaning: rather than rip it off with a simple SQL query, I'll have to do an app)"

IMHO adapting to the needs of the user == customisationg, which also == money. Maybe it's not a bad idea at that! :-)

In certain cases, at run-time, the system will determine the most appropriate processor for running a piece of code, and direct the execution accordingly.

This assumes, of course, that you have X number of processors to chose from. If you can't do it, the answer is still 'throw more money at it, buy more hardware.'

my head is still spinning from all the new buzzwords overheard at SD West 2006.

Re:Good Motto

[Kitsune818]

They just left out the ending. It's really: 'The Cray motto is: adapt the system to the application - not the application to the system.'" Why? Because hardare costs more to change!"

Re:Good Motto

[Woy]

So true, but you gotta admit, we've seen much worse bullshit fly.

Re:Good Motto

[Jah-Wren Ryel]

This assumes, of course, that you have X number of processors to chose from. If you can't do it, the answer is still 'throw more money at it, buy more hardware.'

Except that in this case, one of the options they are promoting is FPGA - Field Programmable Gate Array - which can literally be adapted to the problem by reprogramming them. They are, in effect, an infinite number of processors to choose from.

Look to see FPGA's showing up as coprocessors on more prosaic AMD Opteron motherboards in the near future - Cray isn't the only one that thinks "FPGA on Board" is a good idea.

Re:Good Motto

[hey!]

This assumes, of course, that you have X number of processors to chose from. If you can't do it, the answer is still 'throw more money at it, buy more hardware.'

Uh, sure. That would be the assumption. Just like back in the day you had math coprocessor for floating point operations, and now it's on the chip; or disk compression duties used to be handled by a Stacker board. Or today you have a graphics accelerator to handle 3D video.

Sounds like a sound business too. Instead of having completely different models for, say weather modeling and cryptography, or choosing one task and being an also ran, you sell the same base system all around with optional coprocessors. If the coprocessor is transparent to your software, then in some applications the customer might benefit from only equipping some of his processors with coprocessors. Genreally, as a vendor you want to absorb all the customer's budget for the kinds of things you can sell year after year.

Re:Good Motto

[dildo]

It is possible to build comptuers that are optimized for certain kinds of calculations.

For example, Gerald Sussman of MIT (a computer scientist) and a Jack Wisdom (a physicist) decided they wanted to do long-term modelling of the solar system's evolution over time. Long time modelling of a multi-body system requires a fantastic amount of calculation. What is the best way to do it?

Sussman and Wisdom came up with a crafty idea: build a computer that is specially configured at the hardware level to do the modelling. Sussman and his colleagues decided that with off-the-shelf parts they could build a computer that would be just as or more capable of modeling this system than a supercomputer would be. The result was the Digital Orrery, a relativlely cheap computer that gave great results. (It is now featured in the Smithsonian museum.)

Think of it: if your computer is going to be doing the Fast Fourier Transform 6.02x10^23 times per day, why not build a superfast chip that does nothing but the FFT rather than express it as software? It's a pretty cool idea. I think this is the sort of thing that Cray computers claims to want to do with its motto.

Re:Good Motto

[Alef]

'The Cray motto is: adapt the system to the application - not the application to the system.'

Wasn't it essentially that motto that once gave us the CISC architecture, which most people today agree was't such a great idea...?

Re:Good Motto

[Doctor Memory]

Are FPGAs fast now? That was always the problem before: you could create a custom processor, but it wouldn't run faster than 15MHz. If your FPGA can't keep up with the data stream, then what's the point? You'd probably be better off trying to hand-roll some custom microcode for one of your commodity processors. It's not as flexible as a PGA, but it'll be faster, and may be more appropriate for certain classes of problems.

Re:Good Motto

[imgod2u]

Look on Xilinx's website. The Vertex4's (although currently having supply problems) go up to 500MHz (though you probably don't want to run anything at that speed considering that's probably the reg-to-reg limit). These things are literally better system-on-a-chip solutions than any ASICs could be considering what it offers. Integrated micro-processor, bus architecture, peripheral interfaces and non-volatile and volatile memory, with enough pins (BGA package) to expand with off-chip components. Actel even offers mixed-signal FPGA's where you can have your analog and digital circuitry all programmed onto one chip. These things are the future.

Re:Good Motto

[drinkypoo]

There are FPGAs over 250MHz now. There are times when such a beastie is useful. There are times when they aren't. Not sure why the hell you'd want to put this in a commodity PC though. It couldn't possibly help more than a second processor, which would be cheaper - or a second core, which would be cheaper still.

Re:Good Motto

[imgod2u]

FPGA's aren't the golden answer currently. Most if not all FPGA's have issues with being used this way. They are programmable, but they're not made or intended to be programmed in the field (despite their name). The majority have a programmable life of maybe 1000 flashes with flash-based FPGA's (ProASIC from Actel for instance) having a life of maybe 100 flashes. They're basically a poor-man's ASIC more than anything else. The technology would have to improve significantly in a much different direction than what the main FPGA market is targetted at before they can be used as adaptive circuit components while live.

Re:Good Motto

[de Selby]

Wasn't it essentially that motto that once gave us the CISC architecture ...?

No. I admit I'm no expert, but this is my understanding of it. CISC has several very good reasons (at the time) behind it:

1) Keep the code footprint as small as possible, since memory (disk and RAM) was expensive.
2) Try to factor out the most common "overhead" instructions (i.e. load and store) which many thought were actually crowding out the important code.
3) Make compiler writing easier (but not necessarily easier to optimize for speed).
4) Ease assembly language programming (but not necessarily optimization). And, yes, this does involve implementing a few common functions in hardware.

When the hardware changed (with memory becoming much less expensive) and the software changed (with far fewer actually writing in assembly) and people's needs changed (with speed becoming more important than just getting the program to fit on the computer), RISC grew to dominate.

Re:Good Motto

[Glenn R-P]

Cray CTO Steve Scott says, 'The Cray motto is: adapt the system to the application - not the application to the system.'

That's a good motto

Yeah. But having spent a good part of my career sweating over scientific
codes line by line to make them "vectorize" on the Cray, I wonder.

Re:Good Motto

[Alef]

The first argument I agree was a good one---it did reduce the code footprint.

However, the way I see it, points 3 and 4 (and possibly 2, depending on what you meant with "overhead") are basically attempts to do in hardware what can be done in software. Perhaps these were valid points at the time when memory was expensive, as you say, but at least in the long run didn't turn out to be very effective. Yet, we are still stuck with CISC processors because of x86 backward compatibility (although they internally are more like RISC processors).

I am certainly no expert either though, so please feel free to correct me on this.

Re:Good Motto

[superflyguy]

Cray makes supercomputers. While some 'supercomputers' may contain commodity PCs, they are not commodity PCs, and are generally described as 'clusters', not supercomputers. And cray does not make supercomputers out of commodity PCs. You wouldn't want to put it in a commodity PC, which is why nobody implied anything about commodity PCs until you pulled that connection out of thin air.

Re:Good Motto

[RKBA]

How about if you want to do arithmetic on 704 bit integers? Sure, you can break it up into smaller chunks and do multi-precision arithmetic in software on a general purpose computer, but with an FPGA you can simply declare whatever bus width you want and define whatever processing architecture you need for a given task.

Re:Good Motto

[Decker-Mage]

Oh, I don't know about that... The new IBM Blade Server-H has swapable blades that can be hot swapped between Xeon and Power PC blades so you can reconfigure on the fly. Later on this year they will be adding Cell blades to the mix for calculation instensive requirements.

Re:Good Motto

[vellella]

Um, no... Most FPGAs (Xilinx and Altera being the leaders) are static RAM based so can be programmed an unlimited number of times.

Re:Good Motto

[nickptar]

Not out of thin air. Look several posts up.

Re:Good Motto

[petermgreen]

dunno about other makes but i know the xilix spartan 3 fpgas are ram based and reprogrammed on every startup. I believe this applies to xilixes higher end fpgas too.

the problem i see is that place and route processing of a design is SLOW so you would have to be running a pretty long job for customisations to be worth it.

Cray?

[Eightyford]

I didn't even know Cray still existed. Maybe it was Sony's "emotion engine" that almost killed them. ;)

Re:Cray?

[Kitsune818]

If you are going to link something, maybe it should at least reference something relating to what you are talking about in that context. What does the EE have to do with Cray? The wikipedia article does not mention them.

For instance, John F Kennedy.. I'm sure he had emotions. What does that have to do with anything?

Re:Cray?

[Luthair]

Its a joke, before PS2 came out Sony was claiming the processors had crazy power and would be displacing super computers, etc.

Re:Cray?

[Anonymous Coward]

U R 50 pwned!

Coolest Looking Supercomputers

[Eightyford]

Cray always made the coolest looking supercomputers. Here's an interesting bit of trivia:

The Cray T3D MC cabinet had an Apple Macintosh PowerBook laptop built into its front. Its only purpose was to display animated Cray Research and T3D logos on its color LCD screen.

Re:Coolest Looking Supercomputers

[Rob T Firefly]

Who says you can't combine a Cray and a portable!

Re:Coolest Looking Supercomputers

[morgan_greywolf]

Another interesting bit of trivia. Apple Macintoshes have been designed using a Cray. What's even more ironic is that according to that same link, Seymour Cray used a Mac to design the next Cray.

Re:Coolest Looking Supercomputers

[Anonymous Coward]

Ah, that's nuthin'. Mr. Scott used a Mac to repair the Enterprise, and Jeff Goldblum used one to repel an alien invasion!

Re:Coolest Looking Supercomputers

[seven of five]

what's even more ironic is that according to that same link, Seymour Cray used a Mac to design the next Cray.

So how long will people continue to be in the loop?

I, for one, welcome our self-designing, etc, etc ..

Re:Coolest Looking Supercomputers

[flaming-opus]

They used to, and the X1 still holds true to that. If you take the skins off, it is a marvel of stainless steel, plumbing, and just plain fantastic mechanical engineering. The Xt3 and mta, however, are just more rectangular racks. The xd1 is just a dull 3u rackmount.

Re:Coolest Looking Supercomputers

[kaszeta]

Cray always made the coolest looking supercomputers.

I used to regularly work in a lab where I walked right by a Cray-2 with the Fluorinert waterfall. Pointless, but cool looking.

Re:Coolest Looking Supercomputers

[barronVonBackstabber]

I used to sleep on a Cray 1 X/MP during night shifts, nice warm seats. I remember the demo Cray 2 had plastic goldfish in the cooling tubes, pretty cool at the time.

Go AMD

[dotfucked.org]

"All of these platforms will use AMD Opterons for their scalar processor base.'

Im just loving the vendors picking up on AMD.

Their idea seems very interesting in theory. It sounds like HPC's version of the math co-processor->crypto accelerator idea.

And at least they are not basing the userland on Unicos :)

Re:Go AMD

[Anonymous Coward]

And Linux. And Perl. And Python.

Complexity, current machines

[gordyf]

It seems like the idea of combining multiple architectures into a single machine is already being done -- we have fast general purpose CPUs (single and dual core x86 offerings from AMD and Intel), paired with very fast streaming vector chips on video cards, which can be used for other non-graphical operations like a coprocessor.

The only difference I see is that they're relying on an intelligent compiler to decide which bits to send to which processing unit, but I'm not sure how much faith can be placed there. Cray certainly has a lot of supercomputing experience, but relying on compiler improvements to make or break an architecture doesn't have a good track record. I'm curious to see how they fare.

Re:Complexity, current machines

[TubeSteak]

The only difference I see is that they're relying on an intelligent compiler to decide which bits to send to which processing unit, but I'm not sure how much faith can be placed there.

If you read further into the article, you would have noticed TFA talks about a new programming language called "Chapel".

Chapel was designed as a language for rapid development of new codes. It supports abstractions for data, task parallelism, arrays (sparse, hierarchical, etc.), graphs, hash tables and so on.

So, they aren't relying on a just a compiler, even though they are going to support "legacy programming models."

Re:Complexity, current machines

[morgan_greywolf]

Cray certainly has a lot of supercomputing experience, but relying on compiler improvements to make or break an architecture doesn't have a good track record.

Seriously. Just ask Transmeta. Or Intel (think Itanic).

Re:Complexity, current machines

[flaming-opus]

They really aren't rellying on compiler improvements, so much as passing the code through their vectorizing compiler, and a tool for generating their fpga codes. If the code optimization for these 2 steps fails to optimize very much, you bail out and send it to the general purpose (opteron) processors.

Your being fairly pedantic about the computer architecture anyway. Yes, pairing multipe processor types together is not new, but most mpp supercomputers use identical node types.

The jist of this story is simpler than it sounds. Cray has 4 product lines with 4 cpu types, 4 interconnect routers, 4 cabinet types, and 4 operating systems. They would like to condense this down. The first step is to reuse components from one machine to the next. There are distinct advantages for keeping the 4 cpu types for various problem sets, but most everything else could be multi-purpose. From the sounds of things, it's using the next generation of the seastar router in all of the machines. Thus you use the same router chips, cabling, backplane, and frame for all the products. This reduces the number of unique components cray has to worry about. If they go to DDR2 memory on the X1 and mta, that further simplifies things, though I suspect they won't.

Well, once you share parts, why not make a frame with a bunch of general purpose CPUs for unoptimized codes, and a few fpga or vector cpus for the highly optimized codes? It allows customers more flexibility, and introduces cray's mid-range customers to the possibility of using the really high-end vector processors currently reserved for the high-end X1 systems. It's also a win for the current high-end customers. On the current X1 systems, you have these very elaborate processors running the user's optimized application, but the vector cpu's also end up running scalar codes like utilities and the operating system. These are tasks the vector cpu's aren't terribly good at, and you're using a $40,000 processor to run tasks a $1000 opteron will do better. Even if the customer isn't interested in mix-n-match codes on the system, (which I'm skeptical any cray customer really is), you probably want to throw a few dozen opteron nodes into the X1's successor, just to handle the OS, filesystems, networking, and the batch scheduler.

Re:Complexity, current machines

[joib]

I wonder whether the Cascade vector processor will really be a stand-alone vector processor or actually a co-processor?

Paradoxically, I believe that the major problem in making a really good vector processor is in pushing the envelope in single thread performance as well (Amdahls law and all that). In comparison, parallelism is easy. So in that sense, it would make sense for Cray to rely on AMD and x86 market volume to get good single thread performance very cheaply, and then concentrate resources on making a good vector co-processor. AMD licensing cache-coherent HyperTransport might fit in nicely here as well.

Also, from the software standpoint a vector co-processor makes more sense. Or else you would need an OS able to simultaneously run on different hardware architectures, or you need a vector chip capable of executing x86 code (uh oh)?

Re:Complexity, current machines

[flaming-opus]

The X1 processor is already a coprocessor. Not in the sense that it's on a different piece of silicon from the scalar unit, but that the vector CPU's instruction stream is distinct from the scalar unit. In past cray systems, some cpu's used the same functional units for the scalar unit and vector unit, (T90) while some (J90) used distinct scalar units. The X1 is a vector unit bolted on the side of a MIPS scalar core, with synchronization logic, and multi-ported register files to support multi-streaming. I don't know what latency there is for the scalar unit reading/writing a vector register, but I can definately imagine a vector co-processor linked to an opteron with coherent-hypertransport. Maybe in black widow, rather than cascade. Cray has been cheering how much faster black widow will be at scalar codes, than the X1.

The trick, of course, is how do you get the opteron and the vector processor to share access to memory? No way does hypertransport have enough bandwidth to feed the vector unit. You don't want the scalar unit to have to read the memory through the hypertransport through the vector unit. Do you give them distinct memories that are connected in some form of numa?
The current X1 uses 32-channel rdram for 4 cpus. Assuming the black widow processor is twice as fast, and only 1 vector cpu per node: to provide the same bandwidth per flop, you need at least 12-channel xdr memory, or 4-channel xdr2. The opteron keeps going with dual channel ddr2, and has one hypertransport channel connecting the register files, one for numa memory, and one to talk to the seastar(s). Also, do the vector units and the scalar processors share the same interconnect controllers? You would want more than 1 seastar for each vector node, maybe 4.

Hmm. I'm sure there are technical hurdles a-plenty, but it sounds good on paper.

Supercomputing v Distributed Computing

[user24]

It seems the bulk of the article is bemoaning how ineffecient single processor systems are, offering Cray's planned adaptive model as a solution, but surely we've already seen the way forward in regard to supercomputing, and that is distributed single (or dual) processor machines. As stated at zakon.org, "SETI@Home launches on 17 May (2001) and within four weeks its distributed Internet clients provide more computing power than the most powerful supercomputer of its time"
Surely the computing environment hasn't changed so dramatically in 5 years as to make this type of achievement redundant?

Unless 'computing power' is different to 'combined processor speed', I don't understand what Cray are up to here.. perhaps someone can enlighten me?

Re:Supercomputing v Distributed Computing

[drinkypoo]

Unless 'computing power' is different to 'combined processor speed', I don't understand what Cray are up to here..

Well yes, they are very different. Processor speed is clock rate and tells you precisely jack shit about how much work can actually be done. Computing power is better measured in operations per second. Typically we measure integer and floating point performance separately. Even those benchmark numbers are usually pretty useless; hence we have the SPECint and SPECfp benchmarks which supposedly exercise the CPU in a way more similar to real-world use.

Re:Supercomputing v Distributed Computing

[amliebsch]

I don't understand what Cray are up to here.. perhaps someone can enlighten me?

Imagine a beowulf cluster of Cray supercomputers!

Re:Supercomputing v Distributed Computing

[user24]

so it's actually nothing new at all then, just two existing techs merged into one with a cool sounding name from a well known company. I see.

Re:Supercomputing v Distributed Computing

[user24]

ok, I shouldn't have said anything about processor speed. am I right in thinking that there's still no reason this adaptive approach will neccessarily be any better than a distributed project?

Re:Supercomputing v Distributed Computing

[drinkypoo]

Depends on how parallelizable the problem is. Clusters work well on jobs that are highly parallelizable, and in which there's small inputs for large outputs. Supercomputers are better for jobs with large data sets that are not easily split up into smaller pieces that can be sent to cluster nodes. The major advantage is that all the processors have direct access to main memory instead of having to fetch data across the network.

Re:Supercomputing v Distributed Computing

[Anonymous Coward]

Adding together all of the processors isn't enough unless you have something a lot like SETI at Home, where the data can be broken down into small chunks and be processed end to end from there. Imagine, for example if you couldn't do that and SETI had to load ALL their data onto your computer before you could start processing. Similarly, imagine that it wasn't possible to compute the solution for only a small part of the sky, you have to do it all at once. In those cases distributed computing, as you suggest it is not nearly so effective. It justs turns out that SETI had a problem that was very easy to break apart.

Re:Supercomputing v Distributed Computing

[Anonymous Coward]

You are, in fact, incorrect.

There are many problems which are embarrassingly parallel - 1024 computers will provide 1024 times as much processing power. This is NOT what Cray is going for.

Crays are built for problems like Molecular Dynamics, Nuclear physics, CAE, etc, which might require less than 10 microseconds in latency and multiple-gigabits of bandwidth in order to make even 2 processors quicker than 1, nevermind scaling to a couple of hundred CPUs per problem.

The Beowulf cluster community has been built around the fact that these sort of problems are relatively rare. However, Cray stays in business because the communities that do need such computing power have lots of big government support.

Re:Supercomputing v Distributed Computing

[fgodfrey]

No, you're not right.

You're ignoring one *major* element of scientific computing vs. something like SETI@home. SETI requires *very* little communication over the network and *no* communication between the peers doing the computation. The kind of scientific computation that someone would do on a high end cluster or supercomputer (say, a weather model or a model of an airplane) requires a great deal of communication and, even more important, synchronization. Think about what happens if you have 10,000 processors running your job and they all need to sync up once in awhile. If the time it takes to do the sync is a significant portion of the time between sync's, you are in big trouble. That is true more often that you would think.

So basically, if you're running SETI@home (or a distributed rendering farm or other similar things), you're not going to see much benefit from a high-end cluster or a big supercomputer. However, there are plenty of codes for which communication bandwidth and latency are *huge* issues. These are the kinds of things that get run on Crays.

I should also point out that there are many other factors that go into making a computer that performs well on a demanding application. Processor speed and architecture, memory bandwith, network bandwidth, compiler design, etc...

Re:Supercomputing v Distributed Computing

[flaming-opus]

"ok, I shouldn't have said anything about processor speed. am I right in thinking that there's still no reason this adaptive approach will neccessarily be any better than a distributed project?"

REally 2 different tools for 2 different problems. Distributed computing is really only useful for highly parallel tasks that require a LOT of computation on very little raw data. Furthermore, it has to be on data you don't mind shipping off to joe anonymous to be processed.

Current and future crays are typically run on modestly parallel tasks that use an enormous amount of raw data, do a lot of communication between nodes, and output a ton of intermediate and output data. Some of the machines use regular opteron processors, but they have 3 custom processor designs for specific problem classes that do not perform well on a general-purpose cpu. The interconnect offer multiple-tens of gigaBytes of bandwidth per processor, and latencies of a dozen microseconds. The CPUs have tens or hundreds of gigabytes per second of memory bandwidth. Equally important is that most crays are sold to either the department of energy, the department of defense, or their subcontractors. These systems are most likely not on the same network with any computer that is also connected to the internet. The data is almost certaintly classified.

By comparison: Distributed computing has bandwidth measured in kilobits per second, and latency measured in seconds. It may offer a lot of cpu's for little or no cost, but that's not appropraite for the majority of high performance computing tasks.

Incidently. The distinctions I draw are not unique to Cray. A lot of other supercomputers share high-bandwidth low-latency, and high-security. SGI also has put out a fpga blade that can be plugged into their altix supercomputers, which is pretty much the same as what cray is working on here. Cray just has a few more types of custom processors.

Re:Supercomputing v Distributed Computing

[Anonymous Coward]

As stated at zakon.org, "SETI@Home launches on 17 May (2001) and within four weeks its distributed Internet clients provide more computing power than the most powerful supercomputer of its time"
Surely the computing environment hasn't changed so dramatically in 5 years as to make this type of achievement redundant?

The problem is that *very* few problems work well in a SETI@Home sort of environment. Their system has worked extremely well for them, but most applications would run very poorly on such an enviroment. As a scientist, if I were to run my application on a SETI@Home type framework, I'd probably be long-since dead before I got my results. Even clusters aren't perfect solutions for all applications, which is why companies like Cray, IBM, and SGI still make more traditional supercomputers.

Re:Supercomputing v Distributed Computing

[Grotus]

It depends on the problem that you are trying to solve. Distributed systems are great for problems that can be broken up into a lot of unrelated smaller problems. They aren't so good when that isn't the case, as in climate modelling or nuclear explosion simulations.

I'll pre-order the next version

[Anonymous Coward]

so that I can play Duke Nukem Forever on it.

Co-processors anyone?

[TubeSteak]

After exhaustive analysis Cray Inc. concluded that, although multi-core commodity processors will deliver some improvement, exploiting parallelism through a variety of processor technologies using scalar, vector, multithreading and hardware accelerators (e.g., FPGAs or ClearSpeed co-processors) creates the greatest opportunity for application acceleration.

So they're saying that instead of faster/more generalized processors, they want several specialized processors.

Old ideas are new again.

Re:Co-processors anyone?

[sketerpot]

There are actually processors out there with compilers which can compile a few bottleneck C/C++ functions into hardware on an integrated FPGA. This expands the CPU instruction set in application-specific ways and can, in some cases, give absolutely enormous speedups.

In other words, they're working on processors which are programmed in general-purpose languages, but which adapt their hardware to the specific program.

This begs the question...

[__aaclcg7560]

So if I want to run Mine Sweeper, Cray will adapt one of their supercomputers to the requirements of this game? Sweet!

Re:This begs the question...

[Surt]

Heck, for just $10,000 I'd be happy to deliver you a supercomputer with terrific minesweeper performance.

Re:This begs the question...

[SpinJaunt]

What are the requirements for Mine Sweeper?

Cray CTO Steve Scott.

Re:This begs the question...

[irablum]

I'll bet if I have one of these things I can finally pwn people when I duel them in the common are of Ironforge. :)

Ira

Re:This begs the question...

[__aaclcg7560]

The operating system is Windows Vista and a fast supercomputer is needed to run the desktop interface ultra eye candy mode. Plus an extra processor to run Mine Sweeper. :P

I don't know about that...

[aussersterne]

I always thought that Thinking Machines deserved the award for most "I feel like I live in the future" cool in their computers with the CM5.

Re:I don't know about that...

[mclaincausey]

Ooooh, fascinating. LED lights...

j/k :P

Good Linux Journal Article On This

[dapantzman]

LJ had a good article on this a few months back.

http://www.linuxjournal.com/node/8368/print

Comment removed

[account_deleted]

Comment removed based on user account deletion

Cray as a company in general

[guildsolutions]

Cray as a company in general is amazing, they have been around forever and they dont sell bulk crap computers, go figure... The inspiration behind Cray is definitly worth a good study for future computer industry companies.

Re:Cray as a company in general

[SillyNickName4me]

The story is interesting, but also full of almost going under, being bought, sold, parent companies going bankrupt and what not..

The Cray we know now shares a name with the Cray that produced the famous Cray supercomputers of old, they also have some nice technology around, but there the similarities stop.

More pictures here

[aussersterne]

via Google image search.

building machines around problems

[deadline]

Cray finally figured it out. I have been saying for years:

HPC/Beowulf clusters are about building machines around problems

That is why Clusters are such a powerful paradigm. If your problem needs more processors/memory/bandwidth/data access, you can design a cluster to fit your problem and only buy what your need. In the past you had to buy a large supercomputer with lots of engineering you did not need. Designing clusters is an art, but the payoff is very good price-to-performance. I even wrote an article on Cluster Urban Legends the explains many of these issues.

Re:building machines around problems

[flaming-opus]

That's not really true either.
You only buy as much hardware as you need, but hardware is only half the cost of a computer like that. Infrastructure (physical, hardware, administrative, and management), software, and planning is a big part of the cost. Every time you install a capability-class machine, you plan for it several years in advance, make space/power/cooling available for it. Hire people to manage the machine. Port your applications to the machine. Install the machine, test and benchmark. Then administer the beast. There are a lot of unhappy owners of cluster machines in the capability class.

Where cluster have been very successful is in capacity class machines. These are the machines I work with. They are typically small clusters of 10-80 2-4cpu machines. HP and IBM have made a killing in this part of the HPC market. They often run off-the-shelf software like nastran or some-such. They are often not bought specifically designed for a problem, but are cookie-cutter purchases. They're cheap, so it doesn't matter if the machine is not 100% utilized. Many of my clients run more than one such cluster.

The part of the market to which cray sells computers is where the cluster paradigm has been only modestly successful. (not as powerful/efficient as promised, more expensive to buy/own/maintain than origionally anticipated) Clusters are definately worth considering in thiat space, and there are several vendors trying to sell clusters of that level. However, the cluster story is not so overwhelmingly powerful, as to eliminate full-on supercomputers from consideration.

Re:building machines around problems

[Anonymous Coward]

Did you even read the rest of the article? You're misrepresenting that quote. The line you quoted was telling of a shortcoming of clusters. Cray builds machines that cater to markets where cluster computers don't cut it.

And What If...

[Nom du Keyboard]

The new system will combine multiple processor architectures

And what if I don't want multiple processor architectures, but instead just lots and lots of the single architecture my code is compiled for?

Re:And What If...

[Surt]

Then buy one of the older designs built on a single architecture?
This announcement is telling us that they are planning to make new designs available which is not the same as saying that the old designs are no longer available.

Re:And What If...

[flaming-opus]

The idea is that all the CPU types will be blades that all use the same router, and plug into a common backplane, and that the cabinets all cable together the same way. In all cases, I imagine there will be opterons around the periphery, as I/O nodes and running the operating system. Then you plug in compute nodes in the middle, where the computer nodes can be a bunch more opterons, or vector cpu's, or fpga's, or multithreaded cpus. There will certaintly be plenty of customers only interested in lotsa opterons on cray's fast interconnect, and they just won't buy any of the custom cpus.

Re:And What If...

[fgodfrey]

Then you only buy one processor type (presumably the Opteron). As for precompiled binaries, assuming they meet the appropriate requirements (yet to be determined because predicting what API's will be necessary in a few years is pointless), they'll run just fine. However, optimizing for your target platform is likely to get you better performance regardless of whether the target comes from Cray or anyone else.

Adaptive = Adapting for Survive

[Anonymous Coward]

Some marketing type must have concocted the phrase, "adaptive computing". It is catchy but masks the real problems at Cray. Namely, general-purpose supercomputers built by IBM (powered by PowerPC), Fujitsu (powered by SPARC64), and NEC (powered by Athlon64) and powered by off-the-shelf microprocessors connected to standardized ultra-cheap chips built by slaves in Taiwanese factories based in China have essentially destroyed the reason for Cray's very existence. Cray's specialized machines may be slightly faster than the commodity-solution supercomputers from IBM, Fujitsu, and NEC but are significantly more expensive than the latter. In short, Cray's machines are a waste of money.

The "adaptive" in Cray's marketing slogan really means "adapting for survival".

Re:Adaptive = Adapting for Survive

[some damn guy]

Cray already makes systems based on many thousands of opteron processors. You can't beat them for scalar processing power. But what they also make,and still excel at, is specialized vector machines that can work with them. It's two good, but different tools for different jobs. The improvement is to make the two even more integrated and more flexible.

Execution

[Anonymous Coward]

Cray's big problem is execution and always will be with the incompetents from Tera still in mgmt.

The Red Storm system was greatly delayed and they incurred many financial penalties as a result. The last word was that it still had not met performance targets at Sandia.

Wow, adaptive computers...

[Anonymous Coward]

So do the splash screens of these new "adaptive" Crays say something like this?

"I am Cray of Borg. We will add your technological distinctiveness to our own. Resistance is futile."

Build to the application?

[ArcherB]

Cray CTO Steve Scott says, 'The Cray motto is: adapt the system to the application - not the application to the system.'

That seems like a good idea, but you end up with a "one trick pony" that does only one thing really well. Once that application is end-of-life or no longer needed, your million dollar machine is worthless piece of lounge furniture unless it can be reconfigured for some other application.

To me, it doesn't seem like a good investment. Then again, that's probably why I'm not building super computers!

Re:Build to the application?

[convolvatron]

i think a more precise interpretation would be:

(iteratively) adapt the system to the application (mix)

Re:Build to the application?

[alversjr]

I think the idea is to have pluggable "blades" that can be interchangable and reconfigurable for a task. So if you had a problem that required vector processing, you would remove all your scalar components (scalar based blades) and plug in components geared for vector processing (vector based blades). I assume the computer or compiler would figure out which part of the program to send to each component. So the idea is to be easily reconfiguration for whatever your problem happens to be.

Has to be said

[Aqua_boy17]

Wow! I'd sure like to have a Beowulf Cluster of...uhm...wait a minute.

Re:Well, that is what supercomputers do...

[vertinox]

That seems like a good idea, but you end up with a "one trick pony" that does only one thing really well.

From my understanding most supercomputers are built to do one task... Either it be fold proteins, simulate nuclear explosions, predict weather, simulate the big bang, or various other number crunching task. By the time they are done, they have to move to the next project... Mostly because of being out of date every 5 years.

And What If... You Actually Read The Article?

[porkchop_d_clown]

Because, if you did, you'd realize that this environment has it's own tool chain and isn't for pre-compiled binaries.

Buzz word.

[mtenhagen]

While I must admit "Adaptive Supercomputing" sound like a realy cool buzz word, in practice the programmer still will need to adapt the application to the physical distribution of the systems. Or are they going to dynamicly rewire the switches?

There have been several attempts (hpfortran, orca, etc..) to automate parallisme but most of them failed because a skilled programmer could create a much faster application within a few days. And remeber that a 10% performance boost in these applications means thousands of dollars saved.

So I suspect this is just a buzz word.

Re:Buzz word.

[scoobrs]

Did you RTFA at all?! The article is NOT about automatic parallelization by some special language. Most supercomputer customers are fully aware that writing applications which perform well for their supercomputer requires writing some form of parallel code. The issue at hand is that some specialized problems perform MUCH faster on one platform than another whether it's primarily scalar, vector, threading (hundreds, not two), and even FPGA. The goal is an intelligent compiler that can recognize code segments that perform much better in another architecture and utilize it across a single application in a hybrid system. That's no small task!

Re:Buzz word.

[wishnuv]

SGI Announced their version "Multi-Paradigm Computing" in July 20004. Cray is 2 years behind the game.
http://www.sgi.com/features/2004/july/project_ultr aviolet/

Re:Buzz word.

[flaming-opus]

2 years behind in announcements, let's see who brings it to market first.

Sadly the answer is that it's not even a race. SGI brought foreward their first step already, but won't get past that. You can now buy an fpga blade to put in your altix. While cray is just now announcing a unified vision for this, they've already had their fpga based solution since they bought octiga bay 2 years ago.

As much as cray is suffering financially, SGI is in much worse shape, and they have about $350million in debt around their neck, which makes them an unlikely target for a buy-out, at least until they go through bankruptcy for a while. I doubt that SGI has any money to spend on long-term engineering efforts like a vector cpu. They hopped on the fpga bandwagon because they could buy them from xilinks, slap a numalink on them, and stuff them into an altix with relatively little investment. Thus far cray has had a great deal of luck porting bioinformatics codes to the fpga in the xd1. (smith-waterman alignment, if anyone cares.) This is a market much more in line with SGIs market strengths and somewhat new for cray, who is used to selling machines with an entry-level price of $2million.

In any case, it's the logical path foreward for Cray's 4 product lines, even if noone combines vector, fpga, and multithreaded processors. They all benefit from being paired with opteron nodes, and from reducing the number of parts cray has to maintain. SGI is coming from the other direction, which is to add processor types to their interconnect foundation. It's still a good idea, but it's probably more capital-intensive than what SGI's capable off these days.

Re:Buzz word.

[mtenhagen]

So the compiler needs to decide which code to run on which cpu, that requires also deciding on which system data is stored and how communication is taking place. Basicly leading to the same idea as hpfortran.

If cray gets this working that would be great ofcourse but I doubt it. Combining several different cpu's is a good idea but this is already occuring. As noted in another reply SGI calls this "Multi-Paradigm Computing" which I consider as a much better buzzword.

Using 'adaptive' implies some sort of automated 'on the fly' process of deciding where run code. This has been tried several times and works but not without performace issues.

Re:Buzz word.

[mtenhagen]

Could give some more info about the 'smith-waterman alignment' implementation in fpga? Papers, code, etc..?

Re:Buzz word.

[scoobrs]

Cascade is expected to include heterogeneous processing at the node level , with fast serial, vector and highly multithreaded capability, all in the same cabinet.

They could've probably been more clear, since it was a bit of a dry read. The idea is a steady progression from heterogenous computing between nodes of different types to a tightly-coupled, single system with coprocessors on the same bus during Phase 3 for the government's Cascade research program due in 2009/2010. I believe that's nothing at all like hpfortran or SGI's program. I can't say any more because I'm on their compiler team.

Re:Buzz word.

[Anonymous Coward]

Papers, code, etc..?, how about vendor?

http://www.timelogic.com/decypher_sw.html (I know people who are happy with this stuff)

Old Story

[wishnuv]

SGI Announced their version "Multi-Paradigm Computing" in July 2004. Cray is 2 years behind the game.
http://www.sgi.com/features/2004/july/project_ultr aviolet/ [sgi.com]

Re:Old Story

[DrMindWarp]

Ah, someone on slashdot with a memory longer than a goldfish! Mod this up!

Re:Old Story

[LookoutforChris]

Just what I was going to say! Project Ultra-Violet is what they're calling it.

SGI has a 2nd generation product based on this: RASC, which is a node board with 2 FPGA chips that integrates (same access to shared memory) with the rest of the machines Itanium node boards.

Re:Old Story

[iggymanz]

heterogenous clustering and frameworks for parallel computing has been around at schools and labs for over 10 years, I really don't see what's novel about Cray's offering

Re:Old Story

[Anonymous Coward]

because its not a "heterogenious cluster" its a tightly integrated single machine (the SGI) with different types of processing element that can be applied to the same data

think

SMP -> NUMA -> NUMA (with different processing resources at each node)

I for one...

[n0mad6]

...welcome our new adaptive supercomputer overlords.

Re:I for one...

[Anonymous Coward]

How the hell did this get modded as a troll ? WTFOMGBBQ, these "overlords" statements have been requisite for any story/comments placed on slashdot since I started reading it. I think someone needs to get back on the short bus.

Cray

[Anonymous Coward]

Seymour Cray (the guy who started Cray) is from my home town (chippewa falls, wi) He would dig tunnels under his house and talk to gnomes when he was stuck on a particular system's problem.

He also had 2 awesome quotes:

"Memory is like an orgasm. It's a lot better if you don't have to fake it."
"If you were plowing a field, which would you rather use: Two strong oxen or 1024 chickens?"

Geniuses tend to be crazy.To bad he is dead. Interesting company from a interesting man

Sounds like SGI, sadly

[hpcanswers]

Cray and SGI have both been losing money recently as more users flock to clusters, which tend to be cheaper and more flexible. Now both of them are offering this "adaptability" position. SGI is moving in the direction of blades so customers can choose their level of computing power; Cray will soon have a core machine that customers can build out from. What's interesting to note is that both of them are ultimately selling Linux on commodity processors (Itanium for SGI and Opteron for Cray) plus a proprietary network and a few other bells and whistles. It seems unlikely they'll be able to compete LinuxNetworx or even *gasp* IBM.

Fast computing with many processors

[PingPongBoy]

6.02x10^23 times per day

Avogadro's number. I get you.

Also 1000 TFlops is still much much less than 10^23, which means the universe is very complex compared to computing power.

Now, it is possible to set up the networking between processors to compute a specific calculation quickly. There is an architecture called systolic arrays that basically treats unrolls a loop into a long pipeline. If you arrange processors into a grid and you chain certain processors together depending on the job they each have to do, you can run the loop many different times, each time with a different set of initial parameters. Generally you assume that the loop always has the same number of iterations (so you assign different sized grids to each of the different lengths of loops).

For example, a chess playing program can be assumed to search a similar sized tree for each move. Therefore, pipeline each possible move into the systolic array and the answers come out the end all in a bunch. The idea is that a general purpose grid of processors would take time figuring out where to send each intermediate result but a special purpose grid already has these decisions hardwired. Of course, chess is a fanciful example because there would be so many processors barking up the wrong proverbial tree that they would be wasted. Feedback loops could be used to reload search trees with useful searches once useless search directions are identified.

Multimedia processing where a large array of data needs to be processed is very appropriate for systolic arrays.

Re:Cray's Motto...

[Anonymous Coward]

Yes, go ahead, mod whatever's against your personal interests as flamebait.

What's next for Cray? The Cray Future!

[RabidTrucker]

Design the Cray to first read & analyze the software to be run + it's hardware requirements, then load it into a ROM chip specific to the Cray operation.