-
Standard Memory Hierarchy Does Not Fit Simultaneous
MultithreadingSebastien Hily Andre SeznecIntel Microcomputer
Research Lab IRISA5350 NE Elam Young Parkway Campus de
beaulieuHillsboro, OR 97124 35042 Rennes cedex
(France)[email protected] [email protected]
multithreading (SMT) is a promizing approach in maximizing
performance by enhancingprocessor utilization. We investigate
issues involving the behavior of the memory hierarchy with
SMT.First, we show that ignoring L2 cache contention leads to
strongly over-estimate the performance one canexpect and may lead
to incorrect conclusions. We then explore the impact of various
memory hierarchyparameters. We show that the number of supported
threads has to be set-up according to the cachesize, that the L1
caches have to be associative and small blocks have to be used.
Then, the hardwareconstraints put on the design of memory
hierarchies should limit the interest of SMT to a few
threads.Keywords : SMT, Simultaneous Multithreading, Memory
Hierarchy, Caches1 IntroductionSimultaneous multithreading (SMT)
appears to be a very promising approach for achieving higher
perfor-mance through better processor utilization [1, 2]. An SMT
architecture executes simultaneously severalprocesses (or threads).
Tullsen et al. [1, 2] have shown that an SMT architecture
supporting 8 threads couldachieve up to four times the instruction
throughput of a conventional superscalar architecture with the
sameissue bandwidth. However, the simultaneous execution of several
threads puts a lot of stress on the memoryhierarchy. The bandwidth
oered by the second-level cache, either on-chip or o-chip, can be
insucient toallow the parallel execution of more than a few
threads.In this paper, we explore the intrinsic limitations of a
standard memory hierarchy in an SMT environ-ment. Our study focuses
rst on the bandwith demanded on the second-level cache. We rst show
thatneglecting the contention on the L2 level cache conducts to
very misleading results. This is already truefor singlethreaded
architectures [6], however this is far more critical when the
number of threads increases.Then we examine the inuence of dierent
memory hierarchy parameters on the eective performance of anSMT
microprocessor. We show that the number of threads supported by the
hardware must be carefullychosen according to the cache size: for
instance when using 32KB-64KB caches, implementing more than
4threads will be counter productive. We also establish that on SMT
processors, rst-level caches have to beset-associative and nally
that the block size has to be small (typically 16 or 32 bytes for a
16-byte bus).The remainder of this paper is organized as follows.
Section 2 presents the experimental framework,giving details of the
simulated architecture and especially the memory hierarchy used.
Section 3 introducesthe methodology. In Section 4, simulation
results are detailed and analyzed. Section 5 summarizes the study.2
Simulation environmentTo conduct this study, we relied on
trace-driven simulations. As our work focuses on
cache-organizationbehavior, we therefore rst present the simulated
memory hierarchy.2.1 Simulated Memory hierarchyTo our knowledge,
the only study available on caches and simultaneous multithreading
is part of a workdone by Tullsen et al. [1]. They showed that
associating a private rst-level cache with each thread is
notinteresting, as it would be equivalent (on memory side) to
conventional multiprocessors sharing a second-levelcache. There
would not be any balance of the cache space used by threads
according to their needs. Withprivate caches, there is a waste of
space when fewer threads are running. Thus, using shared rst-level
cachesis better, except for high number of threads, where private
instruction caches and a shared data cache shouldbe preferred.
Tullsen et al. do not study the impact of all cache parameters on
performance. Moreover,1
-
this study considered only the SPEC92 benchmark suite. This
suite is known to be inappropriate for cacheevaluation, as the
number of requests missing a small L1 instruction cache (and also
in fact on the datacache) is particularly low and not realistic
[4]. Moreover, the contention on the second-level cache was
notevaluated.We evaluate the impact of the principal cache
parameters on the performance of an aggressive
architecturesupporting simultaneous multithreading. We also examine
carefully the problem of contention on the second-level (L2) cache.
Due to large L2 cache size (often 1 MBytes or more), contention on
the memory (or athird-level cache) is far less critical. We built a
congurable simulator for a classical two-level memoryhierarchy
(Figure 1), as described in [5] and [3].
CPU
INSTRUCTION CACHE DATA CACHE
WRITE BUFFERS
WRITE BUFFERS
UNIFIED L2 CACHE
MAIN MEMORY
FETCH/DISPATCHdegree 8
POOL OF FUs
WINDOW
INST.
TH
RE
AD
1
TH
RE
AD
2
TH
RE
AD
i
INST.CACHE
DATACACHEFigure 1: simulated architectureWe simulated a
write-back scheme for the data cache and the L2 cache. The write
policy on miss is write-allocate. Write-back was preferred to
write-through, because it induces less trac on the buses.
However,write-back slightly disadvantages long cache lines as a
longer line is more likely to be dirty and therebyinducing a burst
of trac on the buses. A write-through policy should increase the
average bus occupancybut could diminish the burst eect, which could
result in an interesting tradeo. Write-through schemeimplies quite
a dierent memory hierarchy. This could be part of a future study.As
in recent out-of-order execution microprocessors, L1 and L2 caches
are non-blocking, which meansthey do not stall the processor on a
miss [7]. Dedicated write ports are used for updating the caches
aftera miss. The servicing of L1 misses by the L2 cache is
pipelined; as on most current out-of-order executionmicroprocessors
(DEC21164, MIPS R10000, UltraSparc, ...) servicing of a L1 miss may
begin while anotherL1 miss is still in progress. To limit the
penalty on execution time, the missing word is always sent backrst.
To improve latency and reduce bandwidth consumption, multiple L1
cache misses that access the sameblock can be merged. TLB is
assumed never to miss. L1 caches are accessed with virtual
addresses (i.e.TLB transactions and cache accesses are performed in
parallel). The bus width between the buers and theL1 caches is 16
bytes. The default bus width between L1 and L2 caches is set to 16
bytes. This correspondsto a large but realistic width (the size is
8 bytes on the Intel P6 and 16 bytes on the DEC 21164, the
MIPSR10000 or the UltraSparc). In case of an on-chip L2 cache,
larger buses would result in a higher powerconsumption and buses
would occupy a large silicon area. For o-chip caches, a very high
number of pinswould be required, which leads to high costs
incompatible with low or medium end PC market.The L1 caches are
multi-ported. On every cycle, up to two concurrent accesses to the
instruction cacheand 4 concurrent accesses to the data cache are
possible. Fully multi-ported cache structures were considered.Such
a structure may be considered as unrealistic, but we did not want
to explore the spectrum of interleavingdegree in caches. The
results that are given here may then be considered as upper limits
for speed-ups.Simulating a more realistic L1 cache structure
(interleaved banks) would only reinforce our conclusions.For the
sake of simplicity in this study, we assumed that instruction and
data caches have always thesame size, the same blocksize and
associativity degree. As in most of current processor designs, we
simulateda unied L2 cache. 2
-
2.2 Simulated architectureThis study focuses on the memory
system behavior. To measure only the impact of this memory systemon
performance, other parameters were chosen in a quite optimistic
manner. First, we assumed no resourceconicts on functional units,
i.e. one instruction may be executed as soon as its operands have
become valid.Second, branch direction and target were assumed to be
always correctly predicted. Figure 1 illustrates thesimulated
architecture. Our fetch mechanism is able to select several
instructions from each thread for theexecution. If a single thread
is available, it has the opportunity to ll all slots in the
execution pipeline.This mechanism is fully described in [8].3
MethodologyWe performed simulations by varying memory-hierarchy
parameters while executing 1, 2, 4 or 6 threadssimultaneously.
Distinct programs are assigned to the threads in the processor. For
each simulation, wewarm the memory hierarchy with the execution of
1 million instructions per executing thread. Ten millionof
instructions time the number of threads is then simulated. This is
sucient given the structure ofthe memory hierarchy. Moreover, we do
not look at the absolute performance of SMT architectures on
anapplication, but we want to evaluate their relative behavior
while varying dierent parameters of the memoryhierarchy. The
default parameters used in this study are listed in table 1 (na
means not applicable). We usedInst. cache Data cache L2 cache
MemorySize 32KB 32KB 1MB naLine size 32 bytes 32 bytes 64 bytes
naAssociativity 4 4 4 naLatency (cycles) 1 1 5 30Transfer time
(cycles per 16 bytes) 1 1 2 4Table 1: default parameters of memory
hierarchyeight traces from the IBS (Instruction Benchmark Suite) to
build our workloads : gs, jpeg play, mpeg play,nro, real gcc, sdet,
verilog, video play. The IBS (Instruction Benchmark Suite) is more
representative of realworkload than the SPEC92 [4], and oers a good
balance between instruction and data misses. Moreover,the IBS
includes user-level and kernel-level codes.In graphs illustrating
the remainder of the paper, the name of the workloads are set as
the concatenationof the rst two letters of the executed
applications. gsmp, for instance, refers to gs and mpeg play
runningsimultaneously. Our study has been limited to
multiprogramming environment, i.e. execution of
independentprograms. First, such a workload puts a greater stress
on the memory hierarchy than a parallel workload.Second, we did not
have access to traces of parallel applications including user-level
and kernel-level activities.4 Simulation ResultsThe simplest
measure for representing the behavior of a memory hierarchy on a
program is the miss rate.However, the execution of instructions
from independent threads, out-of-order, with non-blocking
caches,keeps the instruction pipeline and the functional units
busy. The miss rates have now far less signicance: amiss on the
cache does not imply eective penalty for the execution [6]. For our
evaluation, which is mostlyoriented towards caches, with a very
ecient fetch mechanism, the number of instructions executed per
cycle(IPC) is a good indicator of program behavior and will be used
as performance metric in the remainder ofthe paper.4.1 Contention
on L2 cache on simultaneous multithreadingThis section explores the
impact of contention on performance when executing several threads
simultaneously.A similar study had been conducted for
singlethreaded workloads to provide data on the dierent
applicationsused. Its results [8], were used to create groups of
benchmarks exhibiting various behaviors : high, low ormedium memory
pressure, high, low or medium cpu activity, ... We then simulated
dierent conventionalcongurations of memory hierarchy while
executing several threads together. Figure 2 shows the average3
-
IPC obtained for eight dierent groups of benchmarks, for a
degree-4 SMT, 32KB L1 caches and variousblock sizes and
associativities. The other parameters are set up to their default
values. The key 32K-lxxx-ayrefers to a cache with blocks of xxx
bytes and associativity degree y.0,00
1,00
2,00
3,00
4,00
5,00
6,00
gsjpmpnr resdvevi gsmpreve jpnrsdvi gsjpresd mpnrvevi gsnrrevi
jpmpsdve
!6%2!'%)0#
32k-l16-a1
32k-l16-a2
32k-l16-a4
32k-l32-a1
32k-l32-a2
32k-l32-a4
32k-l64-a1
32k-l64-a2
32k-l64-a4Figure 2: average IPC for 4 threads, L2 cache
contention taken into accountThe respective performances of our
various groups of benchmarks are very dierent. The peak
instructionparallelism is 8, which corresponds to the peak fetch
bandwidth. The best performing benchmarks hardlyexhibit an IPC
higher than 5. In the worst case (resdvevi, for a 32KB
direct-mapped cache and a block sizeof 64 bytes), the IPC is only
around 2 (ve and vi are two of the most L2 bandwidth consuming
applicationsin our benchmark set). This IPC is lower than for real
gcc, and just slightly higher than for the three otherprograms, if
they were running alone. This indicates that in some case,
simultaneous multithreading leadsto very low performances.0,0
10,0
20,0
30,0
40,0
50,0
60,0
70,0
80,0
90,0
100,0
gsjpmpnr resdvevi gsmpreve jpnrsdvi gsjpresd mpnrvevi gsnrrevi
jpmpsdve
/##50!.#92!4%
32k-l16-a1
32k-l16-a2
32k-l16-a4
32k-l32-a1
32k-l32-a2
32k-l32-a4
32k-l64-a1
32k-l64-a2
32k-l64-a4Figure 3: average L2 cache occupancy rate for 4
threadsFigure 3 illustrates the average L2 cache occupancies during
the simulations. The L2 cache occupancycan be viewed as the
fraction of time the L2 cache is busy processing accesses from the
L1 cache. For six ofthe eight groups of benchmarks, the occupancy
exceeds 50% whatever be the cache conguration. In severalcases, it
has nearly reached 100%. This has been possible because a miss will
result in only partially stallinga thread, while the other threads
may continue the execution. Except for one group of benchmarks for
asingle hierarchy conguration, the occupancy is always higher than
30%. One has to keep in mind that theseare only average values, and
only give an indication of how good or bad things are: contention,
i.e. conictsbetween accesses, may occur on the L2 cache even when
on average, the L2 cache occupancy is low. However,the correlation
between the measured performance (Figure 2) and the occupancy
(illustrated Figure 3) isquite clear. The higher the occupancy, the
higher is the contention and the lower is the performance. Thereis
no clear threshold after which the performance loss becomes
dramatic. The L2 cache \could" be busy100% of the time by ideally
spaced out requests without resulting in added penalties. On the
other hand,the L2 cache could be busy 10% of the time, but by
bursts of conicting requests.Figure 4 shows that the same
simulations realized without caring for contention on L2 cache give
farbetter results than in Figure 2. For all the groups of
benchmarks, the IPC is between 5 and 6. Theover-estimation of
performance varies, but can exceed 100%, and reaches 174% for
resdvevi, for a 32KBdirect-mapped cache with a block size of 64
bytes. This behavior is already true for one thread [8] but is4
-
0,00
1,00
2,00
3,00
4,00
5,00
6,00
gsjpmpnr resdvevi gsmpreve jpnrsdvi gsjpresd mpnrvevi gsnrrevi
jpmpsdve
!6%2!'%)0#
32k-l16-a1
32k-l16-a2
32k-l16-a4
32k-l32-a1
32k-l32-a2
32k-l32-a4
32k-l64-a1
32k-l64-a2
32k-l64-a4Figure 4: average IPC for 4 threads, assuming no
contention on L2 cachemagnied when several threads are running
together. Moreover, when the contention is ignored,
simulationresults for dierent cache congurations can lead to
misleading conclusions. Thus when ignoring L2 cachecontention for
all benchmarks, increasing block size allows higher performances. A
look at Figure 2 provesthis to be generally wrong. Finally, Figure
4 shows little variation in IPC between dierent mixes of threads.In
contrast, Figure 2 shows a much wider variation. This suggests that
the threads mix has little impact onsmall L1 caches, but has a
higher impact on large L2 caches.Figure 5 shows the average MPI for
the sequential and the parallel executions of the four
benchmarksconstituting each workload, for 32KB 2-way associative L1
caches with varying blocksize. The number ofmisses on the parallel
execution is approximately the double of a sequential execution,
which explains theincrease in contention on the L2 cache.0.000
0.010
0.020
0.030
0.040
0.050
0.060
0.070
0.080
0.090
gsjpmpnr resdvevi gsmpreve jpnrsdvi gsjpresd mpnrvevi gsnrrevi
jpmpsdve
-)330%2).3425#4)/.
SEQ-l16
PAR-l16
SEQ-l32
PAR-l32
SEQ-l64
PAR-l64
Figure 5: comparison between L1 miss rates for sequential and
parallel execution of 4 threadsThe remainder of this study will
explore in depth the impact of the size, the associativity, and the
blocksize of the memory hierarchy on the performance of an SMT
architecture.4.2 Cache sizeIn this section, we examine the behavior
of cache hierarchy when up to six threads are executing
simulta-neously, by xing instruction and data cache sizes to
successively 16KB, 32KB and 64KB bytes. The othercache parameters
are set to the default ones (32-byte blocks, 4-way
associativity,...). The impact of thecache size on the performance
is illustrated in Figure 6, through the resulting average IPC. Each
bar (IPC)represents the same number of applications executed either
sequentially (for one thread) or in sequences ofgroups of
benchmarks, a group of benchmarks consisting in the parallel
execution of 2, 4 or 6 programs.Each of our 8 benchmarks have the
same weight for the four considered congurations.For a single
thread, 4-way set-associative 32KB caches are sucient for most of
our applications. Cachesof this size are not the real limiting
factor of the performances. The benet from shifting from 16KB
to32KB allows a gain of 12% on the IPC. A shift from 32KB to 64KB
only enhances the IPC by 4%. Forseveral threads, this dierence in
performance is more important. Thus, for 2 threads, shifting to
32KBcache brings a net gain of 13%. A shift to 64KB is still
interesting, with a better performance of nearly 10%.5
-
0
1
2
3
4
5
6
1 thread 2 threads 4 threads 6 threads
!6%2!'%)0#
16 Kbytes
32 Kbytes
64 Kbytes
Figure 6: average IPC obtained with 16KB, 32KB and 64KB bytes L1
cachesAs expected, the cache size is a much more determining
parameter for 6 threads. The shift from 16KBto 64KB allows a gain
of nearly 30%, which represents more than one added instruction
executed per cycle.The L1 caches are shared among the running
threads, which allows some kind of dynamic adaptation ofthe
available space to the threads' needs (especially because we have
assumed here associative caches).However, this is true only up to a
certain limit; when too many \memory eager" threads are running
inparallel, the caches are permanently saturated. The number of
requests missing on the L1 cache results inincreasing contention.
Thus, as illustrated by Figure 7, for a 32KB L1 cache size with 6
threads runningtogether, occupancy is higher than 80% for most of
the groups of benchmarks. Conversely, with 64KBcaches, occupancy is
under 70% for most of the benchmarks.0
10
20
30
40
50
60
70
80
90
100
gsjpmpnrresd gsjpmpnrreve gsjpmpresdvi gsjpmprevevi gsjpnrsdvevi
gsmpnrsdvevi jpnrresdvevi mpnrresdvevi
/##50!.#92!4%
32k-l32-a4
64k-l32-a4
Figure 7: average L2 cache occupancy for 6 threads, with 32KB
and 64KB L1 cachesThis emphasizes the importance of tuning well the
number of threads to the cache size. When the cacheis too small,
the benet of executing a larger number of threads is tiny. An
increase in the number ofsimultaneously supported threads should be
accompanied by an increase of cache size. However, in
modernmicroprocessors, the size of the L1 cache is among one of the
sensitive parameters which xes the maximumclock cycle. A larger
cache implies a lower clock frequency (or pipelined access).
Moreover, to get theseperformances we allowed respectively two and
four accesses per cycle to the instruction and data caches.The
added hardware complexity implies an even more extended cycle time.
Within the parameter rangethat we explored, whatever be the cache
size, supporting 6 threads does not bring a real speed-up
comparedto 4 threads, and is not worth the added hardware
complexity.4.3 Associativity and block sizeFigure 8 illustrates the
average IPC for 64KB L1 caches and 16KB L1 caches for various
associativities andblock sizes. We notice that, as for one thread,
a higher associativity degree allows a higher performancewhen
several threads are used. However, the phenomenon is emphasized
when the number of threadsincreases. The main reason for this is
that the memory references generated by the simultaneous
executionof independent threads exhibit less spatial locality than
that of a single thread. Conict misses have then ahigher
probability to happen than for a single thread. Increasing the
associativity limits conict misses [5]6
-
(but extends the access time). As illustrated in Figure 8, this
appears far more critical when the L1 cachesize is small.0
1
2
3
4
5
6
1 thread 2 threads 4 threads 6 threads
!6%2!'%)0#
l16-a1l16-a2l16-a4l32-a1l32-a2l32-a4l64-a1l64-a2l64-a4
64K L116K L1
Figure 8: average IPC with varying associativity and block size
of 64KB and 16KB L1 cacheFigure 8 also shows that the choice of the
block size is even more critical than the choice of
associativitydegree. For a single thread, using a 64-byte
block-size (four times the bus width) results in roughly the
sameperformance as a 32-byte blocksize and only slightly higher
performance than the 16-byte one. When thenumber of threads
increases, this is no longer true. For two threads, using a 64-byte
block already leads toworse performance than using 16-byte or
32-byte blocks. This comes mostly from the contention on the
L2cache, as illustrated in Figure 3. The block size's impact on L2
cache is dierent than previously observedfor the associativity or
the cache size. When the associativity degree or the cache size are
increased, theL1 caches miss ratio decreases. This results in less
accesses to the L2 cache. Likewise, when the block sizeincreases,
it results in a small decrease of the miss ratio and so less
transactions on the L2 cache. However,each transaction keeps busy
the L2 cache for a longer period, thus potentially delaying other
miss servicing.The induced extra penalty widely exceeds the benet
of a lower miss ratio. Indeed, the time a transactionkeeps the L2
cache busy is double if the block size is doubled.As the number of
threads increases, this phenomenon is amplied, and the L2 cache
becomes a criticalresource. The memory requests which miss in the
L1 caches are delayed more and more, and this resultsin added
stalls of the instruction pipeline. Adding more threads makes this
even worse and can conductto lower performances. Thus, as
illustrated in Figures 8, average IPC with a cache block of 64
bytes canbe lower for 6 threads than for 4 threads. The problem of
contention is such for 6 threads that even with32-bytes cache
blocks, the performances are slightly lower than for 16 bytes cache
blocks.0
1
2
3
4
5
6
1 thread, 16Kbyte L1 caches 2 threads, 32Kbyte L1 caches 4
threads, 64Kbyte L1 caches
!6%2!'%)0#
l16-a1
l16-a2
l16-a4
l32-a1
l32-a2
l32-a4
l64-a1
l64-a2
l64-a4
Figure 9: making varying associativity and block size, L1-cache
size proportional to the number of threadsIn the simulations
illustrated in Figure 9, we have set the size of the L1 caches
proportionally to thenumber of threads. Thus, for one thread, we
have L1 caches of 16KB, and for 4 threads, the size is 64KB.This
shows that the phenomenon described previously involving the
associativity and the block size aremostly dependent of the number
of threads, and are amplied when the size of the L1 caches is
small.7
-
5 Concluding RemarksSimultaneous multithreading is a very
interesting way to enhance performance as the needed hardware canbe
easily integrated to a superscalar architecture and thus limiting
the design cost. However, one has tobe very careful with the choice
the memory hierarchy. In this study, we showed that contention on
the L2cache cannot be ignored. If for singlethreaded architectures
it leads to strongly over-estimate the IPC onecan expect, for
multithreaded architecture, it is more dramatic. For 4 threads
executing simultaneously,over-estimation over 100% is not rare.
Moreover, we showed that for instance on the choice of block
size,ignoring L2 cache contention can lead to incorrect conclusion,
as several behaviors having negative impacton performance are not
shown.We showed that the maximum number of supported threads has to
be set up according to the cache size.With small L1 caches, the
trac to the L2 cache generated by extra threads rapidly degrades
performance.Executing more threads can then dramatically pull down
the overall system performance. The L1 caches haveto be
associative. Impact of associativity was shown to be far more
important for SMT than for singlethreadedarchitecture. Finally we
showed that small L1 cache blocks have to be used. In our
simulations, using a32-byte and especially a 64-byte block size
leads to lower performance than a 16-byte one.A bad choice of the
memory hierarchy parameters can result in very bad behavior when
the numberof threads increases. Thus for example when using a
direct-mapped 32KB cache and a 64-byte block size,performance is
signicantly lower for 6 threads than for 4 threads. However, if
keeping small cache blocksdoes not induce serious hardware
diculties, the size and the associativity of L1 caches are more
sensitiveparameters. Their combination generally xes a
microprocessor's cycle time. The larger the cache, thelonger is the
cache access time. Using associativity may lead to the use of
longer cycle or extra load usedelay (3 cycles for instance on the
DEC21264). The implementation of support for several threads has
alsoa hardware cost which should also be prohibitive compared to
the small gain in performance that a shiftfrom 4 to 6 threads can
oer.Thus, for general purpose microprocessors supporting a standard
memory hierarchy and running IBS likeworkloads, simultaneous
multithreading is promising but should not be interesting for the
execution of morethan a few threads. Moreover, as this study has
pointed out that the L2 cache is already a major bottleneckwhen
several threads execute simultaneously, multithreaded execution on
an SMT will not take the sameadvantage of new anticipating
techniques (fetching two basic blocks per cycle, predicting or
anticipating loadaddresses, ...) as a singlethreaded
execution.References[1] D. M. Tullsen, S. J. Eggers, and H.M. Levy.
Simultaneous Multithreading: Maximizing On-Chip Paral-lelism. In
22nd ISCA, June 1995.[2] D. M. Tullsen, S. J. Eggers, J. S. Emer,
H. M. Levy, J. L. Lo, and R. L. Stamm. Exploiting
Choice:Instruction Fetch and Issue on an Implementable Simultaneous
Multithreading Processor. In 23th ISCA,May 1996.[3] N. P. Jouppi
and S. J. E. Wilton. Tradeos in Two-Level On-Chip Caching. In 21st
ISCA, April 1994.[4] R. Uhlig, D. Nagle, T. Mudge, S. Sechrest, and
J. Emer. Instruction Fetching: Coping With Code Bloat.In 22nd ISCA,
June 1995.[5] S. A. Przybylski. Cache and Memory Hierarchy Design :
A Performance-Directed Approach. MorganKaufmann, 1990.[6] A. Seznec
and F. Loansi. About Eective Cache Miss Penalty on Out-Of-Order
Superscalar Processors.TR IRISA-970, November 1995.[7] D. Kroft.
Lockup-Free Instruction Fetch/Prefetch Cache Organization. In 8th
ISCA, May 1981.[8] S. Hily and A. Seznec. Contention on 2nd Level
Cache May Limit the Eectiveness of SimultaneousMultithreading. TR
IRISA-1086, February 1997. 8
