There are two largely separate points, the performance and the reliability. When you talk about performance everyone tends to pay attention to the CPU frequency, but to tell the truth, it is not the case that that alone decides the performance. We, by cancelling out bottlenecks inside the processor, targeted efficiency of the entire processor. A bottleneck in one part can slow down the entire processor and reduce performance.

To make it easy to represent, let’s compare the functions of the processor to cooking. Buying and cooking of ingredients replaces the handling and processing of data. In order to cook, ingredients (=the data) must be first bought from the shop (=memory) and kept in the refrigerator (=secondary cache) near the cooking place. When cooking, the necessary ingredients must be prepared from the refrigerator on the kitchen stand (=primary cache) and cooked using the cutting board and the stove (=computing unit).

The improvement in CPU frequency relates to how the cooking speed can increase using the cutting board and the stove. For example, it is assumed that 10 potato croquettes can be made in one minute. So if the ingredients are prepared on the kitchen stand beforehand, then 10 pieces can be made per minute. But if the ingredients are not prepared on the kitchen stand it is necessary to take them from the refrigerator.

But how might it be if the refrigerator is on the second floor and the kitchen is on the first floor? It takes more time to bring the ingredients from the refrigerator. If it takes 3 minutes, then only ten croquettes can be made every three minutes and the work efficiency reduces to one third. Therefore, in order to make 10 croquettes per minute acceleration of the part where the ingredients are prepared is required.

In other words, in order to fully use the efficiency of the computing unit, the entire throughput, which includes the memory and cache access, must also be improved. In the mission critical system environments where PRIMEPOWER is introduced, mass data processing is carried out 24 hours a day, 365 days a year. Because of that, we think it is especially important to remove all bottlenecks to ensure the entire process is optimum.

Out-of-Order execution has been enhanced. Out-Of-Order execution is a technique for improving performance by bringing forward and executing instructions where all necessary data is complete, regardless of the order described in the program. This technique was adopted in a limited way with the previous generation of SPARC64 GP processors. But in SPARC64 V, the extent of where Out-of-Order can be executed has been expanded to even include memory access. We can again think of this using the cooking analogy. Now we assume that the croquettes are made first and the salad is made afterwards. Let’s assume the ingredients for the salad are on the kitchen stand, but we don’t have the ingredients for the croquettes unless we go and buy them. Previously, even assuming the ingredients for the salad existed, going and buying the ingredients and making the croquettes would occur before making the salad. While buying the ingredients all cooking would stop and the cutting board and stove would remain unused.

But with SPARC64 V, because the ingredients are ready, the salad is made first while the ingredients for the croquettes are prepared, when that point is reached the croquettes can be made.

Our previous generation SPARC64 GP processor was at a point, which was said to be very complete in regards to RAS(Reliability, Availability and Serviceability) in comparison to competitive products, but further enhancements were put in place. To use the cooking example, a supervisor had been introduced to additionally check the quality of the ingredients on the bench top, refrigerator and the kitchen to see whether or not the ingredients carried there are not damaged. But after that, until now, any damage after having started cooking could not be checked. To improve this situation we set about checking all stages, including buying the ingredients, cooking and even sending it to the table.

In SPARC64 V, checkers were installed for all transmissions of data including the computing unit and the registers without exception, plus any errors are checked in detail. The latest SPARC64 V processors contain 803 checkers each, which means around 320,000 checkers in a single system (PRIMEPOWER2500 with 128 processors). I would suggest that no other vendors think about the reliability of processors so strictly. It is on this reliability basis that we achieve RAS functions equal to that of mainframes. With PRIMEPOWER an important server supporting a customer’s key business processes, errors are not allowed and processing cannot be allowed to progress if a mistake occurs.

It is necessary to not only detect the error when it occurs but also to restore processing. For SPARC64 V we chose the concept of self-restoring hardware, although there are methods of doing this using the operating system software, etc. Because hardware performs the instruction processing and is used to detect errors it can use a function called “Instruction Retry” to automatically repeat instructions to reduce errors as much as possible.

If we think of software correcting the error, then the software only works on top of the hardware where the error is. In so doing, it is like the disease treating itself and is not a very good way of correcting the error. So inside SPARC64 V we have installed special self-recovery mechanisms that check errors and perform recovery. This can be viewed in the same way as appointing a specialist (doctor) specific to the illness.

In this situation the reporting and restoration of errors can be performed efficiently even in cases where software is malfunctioning. In truth, not many transistors are needed to setup this mechanism. So in order to make a processor in which you can have great confidence we believe such functions are important. In PRIMEPOWER we use many other technologies that also enhance confidence. The technology and know-how of Fujitsu once cultivated in mainframe development is now best used in UNIX server development.

The next page introduces development impressions and a view to the future.

Previous

Next