Why sparc?

[Carlis]

Sun charges like 3000 usd for a single core 1.3 ghz sparc station that is not faster than a 1.3 ghz of any thing else. Now, I know these machines are used in environments where cluster / server performance is what matters, but do sparc have any advantages towards x86 in server applications now a days?

 

[nonameo]

Doesn't sun offer Opteron servers now? I'd think that anyone wanting x86 or x64 would use one of those instead.

 

[firewolfsm]

Their OS is useful for some apps but they've been losing favor recently anyways.

 

[brassbin]

If you are simply talking about a typical workstation, then no, there isn't any advantage over a x86 system except for the fact that some niche apps are built for Sparc platform. Now if we are talking about a server, then Sparc scales much better than any x86 or x64 systems, AND CHEAPER.

 

[syadnom]

which 1.3 Ghz processor? the Niagra T1 or T2? if so then their 1.3Ghz processor is quite good at it's intended task. They are transactional chips, very very very good at large numbers of small transactions. think database, think web server. in its intended roll, a 1.3Ghz Niagra will spank a Q6600 without breaking a sweat. on the other hand, in general computing they are likely slower than their same speed core2 processor.

also, realize that your Q6600 is 4*2.4Ghz = 9.6Ghz aggregate while a T2 1.3 is 32*1.3Ghz = 41.6Ghz aggregate. Big difference.
that might be better stated that a T2 is 4 cores with 8 threads per core, something like ULTRA hyperthreading, or the big brother 8 core 64 thread. unlike hyperthreading though, the 'thread' is a real pathway through the core, not just a scheduling trick. it would be a better analog to say that a Q6600 is a 2 core, 4 thread CPU if you were comparing the two. 8 core T2 chips are litterally 8*4core chips on 1 package.

As a side effect, this is the extreme example of less but faster cores feeling faster than more slower cores. To a lesser extent, this is the current arguement of Q6600 vs E8400

_____

Id like to add that "Their OS is useful for some apps but they've been losing favor recently anyways." was true a couple years ago but Solaris10 is turning that around and is gaining steam. Solaris is a very nice unix with features that are unmatched in the server world except where those programs are ported over. Think DTRACE and ZFS.

If you ever get the chance to see a

 

[Carlis]

The 1.3 ghz chip I was refering to is UltraSPARC IIIi, 1.34 GHz found in the sun ultra 25 workstation. It was just an example of how expensive "exotic" hardware can be. Does the Niagara beat x86 when it comes to price performance as well?

If the sparcs scale well and has a good price performance and require less energy one would think they make great super computers...

 

[NXIL]

http://en.wikipedia.org/wiki/SPARC

Features

The SPARC architecture was heavily influenced by the earlier RISC designs including the RISC I & II from the University of California, Berkeley and the IBM 801. These original RISC designs were minimalist, including as few features or op-codes as possible and aiming to execute instructions at a rate of almost one instruction per clock cycle.

Supercomputers

As of June 2007, three of the world's top 500 fastest supercomputers are based on SPARC64 processors:

* Rank #178: Nagoya University Japan, PRIMEPOWER HPC2500 (1664 2.08 GHz processors), Fujitsu, 6860 GFLOPS
* Rank #290: National Aerospace Laboratory of Japan, PRIMEPOWER HPC2500 (2304 1.3 GHz processors), Fujitsu, 5406 GFLOPS
* Rank #414: Kyoto University Japan, PRIMEPOWER HPC2500 (1472 1.56 GHz processors), Fujitsu, 4552 GFLOPS

This list compares unfavorably with other processor architectures, which make up a much larger portion of the top 500 list. The SPARC processor family had 88 of the top 500 systems in June 2002, but has since lost popularity to faster chips from IBM, Intel, and AMD.

So: seems sort of like the same situation with AMD now: great CPUs, but, they have not kept up for whatever reason(s).

NXIL

 

[brassbin]

I would like to add the T1/T2/T5120...etc are the low end entry level server models.

 

[Markfw]

