[Irinikus]

After running a blender test as well as Quake 3 on my V880z, equipped with six UltraSPARC III's running at 1.2GHz, I was rather disappointed with the system's performance, to say the least. 

The MIPS and PowerPC machines that I tested seemed to perform much better, when it came to executing these tasks! (When you consider performance vs clock frequency.)

So the question is: What were SPARC CPU's really good for, or what special properties did they possess, which made it worthwhile to keep on producing them?

[jpstewart]

There are many variables that come into play when benchmarking machines.  Keep in mind that something like Blender might not be very well optimized for SPARC at the source code level.  Plus the compiler used might not be producing particularly well optimized machine code from that source.  You might get different results using a different compiler (e.g., Sun Studio might outperform GCC) or benchmarking software that was written specifically for SPARC.  Those are just two possible reasons for the disappointing performance you've witnessed....

In addition to that, it's possible (even likely) that the SPARC CPUs weren't used for their performance, especially not in the era of your machine.  Earlier SPARC systems than your V880 performed well compared to their contemporaries, from what I've heard.  After that some sites continued to use SPARC simply because that's what they were familiar with.  

A lot of money was invested in the overall architecture of the machines to build reliable systems for the data centre, and the Solaris OS was built to match.  So some sites would choose SPARC and Solaris not for raw performance but for reliability reasons.

[vishnu]

Here's Sun's datasheet on that CPU:

http://datasheets.chipdb.org/Sun/UltraSparc-III.pdf

You might want to try re-running the test and monitoring the process with prstat to see how much use it's making of all that hardware...

[Titox]

What were the strong points of the SPARC CPU design?
None, pure advertising and the little desire to change platforms in large companies with gigantic maintenance contracts and in-house Solaris software.

The same Intel Sun servers were a lot more powerful than the Sparc ones in that era. I bought a Sun Blade 1500 at the time of my Fuel and It was very dissapointing, very noisy and slow. Low specs graphics cards, etc.

I also have Netra and Sun Fire and any Intel -or AMD- server is way faster with a fration of the cost, even Sun Cobalts are better servers.

[Raion]

SPARC always has had extremely parallel workloads that focus on high thread counts. Tbh anything before Fujitsu's SPARC64X is not really competitive for GP.

I have a SPARCVIII Fujitsu at my friend's server farm and it does decently well. Think performance of a decent Nehalem.

[escimo]

I don't know how the software mentioned (Quake 3, Blender) are written in case of parallelism by using instruction set extension (e.g. VIS) and special purpose libs (e.g. Sun Performance Lib, OpenMP, ...). So it's hard to quantify in excuse with the user's experience/feeling, better by analyzing the program behavior at runtime (metrics) more precisely and/or take a look into the sources.

Until new arrival of competiting techs by Intel/AMD Sun systems were quite popular by running EDA, MCAD, pre-press, technical documentation, network and database applications with footprints much heavier as a x86 server was able to achieve at this time and with the same price point.

Also Sun was never a "real" competitor in the graphics area, even though Sun offered some innovative and reasonable graphic products for their customer base, e.g. VX/MVX, GX, GT, ZX (Leo), Elite3D, XVR-4000 for hardware, pixrect, XGL/XIL for software, compared to other vendor products (e.g. SGI Infinite Reality for HW, OpenGL for SW).

The idea to use a register file with reg windows the SPARC ISA wasn't bad at the time, if looking at the source code and runtime level for technical apps. But the realization was maybe not as good as it was intended to be (e.g. some regs are locked exclusive to the OS for calls/returns, #func args <6, win over/underflow handling) and easiest to understand. Once SPARC systems (hipe "RISC") performed better than any mk68030 or i386/486 (CISC). Sun tried to get better performance by implementing ILP into their CPUs using them as large SMP shared memory systems (SPARCserver 6x0MP -> sun4m), introduced multi-threading mechanisms by splitting heavy procs into smaller and mem-shared pieces and binding these to LWPs which were distributed by Solaris 2.x to all CPU's available. That followed by ... as well as all other vendors (SGI, HP, IBM and Intel/AMD running on MSW, GNU/Linux) did. And the story is still going on.

[vishnu]

My Blade 2500 with two 1.6GHz UltraSPARC IIIi and an XVR-1200 has always run Pro/E Wildfire 4 really, really well...

[stormy]

Irinikus, you mentioned poor Q3 performance on a 6 processor system, did you enable multiprocessing in the engine? The command is r_smp 1. You might need to add it to the autoexec.cfg.