November 17th, 2003

pixelated

(no subject)

What a domestic day I've had; hardly surprising given I haven't left the house. However, I'm feeling accomplished that teetering piles of junk (some of which dated back to the start of the year) are now either thrown away or filed, surfaces are clean, electricity company has been confused (current meter reading is below their estimate for the start of the billing period), and local entropy has generally been reduced.

Invited myself round to Owen's last night, which was enjoyable and pretty much the sort of party I wanted at the time.
pixelated

(no subject)

So, now they'll be shipping Opteron systems, how is Sun going to manage to not seriously embarrass their UltraSparc III line? CPU-for-CPU, the latest Opteron outperforms the latest USIII nearly 2:1 on SPECint_rate, and by 50% or so on SPECfp_rate, even given Sun's infamous 179.art compiler hack.

The UltraSparc IV is essentially a dual-core USIII, each core isn't going to be any faster per clock than the USIII, and it is initially going to be clocked at the same speeds. I suppose since Sun is shifting its focus at the high end toward lots of relatively slow CPUs by using multi-core everywhere, so it's actually not a bad fit to have their low-end SMP line look fast and cheap again by using Opteron. It probably means an end to the tradition of the Ultrasparc based E450/V480 type workhorses that Sun have made so much on. The move at the high end is arguably a good strategy, since the rate of gain in single-thread performance have been reducing for a while, and people have been used to writing somewhat parallel code.

Amusingly a dual CPU Opteron 248 system benchmarks very close to a (now fairly old) 14 CPU Sun Enterprise 4500 at SPECint_rate. It'd be interesting to see how it compares on more multi-threaded benchmarks.

I don't think Sun are quite dead yet, but between the monoliths of IBM & HP at the high end, and various x86 based servers eating the 1-4 CPU market, it'll take a lot of work and luck for them not to end up as another SGI, or another DEC.