This is the breakdown of the top 500 as of Nov 2007 (most recent on the site)
Processor Family Count Share % Rmax Sum (GF) Rpeak Sum (GF) Processor Sum
Power 61 12.20 % 1791560 2292793 634894
Cray 2 0.40 % 30661 36775 2034
Alpha 1 0.20 % 13880 20480 8192
Intel IA-32 13 2.60 % 100193 161496 26044
NEC 2 0.40 % 44783 50176 5696
Sparc 1 0.20 % 6860 13844 1664
Intel IA-64 21 4.20 % 429437 499856 79616
Intel EM64T 320 64.00 % 3374374 5776210 550682
AMD x86_64 79 15.80 % 1174421 1706457 339273
Totals 500 100 % 6966169.82 10558086.75 1648095

IntelEM64T the leader by a longshot
AMD is number 2 ! (surprises me)

 

[Carlis]

Intel EM64T, thats core2, right? And the IA is ithanium if I'm not mistaken. I expected power to have more than 12.2%. But the IBM has much of the upper section, right?

 

[Griswold]

Originally posted by: Markfw900
IntelEM64T the leader by a longshot
AMD is number 2 ! (surprises me)

And why would it surprise you? Opterons are in many ways the superior choice in HPC over Intels current offerings due to design, not raw processing power.

However, this has nothing to do with the thread topic per se.

 

[Aluvus]

Originally posted by: Carlis
Intel EM64T, thats core2, right? And the IA is ithanium if I'm not mistaken. I expected power to have more than 12.2%. But the IBM has much of the upper section, right?

EM64T is any Intel x86 that supports the 64-bit extensions, inclusive of Xeons based on the Core microarchitecture (but also older Xeons).

IA-32 is Intel x86 without the 64-bit extensions.

IA-64 is Intel Itanium.

POWER is IBM.

 

[degibson]

I think there are only two reasons to go with Sun:
1) Vertical integration with support-- your complete HW and SW stack comes from one vendor (you can also get this from IBM, for more money)
2) RAS features for servers (you can also get this from IBM, for more money) =)

 

[degibson]

Originally posted by: syadnom
also, realize that your Q6600 is 4*2.4Ghz = 9.6Ghz aggregate while a T2 1.3 is 32*1.3Ghz = 41.6Ghz aggregate. Big difference.
that might be better stated that a T2 is 4 cores with 8 threads per core, something like ULTRA hyperthreading, or the big brother 8 core 64 thread. unlike hyperthreading though, the 'thread' is a real pathway through the core, not just a scheduling trick.

Clock speed aggregation is the wrong paradigm here, because it implies that higher is better. Pick any single-, dual-, or four-threaded application you like, and the Q6600 will absolutely destroy the T1 and T2, and it will likely destroy them even for 64+ thread apps -- the exception is a certain class of server apps that have so many dependent cache misses that superscalar techniques are useless.

The threading on the Niagara series (T1/T2) actually isn't its own path -- its more like very-fine grained context switching (say, every 2-4 instructions. Basically, Niagaras switch to another thread whenever there is a branch instruction, or when a load misses in the tiny little L1 caches). It is a much simpler scheduling trick than hyperthreading, which actually does simultaneously execute instructions from multiple threads.

 

[jones377]

The USIIIi is probably the crappiest processor, in terms of performance, to come out since Merced (Itanium 1).

 

[v8envy]

It's already been mentioned -- legacy binaries run on sparc. In addition, if your target environment is big Sun iron (and plenty of wall street firms run their back ends on Suns, still) your developers may need sparc workstations.

Also you can't compare USIII vs Intel clock for clock. USIII has a serious IPC deficit when compared to IA64. Even sun sales guys are pushing opteron workgroup servers to people who don't already have a big iron sparc installation. I'd guestimate single USIII 1.3 ghz == 800 mhz core2.

Suns are good at running a massive number of processes (not just threads) -- they're optimized for context switching and running Unix. If your workload is doing tens of thousands of transactions coming from every direction (e.g., web server, database) that architecture wins. Otherwise it's a big, expensive lose.

 

