yARN: Oracle plugs SPARC
- 29 November, 2012 14:50
This month, Oracle has been celebrating the twenty-fifth anniversary of the SPARC processor.
Interest in reduced instruction set computing (RISC) blossomed in the 1980s. The basic idea was that a processor should be able to execute any of its instructions within a single memory cycle.
The more widely used complex instruction set computing (CISC) model allowed the execution of an instruction to occur over multiple memory cycles. For a given amount of silicon, a RISC processor devoted less space to execution, leaving room for more registers (working memory, if you like). So where a CISC processor might be able to add the values stored in two memory locations, a RISC processor would only add values stored in two registers, so fetching those values from memory had to be coded explicitly.
Some highly influential research into RISC was carried out at the University of California Berkeley during the early 1980s, and became the basis of Sun Microsystem’s SPARC (Scalable Processor ARChitecture) which was created in 1986 and used in the 1987 Sun-4 workstation.
Although the SPARC architecture has been licensed to multiple manufacturers including Texas Instruments and Fujitsu, it remained largely associated with Sun and - thanks to that company’s 2010 acquisition - more recently with Oracle.
SPARC wasn’t the only commercial RISC implementation: others included the DEC Alpha, HP PA-RISC, and MIPS (acquired and later divested by Silicon Graphics). The most widely used RISC architecture is ARM (originally Acorn RISC Machine), as found in Apple’s iPhone and iPad, Microsoft’s Surface, and a large number of other products.
But back to SPARC, which “couldn’t be healthier,” according to Rick Hetherington, Oracle’s vice-president of hardware development. Hetherington has been with Sun and Oracle since 1996, and previously worked for DEC on VAX and Alpha hardware (that’s a lot of RISC experience).
Around 2000 engineers are currently working on SPARC hardware and systems, which is a bigger team than he remembers ever seeing at Sun. The increased predictability of processor design means there is less risk, and “the future looks extremely bright”, he says, with performance doubling every two years.
The significance of a software company having its own hardware is that it makes it possible to provide hardware acceleration for functions normally handled in software (eg, by Oracle Database) and thus give customers a better experience, he explained.
The current generation of SPARC processors is known as T4, and has eight cores, each of which can act as up to eight virtual CPUs. If a core is dedicated to an application’s ‘critical thread’ - the thread that limits overall throughput - can be isolated to a single core, the result is better performance, he explained. Some SPARC customers currently do that manually, but Oracle is building this ability into its systems so it happens automatically.
Getting the hardware (SPARC), operating system (Oracle) and software (eg, Oracle Database or Oracle Coherence clustering software) working together more closely will increase throughput. Another part of Oracle’s approach is to build specific functions into SPARC chips. An existing example is the inclusion of a cryptographic engine, which means the crypto functions in Solaris are very efficient. For example, it means that a web server running on a SPARC system can use HTTPS instead of HTTP without the usual performance hit.
The company is planning to move more of these specialised functions from software to silicon in future SPARC designs, Hetherington said. The SPARC roadmap shows a variety of accelerators are planned for the 2014-2016 timeframe, with functions including compression, database query, and application data protection.
Closer to hand, the SPARC T5 is expected in the first half of next year, with 16 cores (each capable of running eight threads) running at up to 3.6GHz and a corresponding doubling of the L3 cache from the T4’s 4MB.