As part of the Sparc SuperCluster rollout yesterday, Oracle chief exec officer Larry Ellison let slip that the future Sparc T4 chip was coming out next year. Oracle and Fujitsu also announced a revved up Sparc64-VII+ processor for the Sparc Enterprise M series of midrange and high-end SMP machines, but did not provide any details on future system and chip co-development between the two firms.
It is not entirely clear what the Sparc T4 chip is, but it looks to be a shrink of the current 16-core "Rainbow Falls" Sparc T3 processor, which is fabbed by Taiwan Semiconductor Manufacturing Corp using a 40 nanometer process and which debuted back in September. The new Ellisonized Sparc roadmap does not appear to be the same as the Sun Microsystems roadmap that predates the Oracle acquisition, and that looks like a good thing.
On the old Sun roadmap, Sun was going to cut back the number of cores to eight and crank the clocks to 2.5 GHz using the same 40 nanometer process. This chip was called "Yosemite Falls" by Sun, and it was due in the second half of 2011. In 2012, Sun had a four-core chip called "Yellowstone Falls" running at 3 GHz and used in machines that spanned up to 192 sockets; this was expected around the middle of 2012. Then in late 2012 came "Cascade Falls," which had 16 cores like the Sparc T3s and also ran at 3 GHz. These latter two chips were to be baked in 28 nanometer processes. It looks like Sun was trying to recover from the death of the "Rock" UltraSparc-RK processor and the "Supernova" systems that were killed off just before that roadmap was given to customers back in June 2009.
Back in January, in the wake of Oracle's closing of the Sun acquisition, Mike Splain, who had been running Sun Microelectronics and who is now senior vice president of Oracle Microelectronics, said that the next generation of Sparc T chips, which we now know will be called the Sparc T4s thanks to Ellison, would use 40 nanometer processes, be socket-compatible with the Sparc T3 machines, and run at higher clock speeds.
Out beyond the Sparc T4, Splain said back in January that the T series would get a new core, and more of them would be packed onto the chip and run at higher frequencies. This chip - let's call it the Sparc T5 - will use 28 nanometer processes and will have a new memory controller, larger cache memory, new I/O, and power management features to squeeze all the performance per watt Oracle can out of systems.
So, what used to be three future chips seems to have been compressed down to two. It looks like Oracle has kept Yosemite Falls and Cascade Falls alive, but has made changes to them that allow Oracle to crank up the clock speeds higher than Sun had planned. Also, a new "VT" core that was expected with the Sparc T4 has been pushed out to the Sparc T5.
In his presentation yesterday, Ellison confirmed that the Sparc T4 would cut the core count back to eight from sixteen in the Sparc T3s and would keep the same eight threads per core. This matches the Yosemite Falls plan in terms of core count, but keeps the T2/T3 core instead of moving to that new VT core.
In August, when Oracle laid out its system aspirations, the company put together this roadmap:
In that new Oracle roadmap above the company is promising "+3x Single Strand" performance, which we take to literally mean that the clock speeds will be three times those of the past Sparc T2+ or now current Sparc T3s. That means between 4.8 GHz and 5 GHz clock speeds, depending on if Oracle was comparing to the 1.6 GHz T2+ or 1.65 GHz T3s. That is twice the 2.5 GHz clock speed that Sun was planning withYosemite Falls, and it will be interesting to see how Oracle does it.
You would think that to stay in the same thermal range as the T3s, oracle would have to bust the chip back to four cores to ramp the clocks so high. It is also possible that even with the 40 nanometer processes, Sun will crank up the Sparc T4 clocks to the 5 GHz range and just let them run a lot hotter, breaking into the same thermal ranges of other high-end RISC processors instead of trying to stay in the same thermal envelope as the Sparc T3s.
"The microprocessor team is doing a fabulous job," Ellison raved at the SuperCluster launch yesterday. "Our T4 is in the labs and will come out next year." A little later in the presentation, when talking about performance gains coming in the future, Ellison added that "with the T4, we're going to make our single-thread performance better, and it looks very good right now."
The jump to 28 nanometers would allow Oracle several options for core counts and clock speeds with the Sparc T5s relative to the Sparc T3s and T4s. It could do high core count and high clock speed variants again - and that might be the smart (although not cheapest) thing to do.
As part of the Sparc love-in yesterday, John Fowler, executive vice president of hardware engineering at Oracle, brought up Noriyuki Toyoki, corporate senior vice president at Sparc chip and system and Solaris partner Fujitsu, to introduce the long-awaited upgrade to the quad-core Sparc64-VII+ processor.
Fujitsu's Sparc64-VII+ "Jupiter-E" quad-core processor
The new chip, which was originally developed as the "Jupiter-E" by Fujitsu and which Oracle calls the M3 chip now, runs at 3 GHz. With 12 MB of shared L2 cache, it has twice as much cache memory as prior 2.88 GHz Sparc64-VII chips. Toyoki said that the larger cache size would boost database performance and said the new chip had about 2.4 times the oomph of the dual-core Sparc64-VI processor announced several years ago. With the extra cache and clocks, Oracle and Fujitsu that Sparc Enterprise M customers should expect up to 20 per cent more performance using the Sparc64-VII+ chips over systems with the earlier Sparc64-VIIs. The cache is a big part of that gain, with only a 4.2 per cent increase in clock speed.
The Sparc64-VII and Sparc64-VII+ chips have two threads on each of the four cores as well as 128 KB of L1 data and instruction cache per core. These chips implement true simultaneous multithreading, not the earlier VMT threading used in the Sparc64-VI chips.
As is the case with past Sparc Enterprise M machines, the latest Sparc64 chip is running at a variety of different clock speeds in different model of the line. Every machine does not get the fastest chip - just the biggest baddest boxes. Smaller machines get slower chips.
The single-socket M3000 entry machine doesn't even get the new Sparc64-VII+ at all, in fact, if Oracle's spec sheets are correct. The four-socket M4000 and eight-socket M5000 midrange machines get a 2.66 GHz version of the new Sparc64 chip, while the 16-socket M8000 and the 32-socket and 64-socket M9000 machines get the full-on 3 GHz chip.
The new chips can be used in the same chassis as the prior Sparc64-VI and Sparc64-VII chips, Toyoki reminded everyone, and this is in fact something that other high-end server makers do not do. When you mix and match the CPUs in a single system, the processors all run at their full rated speed. The clocks don't all average down.
The one thing that Oracle and Sun did not discuss were any potential plans to commercialize the eight-core "Venus" Sparc84-VIIIfx processor that is at the heart of the 10 petaflops Project K, formerly Project Keisoku, supercomputer project in Japan. Back in June, Fujitsu's new president, Masami Yamamoto, said that Oracle and Fujitsu were working on a new development and reseller agreement and hoped to have it done in a month or two.
Apparently that deal did get done, because the Ellisonized Sparc roadmap from August shows the M series of processors being goosed with six times the throughput and 1.5 times the "single strand" performance in mid-2012. That's a long way away from now. As is the upgrade that is coming in the end of 2013 or 2014, that will double up throughput again. I think a quad-core Sparc64-VIII processor running at 4.5 GHz is more likely in 2012 than an eight-core Sparc64-VIII running at 2.2 GHz. And that is what this roadmap suggests. But again, Oracle and Fujitsu have not really said what the plan is.
It is hard to say what that 64-socket Sparc box due in 2015 or so will be. Hopefully they didn't code-name it "Uranus." ®