[Martimus]

Originally posted by: Carlis
Sun charges like 3000 usd for a single core 1.3 ghz sparc station that is not faster than a 1.3 ghz of any thing else. Now, I know these machines are used in environments where cluster / server performance is what matters, but do sparc have any advantages towards x86 in server applications now a days?

SPARC is not an x86 architecture, it is a Reduced Instuction Set Computer (RISC).

edit: I see that this question has already been answered a few times, so I will remove the rest of the post.

 

[Brunnis]

Originally posted by: degibson
Clock speed aggregation is the wrong paradigm here, because it implies that higher is better. Pick any single-, dual-, or four-threaded application you like, and the Q6600 will absolutely destroy the T1 and T2, and it will likely destroy them even for 64+ thread apps -- the exception is a certain class of server apps that have so many dependent cache misses that superscalar techniques are useless.

The threading on the Niagara series (T1/T2) actually isn't its own path -- its more like very-fine grained context switching (say, every 2-4 instructions. Basically, Niagaras switch to another thread whenever there is a branch instruction, or when a load misses in the tiny little L1 caches). It is a much simpler scheduling trick than hyperthreading, which actually does simultaneously execute instructions from multiple threads.

Good post. I was kind of scratching my head over syadnom's explanation of SMT in the Niagara, but this makes much more sense.

Originally posted by: Martimus
SPARC is not an x86 architecture, it is a Reduced Instuction Set Computer (RISC).

Being a RISC CPU/architecture is hardly an advantage in itself.

 

[Idontcare]

Originally posted by: degibson
The threading on the Niagara series (T1/T2) actually isn't its own path -- its more like very-fine grained context switching (say, every 2-4 instructions. Basically, Niagaras switch to another thread whenever there is a branch instruction, or when a load misses in the tiny little L1 caches). It is a much simpler scheduling trick than hyperthreading, which actually does simultaneously execute instructions from multiple threads.

There seems to be a disconnect between your post and SUN's marketing...

With 8 cores, each supporting 4 threads, the UltraSPARC T1 processor executes 32 simultaneous threads within a design consuming only 72 watts of power
http://www.sun.com/processors/niagara/index.jsp

Eight cores and eight threads per core accelerate throughput as shown by two world-record, single-chip SPEC CPU scores, based on tests that delivered 78.3 est. SPECint_rate2006 and a 62.3 est. SPECfp_rate2006. The UltraSPARC T2 processor has twice the thread count of Sun's UltraSPARC T1 processor, which recently set a world record on ten Sun Blade T6300 Server Modules delivering 8253.21 SPECjAppServer2004 JOPS@Standard
http://www.sun.com/aboutsun/pr...unflash.20070807.1.xml

 

[Brunnis]

Originally posted by: Idontcare
There seems to be a disconnect between your post and SUN's marketing...

With 8 cores, each supporting 4 threads, the UltraSPARC T1 processor executes 32 simultaneous threads within a design consuming only 72 watts of power
http://www.sun.com/processors/niagara/index.jsp

Eight cores and eight threads per core accelerate throughput as shown by two world-record, single-chip SPEC CPU scores, based on tests that delivered 78.3 est. SPECint_rate2006 and a 62.3 est. SPECfp_rate2006. The UltraSPARC T2 processor has twice the thread count of Sun's UltraSPARC T1 processor, which recently set a world record on ten Sun Blade T6300 Server Modules delivering 8253.21 SPECjAppServer2004 JOPS@Standard
http://www.sun.com/aboutsun/pr...unflash.20070807.1.xml

I don't know how SMT is implemented in the Niagara, but the above doesn't really contradict what degibson wrote. The CPU would be fed two threads, but instead of scheduling instructions from both in parallel, it alternates between them. I guess one could call it SMT since the CPU needs to be fed two threads at any time to achieve its full potential.

