Hardware Reference
In-Depth Information
FIGURE 1.20 Percentage of peak performance for four programs on four multipro-
cessors scaled to 64 processors . The Earth Simulator and X1 are vector processors (see
Chapter 4 and Appendix G). Not only did they deliver a higher fraction of peak performance,
but they also had the highest peak performance and the lowest clock rates. Except for the
Paratec program, the Power 4 and Itanium 2 systems delivered between 5% and 10% of their
peak. From Oliker et al. [2004] .
Pitfall Fault Detection Can Lower Availability
This apparently ironic pitfall is because computer hardware has a fair amount of state that
may not always be critical to proper operation. For example, it is not fatal if an error occurs in
a branch predictor, as only performance may sufer.
In processors that try to aggressively exploit instruction-level parallelism, not all the opera-
tions are needed for correct execution of the program. Mukherjee et al. [2003] found that less
than 30% of the operations were potentially on the critical path for the SPEC2000 benchmarks
running on an Itanium 2.
The same observation is true about programs. If a register is “dead” in a program—that is,
the program will write it before it is read again—then errors do not mater. If you were to crash
the program upon detection of a transient fault in a dead register, it would lower availability
unnecessarily.
Sun Microsystems lived this pitfall in 2000 with an L2 cache that included parity, but not
error correction, in its Sun E3000 to Sun E10000 systems. The SRAMs they used to build the
caches had intermitent faults, which parity detected. If the data in the cache were not modi-
ied, the processor simply reread the data from the cache. Since the designers did not protect
the cache with ECC (error-correcting code), the operating system had no choice but to report
 
Search WWH ::




Custom Search