Sun, Servers, and SPARC

Sun Microsystems made its reputation in the mid-1980s by building a line of highly regarded UNIX workstations with the Sun OS, based on a version of the Berkeley Software Distribution of UNIX. Starting in 1982, Sun's servers offered the TCP/IP protocol suite. By 1985 Sun had its IPO, and by 1987 it was the industry leader in the workstation market. Sun had one of the fastest and most successful runs in the computer hardware market.

By 1988 Sun had introduced its SPARCstation 1, the first "pizza box" design. In some ways, 1991 was a watershed year for the company. That year, Sun introduced the Solaris 2 operating system for RISC processors, a version of the operating system that was designed for symmetric multiprocessing (SMP) systems. The SPARCstation 10, which appeared in 1992, was the first SMP desktop system. In that year, Sun shipped more RISC systems than any other UNIX vendor had ever shipped.

The popularization of the Internet really fueled Sun's surge into the server market. ISPs needed routers, switches, and firewalls for their networks and Sun was one of the players. When many of them began comparing the cost and power of servers made by other vendors to the cost and power of Sun workstations, many opted for the much less expensive Sun workstations. As the Internet market grew, Sun workstations and then Sun servers became the dominant platform for not only routers and switches but for webservers and other application servers as well. Eventually Cisco would displace Sun from the router market, but Sun continued to offer more and more powerful systems until it became the dominant Internet server vendor.

In 1996 Sun introduced systems based on its first 64-bit processor, the UltraSPARC. That was the same year that Java was first introduced, and it was when Sun contributed to the development of XML. A year later Sun introduced its first high-end server system, the Sun Enterprise 10000, which was really a mainframe-class system. That system set TCP-C benchmark records on all the leading databases. From the standpoint of servers, the next big introductions were smaller systems meant to be building blocks in horizontally scaled applications, such as the Netra t1 servers and the Sun Ray 1 enterprise appliances in 1999 and the Sun Fire "midframe" systems in 2001.

All of Sun's server offerings ran RISC architectures and Solaris exclusively until 2002, at which point the Sun LX50 server, a general-purpose server that could run either Solaris or Linux, appeared. Sun began to broaden its approach to deploying servers in 2002, first with the N1 architecture, in which "the network is the computer," and later in 2003, with a push into grid computing. Grid computing uses multiple network computers to solve the same problem (see http://en.wikipedia.org/wiki/Grid_computing). This chapter spends a significant amount of time discussing Sun's approach to blade servers, but the company has had a modular approach to systems for quite some time. It's the natural expression of the company's workstation heritage. The most recent trends in their server strategy are the broadening of Sun's product line into Linux, a serious push to attain server interoperability with other network operating systems (something the company didn't strive for until recently), and its initiative into a web services model that Sun calls "utility computing," which is a form of pay-as-you-go services.

The RISC Architecture

Broadly speaking, there are two approaches to building computer processors: complex instruction set computer (CISC) and reduced instruction set computer (RISC). They aren't actual processor designs; they are more like design philosophies. A CISC processor has a larger set of commands, and those commands can be more complex than those in a RISC processor. CISC allows commands that can span several processor cycles to be executed.

In the 1970s, when chip designers took a close look at exactly which instructions developers were using in their programs, they found that the much greater majority were simple commands. Even when a more complex command was used, it was often a combination of simpler commands. A well-known example of this is the VAX INDEX command, which turned out to be slower to execute than using a larger set of simpler commands, looped in code to create the same data structure. The compound instructions called orthogonal addressing modes were ignored, and the additional instructions were converted with compilers rather than the programs being written in assembly language; today compiling code is the standard step taken prior to running a program.

RISC processors use fewer commands in their instruction set than CISC processors, but they try to optimize those commands so that they run more efficiently. An instruction in a CISC processor that might be a combination of four simpler instructions and run over eight processor cycles, when executed on a RISC processor, would become four individual instructions that might still take eight processor cycles, but because the instructions are smaller, there is greater efficiency in getting the instructions processed with fewer lost cycles. That's the difference, in theory.

RISC processors offer a few additional benefits that make them popular in high-performance systems. First, because there are fewer instructions in a RISC processor's instruction set, the design of the processors can be simpler. A simpler design means that the chips can be less expensive or include additional features at the same price as a more complex chip. Also, with simpler commands, less memory is consumed storing the instructions as the code executes. Given that CPUs operate much faster than memory, less memory consumption is a very desirable feature.

In RISC processors, you may find the following:

• Very large internal caches

• Additional registers, which tend to be more homogeneous than CISC registers

• Built-in I/O control and timers for use in controller applications

• Next-generation features implemented into older chip designs, thus using old fabrication facilities to create new series processor

• Built-in graphics routines

• Parallelism implemented through pipelining or by superscalar technologies

• A lack of some features in order to decrease the energy consumption of the chip

Examples of CPUs with RISC architectures are Sun's SPARC and UltraSPARC, IBM PowerPC, MIPS (see http://en.wikipedia.org/wiki/MIPS_architecture), and DEC Alpha chips.

One additional feature is that it's easier to develop RISC chips with larger internal buses than to develop CISC chips, and indeed you need a wider bus if you are going to beat the clappers out of your processor, pushing small instructions through the logic unit. RISC processors and the operating systems that run them reached 64-bit internal buses in the late 1990s. With wider buses, you also get better performance out of the chip at lower frequencies and thus have lower heat issues. This also means that the compilerthe software that translates programs into instructions that the processor understandsis easier to create and more efficient in a RISC-based CPU.

