Oracle's Sparc T5 Chip Evidently Pushed Back to 2013 98
Mark Hachman writes in Slash Datacenter that the Sparc T5 chip Oracle announced earlier this year apparently won't be ready until sometime in 2013. John Fowler, executive vice president, Systems, Oracle, presented at Oracle Open World a chart outlining highlights of Oracle's plans for the future.
"But Fowler also skipped over some bad news: an apparent delay for the Sparc T5. A year ago, Oracle’s Sun division announced the Sparc T4—and according to Fowler, Oracle chief Larry Ellison set a very high bar for the next iteration: double the performance while maintaining app compatibility on an annual basis. Apparently, that didn’t quite happen with the T5; Oracle had the opportunity to announce a T5-based server, and didn’t. That’s a bit of bad news for the Sun design team, which already had to watch Intel’s Xeon chief, Diane Bryant, give the preceding keynote. ... As detailed at this year’s Hot Chips conference, the T5 combines 16 CPU cores running at 3.6 GHz on a 28-nm manufacturing process. Continuing the trend of hardware acceleration of specific functions, Sun executives claimed the chip would lead in on-chip encryption acceleration, with support for asymmetric (public key) encryption, symmetric encryption, hashing up to SHA-512, plus a hardware random number generator."
Oracle? SPARC? (Score:4, Interesting)
hardware, not software Re:Oracle? SPARC? (Score:5, Interesting)
Companies continue to force non-free software onto unsuspecting victims too.
Actually the fine article is about hardware; processors to be specific.
If I was heavily invested in Solaris I would be interested in the Sparc T5. Here are some excerpts from this Register article: [theregister.co.uk]
The Sparc T5 chip is more than just a shrunken Sparc T4 processor, which Oracle revealed at last year's Hot Chips conference and then started shipping in systems as 2011 wound down. The Sparc T4s had eight of the new S3 generation of Sparc cores, and the 3GHz clock speed and tweaks to the instruction pipeline were designed to make it much better at single-threaded work than its Sparc T chip predecessors. The Sparc T4 is manufactured by Taiwan Semiconductor Manufacturing Corp using its 40 nanometer processes, and the sixteen-core Sparc T5 chip uses the popular 28 nanometer processes from TSMC that a number of processor and graphics card makers are employing in their latest devices.
Getting back to sixteen cores on the Sparc T5 die, each with eight threads for running heavily threaded work, is a good use of the process shrink. Oracle could have gone a simpler route and double-stuffed the sockets with slightly modified Sparc T4 designs, akin to what IBM is doing with its Power7+ processors in some server configurations, to get to that sixteen core level. But, for whatever reason, Oracle wants to have all of the cores on the same die and running on the same crossbar interconnect.
Re:Oracle? SPARC? (Score:5, Interesting)
Before Fowler became an Oracle employee, he was in charge of the hardware division at Sun. And before that, he was in charage of x64 systems. I was working there at the time, and the word from on high was that putting the x64 guy in charge was a signal about our future direction.
Which of course, didn't happen. Sun's sales channels continued to view x64 systems as a way of migrating people to SPARC vis Solaris-on-x64. Which all our customers, who were already heavily invested in Windows and Linux, had no interest in. My big hope for the Oracle takeover was that Oracle's sales org (aside from being bigger than all of Sun) would be smarter than that and push x64 systems.
But Oracle has dratically reduced the models of x64 systems they sell. Officially, that's about a leaner product line and ending the special relationship with AMD. But I'm beginning to expect that the SPARC koolaid is as popular in Oracle as it was in Sun.
Re:Oracle? SPARC? (Score:2, Interesting)
Wow. Have you actually used Oracle for a data need that actually requires it? How about a T4 SuperCluster? No? Really? That's probably why you're convinced that your comments like "Someone is still buying that shit" and the like are just hilarious. They're not. In fact they show your immaturity and lack of understanding of just how large and complex some data-sets can get. We've got racks of Exadatas being fed by racks of Superclusters and backing up to racks of ZFS backup appliances. We've also got a couple of racks of Exalogic and Exlytics for Hadoop and front-end apps. In said racks are Intel chips (Intel keynoted Oracle OpenWorld where the above announcement wasn't made), and T4 chips. Solaris and Linux. You get the idea. Mostly it's that you're really just kind of dumb.
Re:Oracle? SPARC? (Score:5, Interesting)
For the first time, Windows compatibility is mattering less and less as many users only use the web and web apps on their computers - opening the door to competing processors for the first time since the late 80's. At the same time, PC's continue to represent a smaller and smaller share of new CPU's, which are migrating to data centers, smartphones, and pads, which are even less dependent on X86 compatibility.
For the first time, the computational penalty of X86 instruction set translation for RISC cores may not outweigh the compatibility benefit for a significant portion of users. Increasingly, customers don't care about compatibility with existing X86 codebases. Like ARM, anyone with a new processor with compelling performance per watt might actually be able to sell the thing, without everyone assuming it's worthless if it won't run Windows.
Also, I wouldn't quite characterize POWER as a strictly legacy product, since IBM introduced the latest iteration, the power 7+, in August 2012, and is currently selling 15 different systems using Power7 processors. Not to mention the Xbox 360, Playstation 3, Wii, and not-even-out-yet Wii U that are all POWER based systems.
Re:hardware, not software Re:Oracle? SPARC? (Score:3, Interesting)
Things like the ability to park threads in the OS that are idle. To shift loads from core to core to allow cores to be shifted into hyper single-threaded mode.
The ability to encrypt/decrypt dual 10Gbit communications at wire speed (ie no delays at all).
The ability to do all SSL encryption/decryption with zero delays or CPU overhead.
The ability to handle hundreds of java threads efficiently, each with their own dedicated VCPU.
The list goes on and on. Most of these you cannot get (yet) with an Intel or AMD solution - not at this scale, not with the horsepower to run through at a steady pace, without slowing down.
Power, Flexibility, Stability - key working points to the SPARC lineup over the years - coupled with Solaris and you still have a rock solid datacenter foundation.
I don't see this in the Intel / Windows / Linux lineup.
Re:Oracle? SPARC? (Score:4, Interesting)
For the first time, the computational penalty of X86 instruction set translation for RISC cores may not outweigh the compatibility benefit for a significant portion of users.
Yes and no.
Yes, in that it's always mattered. Intel can never be power competitive in the low end due to the expense of the x86 instruction decoder. Then again, neither can ARM which is why static 14/8 bitters like PIC dominate the truly low end. In the mid range ARM and others (but mostly ARM) will not be displaced by Intel for exactly that reason.
ARM dominate all the way to the beginning of the high end. However, once one hits the high end, and single thread performance goes up, again the decoder becomes a smaller and smaller fraction of the energy usage. The OoO unint and execution units dominate, as the OoO unit has to expend a lot of energy to keep the energy hungry execution units fed while they're ungated.
Users are now beginning to care about the high end on their phones, just about.
For fun, compare the FLPOS/Watt of an i7 Ivy Bridge to any other general purpose CPU. The Ivy Bridge one does surprisingly well, in fct I think it's pretty much a winner. Certianly compared to ARM. The reason is that as the performance goes up, the instruction decoder begines to pale in to insignificance.
It's the same old argument as always.
Intel will never hit the mid to low end, but the penalty almost disappears on the high end, and Intels better process and expertise in branch prediction dominates.
For now, phones are bumping into the bottom of the top end. In 5 to 10 years they will be firmly in it, and the landscape will be very different. In 10 to 15 years, cheaper smartphones (e.g. spiritual successors to something like the Galaxy Ace) will be comfortably inot the high end.
Arm will continue to dominate the upper low end to the top of the middle because of the decoder. But phones things will be moving well into the top end.
I'm defining low/middle/high by absoute performance and relative power tradeoffs between parts of CPUs.