Simultaneous multithreading (SMT) is an interesting way of maximizing performance by enhancing processor 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 can expect and may lead to incorrect conclusions. We then explore the impact of various memory hierarchy parameters. We show that the number of supported threads has to be set-up according to the cache size, that the L1 caches have to be associative and small blocks have to be used. Then, the hardware constraints put on the design of memory hierarchies should limit the interest of SMT to a few threads.
To achieve high performance on a single process, superscalar processors now rely on very complex out-of-order execution. Using more and more speculative execution (e.g. value prediction) will be needed for further improvements. On the other hand, most operating systems now offer time-shared multiprocess environments. For the moment most of the time is spent in a single thread, but this should change, as the computer will perform more and more independent tasks. Moreover, desktop applications tend to be multithreaded. A lot of users should then be more concerned with the performance throughput on the workload than with the performance of the processor on a single process. Simultaneous multithreading (SMT) is a promising approach to deliver high throughput from superscalar pipelines. In this paper, we show that when executing 4 threads on an SMT processor, out-of-order execution induces small performance benefits over in-order execution. Then, for application domains where performance throughput is more important than ultimate performance on a single application, SMT combined with in-order execution may be a more cost-effective alternative than ultimate aggressive out-of-order superscalar processors or out-of-order execution SMT.
In this paper, we examine the behavior of three of the best performing branch prediction strategies proposed in the literature while executing simultaneously several threads of instructions. Our simulations show that in a multiprogramming environment, if the sizes of the tables (PHT/BTB) are proportional to the number of active threads, there are very few interactions. With parallel workloads, we could have expected a beneficial sharing effect. In fact, it is very dependent an the branch predictors and in the best case, the gains stay very limited. We also show that, for the three predictors, whether in multiprogramming or in parallel processing, if the sizes of the tables are kept small, conflicts in the BTB induce a significant increase in mispredictions. However, for parallel processing with the gshare scheme, the resulting misprediction ratios for 2 or 4 threads stay below those exhibited by 1 thread. Finally, we study the impact of the addition of one Return Address Stack per context and show that a 12-deep stack per thread is sufficient to enhance greatly the accuracy of branch prediction.
'%3e%3ccircle r='20' fill='%23008'/%3e%3ccircle r='17.5' fill='%23fff'/%3e%3ccircle r='3.5' fill='%23008'/%3e%3cg id='d'%3e%3cg id='c'%3e%3cg id='b'%3e%3cg id='a' fill='%23008'%3e%3ccircle r='.875' transform='rotate(7.5 -8.75 133.5)'/%3e%3cpath d='M0 17.5.6 7 0 2l-.6 5L0 17.5z'/%3e%3c/g%3e%3cuse xlink:href='%23a' transform='rotate(15)'/%3e%3c/g%3e%3cuse xlink:href='%23b' transform='rotate(30)'/%3e%3c/g%3e%3cuse xlink:href='%23c' transform='rotate(60)'/%3e%3c/g%3e%3cuse xlink:href='%23d' transform='rotate(120)'/%3e%3cuse xlink:href='%23d' transform='rotate(-120)'/%3e%3c/g%3e%3c/svg%3e)
'%3e%3cpath fill='%23012169' d='M0 0v30h60V0z'/%3e%3cpath stroke='%23fff' stroke-width='6' d='m0 0 60 30m0-30L0 30'/%3e%3cpath stroke='%23C8102E' stroke-width='4' d='m0 0 60 30m0-30L0 30' clip-path='url(%23b)'/%3e%3cpath stroke='%23fff' stroke-width='10' d='M30 0v30M0 15h60'/%3e%3cpath stroke='%23C8102E' stroke-width='6' d='M30 0v30M0 15h60'/%3e%3c/g%3e%3c/svg%3e)
