CPU = IC * CPI * CLKwhere CLK = clock cycle time. So the unoptimized CPU time is:
CPU_un = IC_un * 1.0 * CLK_unand the optimized CPU time is:
CPU_opt = (.9 * IC_un) * 1.0 * (1.05 * CLK_un)(since 30% of the instructions are loads of which 1/3 are not executed on the optimized machine, and the clock cycle time of the optimized version is 5% higher than that of the unoptimized machine).
speedup = CPU_un / CPU_opt IC_un * 1.0 * CLK_un = ------------------------------------ (.9 * IC_un) * 1.0 * (1.05 * CLK_un) = 1 / .945 = 1.058
a) specint: Compaq AlphaServer GS140 6/700 (39.1)
specflt: Compaq AlphaServer 8400 6/575 (114)
SGI Origin2000 (114)
Good way to get these is to go to SPEC web site, use their search
form and get results in descending sorted order (sorted by spec
result). Or if you're dumb like me you can just download them all
and write an awk script to find the maximums...
It's interesting to note that these results change w/ some frequency. When I did the search a couple weeks ago the Compaq XP1000 was the top specint machine.
b) tpc-c: Sun Starfire Enterprise 10000, Oracle 8i
tpc-c p/p: Compaq Pro-Liant, Microsoft SQL Server 7.0
The TPC site sorts these for you.
c) Pros and cons of geometric mean:
pros:
- numbers don't reflect any particular workload: impossible to know
everyone's workload, so try to abstract from a "varied" workload.
- numbers are insensitive to choice of base machine.
cons:
- numbers don't reflect workload! Not proportional to total running
time, ie. don't predict execution time.
- small improvements in smaller benchmarks rewarded more than same
size improvements in larger benchmarks; may lead designers to
focus on smaller benchmarks.
A = B + C B = A + C D = A - Band determine instruction and total "bandwidths". (Note that bandwidth generally implies a rate measurement, ie. bytes per second. So when the book asks us to compare the bandwidths of these variants it is also implicitly asking us to assume that they all take the same amount of time to execute...)
Since the question was not explicit about the ISAs, there was a lot room for variation in instruction choice. Here are the versions they give in the answer book:
Accumulator: load B add C store A add C store B negate ; kind of sneaky, saves loading B again add A store D - inst: 7 * 3 bytes (1 opcode, 2 addr) + 1 byte = 22 bytes - data: 7 * 4 bytes = 28 bytes - total: 50 bytes Mem-to-mem: add A, B, C add B, A, C sub D, A, B - inst: 3 * 7 bytes (1 opcode, 6 addr) = 21 bytes - data: 3 * 12 bytes = 36 bytes - total: 57 bytes Stack: push B push C add pop A ; some people proposed a store-top-of-stack instr ; here, which saves loading A again... push A push C add pop B push A push B sub pop A - inst: 9 * 3 bytes (1 opcode, 2 addr) + 3 * 1 byte = 30 bytes - data: 9 * 4 bytes = 36 bytes - total: 66 bytes Load-store: load r1, B load r2, C add r3, r1, r2 store A, r3 add r1, r3, r2 store B, r1 sub r4, r3, r1 store D, r4 - inst: 5 * 4 bytes (1 opcode, 2 addr, 1 reg) + 3 * 3 bytes (1 opcode, 2 regs) = 29 bytes - data: 5 * 4 bytes = 20 bytes - total: 49 bytesSo the lowest instruction "bandwidth" comes from the memory-to-memory architecture, while the lowest total comes from the load-store architecture.
I. Outline of main points:
"While RISC advocates have been vocal...CISC advocates have been
disturbingly mute". Paper tries to balance the debate by:
1) Defining exactly what (in the authors' opinions) RISC is:
a) reaction to trend towards ever larger and more complex
instruction sets.
b) based on 801 research from 70's.
c) defined by the following:
- single-cycle operation
- load-store
- hardwired control
- few instructions & addressing modes
- fixed instruction format
- complexity moved to compiler
2) Pointing out misperceptions caused by terminology...:
a) names (RISC/CISC) imply that domain for discussion should be
restricted to selecting candidates for a machine's instruction
set.
b) names imply that any machine can (and should) be classified as
one or the other.
3) ...AND problems w/ RISC claims:
a) RISC leaves out operating system.
b) simpler designs could be realized more quickly?
- one of a kind vs part of a lineage.
- academic vs industry.
c) emulating complex functions in software does not imply RISC.
d) designing processor to run a single language well is different
from creating a single machine that must exhibit acceptable
performance on a range of languages.
e) performance claims are ambiguous: narrowly compute-bound, low-
level benchmarks used by RISC researchers.
4) Providing two case-studies of research that may have increased the
level of confusion:
a) register windows - confuse debate since their presence 1) is
orthogonal to instruction set choice, but 2) influences performance
results.
b) Intel 432 - superficially the perfect argument for RISC, but on
closer inspection problems w/ compiler, memory bandwidth, slow
procedure calls cloud the issue.
II. Critique:
2a) Assuming "reduced" is meant to imply "simpler" as well as "fewer" then
the argument can be made that each of the points in their definition
of RISC follows from the instruction set choice:
simpler => single cycle
single cycle => load-store
single cycle => hardwired control
fewer => few instructions & addressing modes
simpler => fixed instruction format
simpler => complexity moved to compiler
2b) Seems that given their RISC criteria, it *is* possible to determine
whether a machine fulfills the requirements or not.
3a) They don't go into any detail on this point: So why isn't the operating
system just a program that needs to be compiled efficiently? Are they
talking about protection?
3d) Seems that one of the main points of RISC (supported by Wulf) is that
architects should stay out of the way of language designers, provide
only the bare minimum of mechanisms useful to all languages, let the
compiler handle the policy.
3e) Good point, but then they go into this incoherent argument about error
checking...speed is orthogonal to correctness. Shouldn't error
checking code go fast too?
4a) How orthogonal are register windows and instruction set choice really?
Part of the rationale for including them in RISC1 seems to have been:
there's extra room now that there's no micro-code decoding and the
control path is simpler.
4b) The 432's slow procedure calls are a perfect illustration of the danger
of the architecture determining policy.
Also, why is the compiler support so bad? Could it be partly
because the designers felt that since everything was going to be
handled at the instruction level there was no need for extensive
compiler support? (I think at least some of the problem is that
Ada is a really difficult language to analyze...)
Some other very good points raised by people in the class:
- the authors don't mention the relationship between RISC and ease
of implementing a pipeline.
- register windows can be viewed as important in addressing a
*weakness* of RISC, many more registers which need to be
saved/restored during procedure calls and especially context switches,
so again maybe they weren't as orthogonal to instruction set choice
as the authors would have us believe.