EDIT (I've read up...): Actually, it doesn't seem as if Sun calls it SMT either. They seem to refer to it mostly as "chip multi-threading". Looking at the UltraSparc T1, it's actually impossible for it to have SMT, since it's a single issue design. There simply aren't any extra execution units to utilize for parallel execution of a second thread in a given cycle.

And here comes the part were syadnom was somewhat right: The UltraSparc T2 has a dual issue design with two integer units. However, as opposed to HyperThreading, the T2 doesn't dynamically schedule instructions from any thread to any of the execution units. Instead it assigns four threads to each integer unit, effectively creating two separate paths (pipelines) for each thread group. So, it does infact execute two different threads simultaneously, but it's a much simpler approach than what Intel took with HyperThreading.

It's simply not fair to say that "T2 uses separate pipelines while Intel used a simple scheduling hack". The HyperThreading way of doing things can allow for much higher performance in less threaded scenarios, while (theoretically) retaining good throughput with more threads. The T2 way of doing things relies much more on applications or scenarios to be heavily threaded, since too few threads means that the already limited execution resources get underutilized. For example, in a single thread scenario, only one of the two integer units will get (inefficiently) utilized. On a a HyperThreaded Intel CPU, the large amount of functional units and the use of a superscalar, dynamically scheduled pipeline means that performance can remain high even with just one thread.

A good implementation of SMT (a.k.a. HyperThreading) with good load balancing between threads could possibly provide superior throughput over the T2. The main reason for not doing this would probably be complexity, which is something Sun doesn't want to deal with due to power and area constraints.

 

[Martimus]

Originally posted by: Brunnis

Originally posted by: Martimus
SPARC is not an x86 architecture, it is a Reduced Instuction Set Computer (RISC).

Being a RISC CPU/architecture is hardly an advantage in itself.

I didn't say it was an advantage, although it does allow for much more efficient code. It is an inherently more efficient architechture, but with so many advances on the x86 front, I can't say that it is really better since RISC doesn't have nearly as much R&D behind it.

 

[Brunnis]

Originally posted by: Martimus
I didn't say it was an advantage, although it does allow for much more efficient code.

Not really. x86 code should be more compact, since a single instruction usually "does more". The advantage of RISC comes at the hardware level, where the simple instructions make for a much simpler design. You can of course make a reasonably simple CISC design (compared to modern x86 processors), but performance would suffer, either due to low clock frequency or too many multicycle instructions.

 

[Martimus]

Originally posted by: Brunnis

Originally posted by: Martimus
I didn't say it was an advantage, although it does allow for much more efficient code.

Not really. x86 code should be more compact, since a single instruction usually "does more". The advantage of RISC comes at the hardware level, where the simple instructions make for a much simpler design. You can of course make a reasonably simple CISC design (compared to modern x86 processors), but performance would suffer, either due to low clock frequency or too many multicycle instructions.

Being a hardware guy, I was thinking of efficient code as code that does what you want in fewer clock cycles.

 

[Brunnis]

Originally posted by: Martimus
Being a hardware guy, I was thinking of efficient code as code that does what you want in fewer clock cycles.

Ahh, you mean "more efficient execution of the code" (not trying to be a smart ass, just clarifying). Yeah, a RISC design theoretically makes it easier to execute code more efficiently. However, the advanced frontends and RISC-like backends of all modern x86 CPUs makes this more or less a moot point. They've basically achieved RISC performance with CISC code density and they did it by throwing man hours and chip area at the problem. It may not be elegant, but it's impressive from an engineering point of view and it definitely works from a performance perspective.

 

[degibson]

Three quick observations:

1) Marketing != Truth (also, Marketing != Lies, necessarily) 'Simultaneous' isn't well defined.

2) SPARC != RISC -- it may be RISC-inspired, but any instruction set that has fmuld8sux16 or tagged add/subtract/set condition codes instructions doesn't get the term 'reduced' in my book. =P

3) I agree with Brunnis -- for all practical purposes, RISC v. CISC is a dead debate -- its mostly RISC under the hood, and x86 (VERY CISC) is the pretty clear winner at the ISA level. So everyone is right -- RISC is easier to implement in hardware, CISC is a more compact representation. The best of both worlds.

Edited to add observation #3.