New SGI Altix 3000

dlloyd writes "SGI has just publicly announced the Altix 3000 series of computers that can scale from 4 to hundreds of processors, with up to 64 processors per single system image. Processors each come in a C brick that has 4 CPUs. I/O is done though IX and PX bricks (12 PCI slots per brick, IX bricks have a base I/O controler and two ultra 160 disks inside), just like on the Origin 3900 series. Anything more than 8 CPUs (2 C bricks) is connected by R bricks, which route the NumaLink packets between nodes. The NumaLink network is good for an aggregate 6.4 gigabytes/sec to *each* node. That scales as you add more C and R bricks. Basically, you can think of this as SGI's origin 3000 series, except that it runs Linux and has Itanium2 processors. The performance and scalability is like nothing that has ever run Linux and is *far* ahead of the competition. For those of you who wonder why anyone would need a 64 processor Linux machine, many scientific and technical customers prefer running their code on large, single system image machines. Large single system image machines are also less labor intensive to maintain and admin, plus they work much better on code that needs to share memory and pass messages between threads (even myrinet and mpi is glacial compared to the SGI numalink network and running code multithreaded)."

Comments

SGI is still in business?

[yppiz]

What is keeping SGI afloat? Service contracts on existing machines?

--Pat / zippy@cs.brandeis.edu

Re:SGI is still in business?

[yppiz]

Thanks for the suggestion. So I did take a look, and the answer to the question "how are they staying afloat?" is "they aren't. They are steadily hemmorhaging money."

I posted my question because, as early as 1996 or 1997, it was clear that commodity machines were going to kill SGI. I'm just amazed that they're still alive.

Here's their income statement, balance sheet, and cash flow statement. As of today, For three out of the previous four quarters, they had sales growth (sic) of -20% or worse. The three analysts who cover this stock have a hold rating, which in analyst-speak means sell.

--Pat / zippy@cs.brandeis.edu

Why Linux?

[HeelToe]

I still don't understand why SGI has foregone such a great OS as IRIX. Why go with Linux? Just trendy, or does it really offer advantages for scientific computing?

But

[Anonymous Coward]

How many keys/sec?

Re:Signs of desperation?

[Anonymous Coward]

That's a lie. SGI has not dropped it's MIPS machines or it's IRIX operating system.

Last quarter IRIX 6.5.18 was released. MIPSpro compilers version 7.4 were released introducing C99 compliance and much better compliance with C++ standards. This hardly sounds like SGI is dropping MIPS/IRIX.

Brick processor

[intermodal]

I rather like the concept of this...no more trying to pair up older processors when you run across a board someone is getting rid of a few years down the road. I recall getting a couple dual-PII workstations a year or so ago, and finding a pair of matching (and working) processors to put in them was hell...this way I could have just searched Ebay or my parts stash for a single old part.

Isn't the issue in this area $/MIPS?

[mckwant]

I don't do this for a living, but it seems that $/MIPS is the only benchmark even worth discussing, so shouldn't one be able to put together massive clusters of boxen to do the same thing, only without the SGI price tag?

Correct me, because I'm almost certian I'm wrong.

Re:Isn't the issue in this area $/MIPS?

[pclminion]

If you have heavily interrelated datasets, like in just about any thermal dynamics/plasma/weather problem, then there is so much interdependancy between adjacent "cells" that each work unit needs information from adjacent work units constantly. Spread that system out on a cluster solution and you're DOA because your communications between boxes are horrendously slow, with latencies measured in milliseconds instead of nanoseconds.

You've obviously never actually researched how distributed finite-element simulations work, because you're absolutely wrong.

In most physical FE methods, each cell interacts only with its 6 nearest neighbors. Yes, the computation requires information that spans across cells, but there's no reason to assign a different CPU to each cell. The cells can be grouped into blocks and assigned to processors that way.

Remember that surface area increases slower than volume. As the sizes of your cell groups increase, there is more volume within them per unit surface area. And since data only needs to be communicated across the SURFACE of each cell group per simulation timestep, the method actually gets MORE efficient as you make the simulation bigger.

So your "obscene" number of transactions turn out to be highly localized in space, which minimizes communication overhead. In fact, if your cell blocks are box-like in shape, then each block requires only 6 logical communication links to the adjacent boxes. This could be realized by a traditional switching fabric, or with actual physical links.

Re:Signs of desperation?

[questionlp]

