Slashdot Mirror

Ah! That explains it. I knew Seymour Cray was working on a GaAs computer -- he had renounced silicon and was assembling some of the world's best GaAs equipment. So, that was bought by Tera

Here's the interesting part of my post: Tera replaced the 24 GaAs chips for one CMOS chip. Here's their blurb from the website:

----
Early MTA systems had been built using Gallium Arsenide (GaAs) technology for all logic design. Today, GaAs parts are predominantly used in cellular phones, not high performance computers. As a result of the semiconductor market's focus on CMOS technology for computer systems, there is little support for GaAs technology.

Cray's transition to using CMOS technology in the MTA will occur in stages.

In the first stage, a single CMOS MTA "Torrent" microprocessor replaces 24 GaAs ASICs that had represented 16 different ASIC designs. Torrent chips support up to 128 virtual processors, or threads, and will run at least as fast as today's MTA processors. A Torrent chip requires 50 watts of power compared with 1,000 watts for the GaAs design. The Torrent processor board requires 1,025 connections versus 14,400 connections on the GaAs board.
----

Somewhere else on their page they say the system is "Water cooled at 4KW per processor". So, even with the reduced-power CMOS, they are putting out a lot of heat!

No can do... We already named her after an old brand of supercomputers. Maybe the second-born, if there's one...

Some interesting papers on the design of the Cray (nee Tera) MTA (multi-threaded architecture) machine are here

If you like that, you'll love the Cray (nee Tera) MTA

Personally I like SUN's java-multi-threaded CPU concept ( even if it never succeeds ). Basically,
you have 4 parallel fully functional, non-related, non-pipelined, fully optimized functional units.
There are no resource contention issues, no scheduling problems, a simplified logic design. And
it's cheaper because you take away pipelining. The best part is that each of these extrememly
simple components are just cookie cuts. You spend all your time tweaking the hell out of one tiny
unit, then make 32 copies. Almost as easy as cache design.

Tera baby! 128 threads, hardware support for context switching, no L1 cache, no pipelining, no superscalar units.

Bascially, you context switch after each instruction. Since you have 128 threads, this hides all the memory latency. You gotta love that design.

Actually, for true multithreading, check out Tera supercomputers. Hardware support for multiple threads means threading is broken down to the instruction level. IE in one clock cycle it will execute an instruction from thread 1, then the next clock cycle it will execute an instruction from thread 2, and so on. This doesn't sound so great by itself, until you realize that by the time it gets back to thread 1, that memory request it made has completed and it is always ready to move on to the next thread (in fact if it isn't, it will automatically not schedule it until the memory request has completed). Effective Zero Memory Latency! Memory latency is the weak link in computing these days....really exciting stuff...too bad it's way out of normal user price range =)

Slashdot should do a story on Tera...

Very true, the primary bottle neck in computers these days is memory and network latency. I think that the advances IBM is showcasing here will really pay off though in decreased power requirements which are becoming increasingly important as embedded devices appear. and the combination of Processor and Memory is an extremely attactive option as it relieves requirements on the bus.

intersting work is being done in this direction under the Processor-in-Memory (PIM) project.

Another mechanism to decrease the effect of this memory latency is to use large numbers of low-level threads (often automatically generated by the compiler) to mask latency. By decreasing the context switch penalty to a single cycle (or less with interwoven threads) and then switching on every cache miss substantial benifits can be made. One example of this is Tera computing MTA architechture. For certain common simulation tasks the 4-processor TERA machine blew away a multi-node Origin and Cray computer according to This NASA report.

Also, Sun's new MAJC architechture uses threads to mask latency.

Interwoven threads (where the processor switches thread every clock cycle) has the benifits of removing branch and data dependancies from a processor pipleine, thus removing the need for processor complexity like data forwarding, speculative execution, and the like. An example of this technique can be found a the TIPSI Project.

One of the few references that I can find on the web is here in a 1990 paper.

Basically, this handwriting has been on the wall for well over a decade, and one can only hope that SGI recouped their investment in the first few years after purchasing Cray.

The Ars review incorrectly claims that Vertical Multithreading (switching threads at the hardware level when there's a cache miss) is unique to the MAJC architecture.

In fact, this is the basis of Tera Comupter'sMTA (Multithreaded Architecture) processors that are already being evaluated at the San Diego supercomputer center.

But then it could be just another Tera MTA...

Even an optimal caching strategy would still leave a lot of idle CPU cycles while the processor is waiting for disk.

Only if the CPU has no way to tolerate the latency involved. Go read about multithreaded architectures. The principal is that the CPU should never wait for a high-latency event to complete before continuing. Instead, it just switches to a new thread. Normally these threads are much lighter-weight than the POSIX variety, but they're of similar flavor. I do not know a good, on-line summary of the various types of multithreaded CPUs. If you're interested, look around U. Wisc., Stanford, and the ACM Digital Library for phrases like `multithreaded', `SMT', etc. You could also go to a bookstore and flip through Culler and Singh's ``Parallel Computer Architecture'' book for some now-slightly-dated info.

One of these machines does exist. It's from the Tera Computer Company. It has no data cache, and it's pretty fast for scientific-style jobs. IIRC, we were getting the equivalent of an 8-way UltraSparc-I on only one or two processors (argh, I really can't remember) on a list ranking benchmark. They're only considering the latency to memory locations (around 170 cycles, which is between 9 and 1.5 insn word opportunaties for a stream), but the general idea should hold for any high-latency event. The engineering for extremely high latencies probably gets trickier, though.

Expect multithreaded architectures in the higher end workstations within the next 3-4 years (at the longest). A certain up-coming architecture has the ability to grow in this direction pretty easily (I believe, haven't thought about it too hard), but one of the folks involved in the design was quite down on multithreading a few months ago.

Jason

Even if these folks had the compilers that would allow you to take large chunks of code, convert it into a hardware representation and program the FPGA to execute it you still have to get have some DATA to feed the instruction stream! The only people that seem to understand true parallel programming models seem to be the people at Tera Computer). They have the only architecture that can do a context switch on each instruction to allow the processors to execute those instructions that happen to be executable because the operand data fetches are complete. Everyone else (Compaq(DEC), Intel, AMD, Sun, SGI, etc.) consume huge amounts of chip real estate with primary & secondary caches rather than really solving the problem of memory latency. The old CPU/Cache IS DEAD in the long run (the chips get too hot). What will work are architectures like Tera's and/or approaches like " Processor in Memory"/" Intelligent RAM"/" Embedded DRAM" that are innovative ways of dealing with the problem of operand latency and memory bandwidth.

Even from the small amount of information published about IA64, it is clear that there is absolutely no support for automatic scaling simply by adding cpus. EPIC refers to the way each individual cpu decodes the instruction stream. EPIC is no more inherently multi-processor than the current IA32 instruction set.

To get automatic scaling, you need something like Tera's Multi-Threaded Architecture. Too bad they can't seem to ship the damn thing, and that it costs a couple of million.

See: http://www.tera.com/ for more info.