Slashdot Mirror
Big-Iron to Open Up for AMD
vincecate writes "Traditionally the key chips that have allowed companies to
scale multiprocessors to large numbers have been proprietary.
Some examples are the
Cray SeaStar,
SGI NUMAlink,
HP sx1000,
and the
IBM X3/Hurricane.
This proprietary paradigm is about to change to a more open one.
Two companies have developed key chips for
building large Opteron multiprocessors,
and they will be
commercial off-the-shelf parts.
PathScale has
released
InfiniPath
which can be used with an
Infiniband
switch to make
a high-bandwidth low-latency interconnect for a
supercomputer cluster.
The other company is
Newisys,
which
will soon release
the
Horus chip.
This chip will make it possible to build 32 socket
(64-core) shared memory Opteron systems."
... k, maybe not. Can't afford one anyway :-(
Real Daleks don't climb stairs - they level the building.
really a 'large number'?
A pizza of radius z and thickness a has a volume of pi z z a
My experience suggests that Suns compilers beat out GCC on single processor machines and more so on 8 and 16 processor systems.
I didn't realise that the compiler was involved in optimising code for multiple processors. I thought it was the programmer that had to do that. I must have been misinformed.
The benifit of Sun's mature sparc compilers might let you squeeze more performance out of a sparc box.
So are you comparing the Sun compiler and GCC on Sparc or Opteron because you don't make that clear? One would expect the Sun compiler to do best on Sparc since nobody else has ever been that interested in it.
If on the other hand, you are claiming that Sun have suddenly produced the best compiler for AMD's Opteron then I would like to see some more evidence.
but that's a high-speed networked cluster, not a shared memory one? A 32 or 64 way shared memory opteron cluster is a threat to Sun's big-iron Ultrasparc boxes, would likely outperform them
A 32-way SMP dual-core opteron box is a serious threat to Sun Enterprise boxes with 64 to 128 UltraSparc, even the hardware partitioning doesn't mean as much when you can just use two or more x86-64 boxes at probably less than half the price. For that matter, it also attacks HP's "superdome" Itanium2 servers and some of IBM's Power5 and Power6. The closed architectures and the proprietary Unix(tm) they run are in deep doo-doo
Hate to break it to you ...
I've worked for Banks, Airlines too
The all had BIG iron in the server rooms
These people are not doing lots of hard calculations
They are moving large amounts of data...
Clock speed doesn't matter that much in these cases.
I/O bandwidth is king for these applications
The fact that these machines are ULTRA reliable
Is a really big deal for these companies.
You can't just reboot you're entire banking platform
to add disk or fix broken hardware.
Processing power just isn't the point in these cases
Help! help!, the termites are eating my DRAM!!!
So I'm a big curious what is so vastly superior? Are you using Intel compiled codecs on AMD machines when you did your testing? Did you even do any testing? I'll admit I had some trouble getting things running smoothly with the Opteron box but the end results speak for themselves; especially when you move over to the 64bit world with 64bit capture drivers the Opteron blows away anything Intel has put out to date. Of course Intel 64bit support is slow as all hell right now so I'm sure that will change in the near future.
While you may have been burnt by AMD I will stick with them for the time being until Intel shows some signs of turning around their product offerings. I'm still curious how a processor has gone bad though. In my experience once you get back the first 90 days its smooth sailing regardless of manufacturer. Only reason I can think a chip would die later in life would be from a PSU failure or some sort of disruption. I've seen that happen, never just seen a cpu die though. Always some other component causing it.Of course this is getting off track from the article. The Opteron is very well suited for these large machines so I'll be curious how they perform in real environments like Oracle and DB2 setups. Opterons bandwidth improve the more processors you throw at it so it'll be intriguing to see the results.
I was curious too, perhaps the AMD optimized apps were better optimized that the Intel ones? Beyond that its also the fact that these Xeons could only do 32bit while the Opterons were running happily in 64bit. The biggest pain there was finding capture card drivers that worked and were natively 64bit. Viewcast makes that difficult, thankfully the Linux drivers worked.
I also might add that the test was a Dell PowerEdge 1750 vs an IBM eServer 325 and later the 326 with dual core which was even nicer. So Dell might just make slow servers while IBM makes em fast. I know I'm fairly impressed with the IBMs over the Dells. Many situations the Dells were choking and I replaced them with the IBMs and all was then smooth. Our webserver was a prime example. 72 million hits in a month the Xeon servers were maxing out. Replaced them with Opteron based IBMs and 186 million hits later they are barely breaking a sweat. 35% cpu with 32bit Windows Server 2003. I'm curious how the 64bit version will effect it since we're expecting 250-300 million hits in January. Going to be a good test.In any case, the Opterons have proved themselves around here. I had to fight for the first one and now all the owner of the company wants to hear is that there is an Opteron in the server he is buying. The systems are rock solid stable and even faster than I expected.
Another thought I had about the reason the servers performance might be different. The Dells had 3 10k rpm ultra 320 scsi drives in a raid 5 configuration while the IBM just has two SATA 150 drives in raid 1. So perhaps the raid configuration was slowing down the write times.Granted, not an ideal benchmark but its still pretty impressive the amount of power I can shove into a 1U server using the Opteron.
I know it's a non-traditional here, but I looked up the benchmarks when the dual core chips came out.
E.g.
http://www.anandtech.com/printarticle.aspx?i=2410
"Gaming performance is, currently, highly based on single-threaded performance and thus, we see no benefit from dual core. The thing to keep in mind here is that AMD's dual core solutions are closer to their fastest single core offerings in clock speed, so they end up performing more like their Athlon 64 counterparts in games - which has always been quite strong."
Look at Doom III, the fastest dual core chip runs slower than the fastest single core. In fact you can pretty much predict performance from clock speed, regardless of the number of cores. So you'd be better off getting the fastest single core chip if that's what you care about.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
No why -- just how the instruction mix turns out. One example is PostgreSQL. Where Opterons might be 15% in MySQL, MS-SQL, DB2 versus a Xeon at the same price range, it's 100%+ faster than a Xeon in PostgreSQL. One of the things noted was large context switching was a big penalty on Xeons so there's been an effort to reduce it.