SGI did make Intel-based workstations that ran Windows NT/2000 that used all standard ports (ATX motherboard layout, Rambus memory, AGP video, et al)... particularly the 550 workstation. They also made several workstation lines that used proprietary memory and graphics subsystem that also ran Windows NT.

For a time... didn't SGI repackage Intergraph workstations as their own? They also had an Itanium 1 workstation that was nearly identical to HP's and Dell's Itanium 1 workstation... but I don't think many of those were ever made.

Price?

[s3xyb17ch]

Just curious, but did anybody notice an estimated price for various configurations either the 3300 or 3700? I couldn't find any price info on their site.

Re:SGI is finally making some new products

[davechen]

It is new. Find me another 64-node shared memory I64 Linux system. I'd much rather develop for a shared memory system than a message passing system. And for a lot of supercomputing apps, a Beowulf cluster just won't cut it.

IRIX is better for computational graphics than Lnx

[Anonymous Coward]

One of the reasons we continue to choose high-end SGI systems like the O3k series is because of the way IRIX can do engineering/scientifical computational graphics. No one can compete with IRIX when it comes to things like fluid dynamics calculations. Many other vendors have tried, but none come close to SGI's capabilities. I sincerely hope they have continued their unique software in their Linux distribution.

Cool

[WindBourne]

As Linux gets into high-end systems, it will drive the industry to compete. Allmost certainly, Sun and HP will have to release high-end systems with Linux rather than trying to keep it on low-end only. Otherwise, it will be SGI and IBM only
Now, If a major would start using Linux in an innovative way rather than simply trying to lower their costs. That would help drive real sales.

Re:Cool

[larien]

A Sunblade 100 with minimum spec is $995 list. You can buy a PC for half that with similar or better performance. To get performance better than a P3/4, you're really looking at something like a blade 1000 which starts off at around $5,000 (off the top of my head).

Yup, the blade 100 is nice, but it doesn't have price/performance of Intel yet. What it does have is binary compatibility with an F15K, so you can run the same 64-bit app on your cheap-ass desktop as you do on the big iron in the data centre.

The poster is right; most hackers don't have a Sun on their desk as they are comparatively expensive. Given the choice between a $1000 Sun which plays very few games and has OK performance or a $1000 PC which will play 99% of games, what do you think the average hacker is going to buy?

MPI?

[Alex Belits]

even myrinet and mpi is glacial compared to the SGI numalink network and running code multithreaded

Don't mix shitty parallel computation libraries and actual performance. Multithreaded applications without MPI are, of course, faster than anything with MPI, however it says absolutely nothing about:

1. Multithreades vs. multiple processes.
2. Myrinet
3. Network programming
4. Clustering
5. NUMA implementations that reduce everything to SMP with a cache that gets flushed a lot

It's one hot machine!

[more]

Don't get it installed in your office! :-)

You can use the 64-processor version for not only the simulation of, but also for the real-life purpose of melting iron. A double Itanium2 HP ZX6000 is heating up my office like no computer before. When I turned the ZX6000 on, my daughters' self-made art (taped on the wall) started flapping in the warm air. To me it looks like Itanium2 is server room hardware, at least until we get the 130 nm version.

Re:IRIX is better for computational graphics than

[fitten]

Well... our experience with the O2K was a bit different (haven't touched an O3K though so I dunno much about it). With the Origins 2K and NUMA, if you ran large simulations, the distant memory would flat kill your performance so you had to make sure your working sets fit on a single node. Also, even though each processor board in the O2K had 2 CPUs, if you actually ran an even somewhat memory intensive process on each CPU, your app slogged because the memory bandwidth only supported about 1.4X the bandwidth of a single CPU. Another bad habit was that if someone snuck onto the machine when you were running your 64 process job and they fired up something like emacs, it would cause this nasty shifting around of memory that got you into the NUMA state mentioned above. Later, SGI came out with some tools that would minimize this effect though, which helped a lot.

So... in order to support the kind of stuff we did and run it on 64 nodes, we would have had to buy a 128 processor system because we would only run one process per node and all the nodes were two processors.

So, we also looked at the Sun10K. While the cpu to cpu comparison of raw crunch was lower, the memory bandwidth was uniform so the programs behaved predictably and were almost as fast in any case. It also had the benefit of running 1 process (as far as performance per process) wasn't noticably different from running 64 processes (on a 64 processor machine). At the time, the Sun10K met our needs much better.

Now, of course, all those have been shoved out the door and replaced by something even faster.