It sounds like RISC is better than sliced bread, doesn't it? Well, not so fast. CISC offers developers the benefits of having a much richer development environment, it is easier to program for, and it has a very long history of development and optimization. If you are a developer and you need an instruction that does four things, do you really want to have to remember which four things they were? Wouldn't it be better to simply give the single instruction and spend your time figuring out if your code does what you want it to do? The best example of CISC processors is the Intel x86 architecture, and we all know how successful those processors have been. Starting with the Pentium Pro, Intel began introducing RISC features into its CPUs, so its current technologies are really something of a hybrid, as are most of the other CPUs on the market today.

As technology has developed, it isn't really possible to say that one chip is a pure CISC chip and the other is a pure RISC chip. RISC chips may have reduced instruction sets, but they are large instruction sets. Chip vendors are optimizing their designs so that you now find RISC features in CISC chips and CISC features in RISC chips. Which design is better is hard to say. As mentioned earlier, these two approaches are design philosophies, and each represents a set of compromises.

SPARC and UltraSPARC

The SPARC processor arose out of RISC processor design work done at Berkeley in the early 1980s. SPARC stands for Scalable Processor Architecture, and although SPARC is most closely associated with Sun Microsystems, it is in fact a registered trademark of SPARC International, Inc. (see www.sparc.com), which promotes and standardizes it as an open system architecture. So you not only find processors using SPARC built by Sun but by Cypress Semiconductor, Fujitsu, Texas Instruments, and in the open source implementation called LEON from Gaiser (see www.gaisler.com/index.html).

Note

You can find a nice repository of CPU statistics and pictures of SPARC processors at www.cpu-collection.de/?tn=1&l0=cl&l1=SPARC.

SPARC is a big-endian processor architecture, unlike the x86 architecture, which is little-endian. That's one reason why you simply can't recompile a program written for x86 onto SPARC and vice versa. Programs that travel from one platform to another are a complete port.

One of the most recognizable features of SPARCs, something that is consistent with RISC processors in general, is their use of general purpose registers (GPRs). SPARC can use as many as 128 GPRs, of which 8 are for global use and 24 form a register window that can be used for function calls in the register stack. A register window of 8 local registers shares 8 registers with nearby register windows. Shared registers pass parameters and return values, whereas local registers store values used by multiple function calls. Only 32 registers (8 + 24) are available for use by programs in the SPARC architecture, but the architecture is called scalable because programs can use up to the full allotment of 32 windows or as few as just 1. When you use more windows in memory, you suffer more context switching because memory must page in and out for instructions, but you do have more instructions loaded in memory.

Table 19.1 lists the essential characteristics of the different generations of SPARC processors.

Table 19.1. SPARC Series Processors

Model	Freq. (MHz)	Year	Process (µm)	Transistors (millions)	Size (mm?)	I/O Pins	Power (W)	Voltage (V)	Dcache (KB)	Icache (KB)	Scache (KB)
					Version 8
microSPARC I	50	1992	0.8	0.8	225	288	2.5	5	4	2	0
SuperSPARC I	3365	1992	0.8	3.1	NA	NA	14.3	5	16	20	1,024
microSPARC II	60125	1992	0.5	2.3	233	321	5	3.3	8	16	0
SuperSPARC II	7590	1994	0.8	3.1	299	NA	16	NA	16	20	2,048
TurboSPARC 1	60180	1995	0.35	NA	NA	416	7	3.5	16	16	1,024
					Version 9
UltraSPARC I	140200	1995	0.5	5.2	315	521	30	3.3	16	16	1,024
UltraSPARC II	250480	1997	0.25	5.4	156	521	21	3.3	16	16	8,192
UltraSPARC Iii	270480	1998	0.25	5.4	148	587	21	1.9	16	16	2,048
UltraSPARC IIe	400500	2000	0.18 AL	NA	NA	370	13	1.7	16	16	256
UltraSPARC IIi+	550650	2002	0.18 Cu	NA	NA	370	17.6	1.7	16	16	512
UltraSPARC III	6001200	2001	0.13	29	330	1368	53	1.6	64	32	8,192
UltraSPARC IIIi	10641593	2003	0.13	87.5	206	959	52	1.3	64	32	16,384
UltraSPARC IV	10501350	2004	0.13	66	356	1368	108	1.35	64	32	16,384

The current versions of the SPARC standard are versions 8 and 9. Version 8 uses 16 double-precision floating-point registers. Each register can be used in different ways. You can use a register to store two single-precision values, which equates to having 32 single-precision registers, or you can couple an odd and an even double-precision register together, which can create up to 8 quad-precision registers. Alternatively, you can use the 32 registers as standard double-precision registers.

SPARC version 9 is notable in that it was the first 64-bit version of the architecture. Version 9 added 16 additional double-precision registers to the architecture to support the internal 64-bit data bus. Of course, even if a processor runs internally at 64 bits, a system's I/O bus still runs at 32 bits. There are plenty of examples of systems running a 64-bit internal CPU bus and a 32-bit I/O bus, as well as the opposite case of a 32-bit internal CPU bus over a 64-bit I/O bus.