Dr. Dobb's Journal - September 2008 - (Page 52)

d09levent_p3db 7/14/08 10:03 AM Page 52 State of the Art MANAGING APPLICATION THREAD USE is increasingly becoming an everyday scenario. Therefore, the idea behind the mix run is to simulate this case. During the simulation, a single instance of each multithreaded benchmark was executed simultaneously. The pseudocode for the mix simulation can be given as follows: # of instances here was set to 1 and then 2, respectively. for threshold in 5 10 15 20 do start governor -thresh -sched for load in {prime, mandel, md, matvec} do for i in # of instances do start load sleep done done stop governor done Figure 4: Single instances of each benchmark are executed in parallel. Figure 5: Intel Thread Profiler analysis showing how one benchmark increases its OpenMP worker threads dynamically within the framework. Uniform Test Results This scenario was simulated with two and four instances of each benchmark. The pseudocode for the uniform simulation can be given as follows: The # of instances in the simulation was set to 2 and 4, respectively. for threshold in 5 10 15 20 do for load in {prime, mandel, md, matvec} do start governor -thresh -method for i in # of instances do start load sleep done wait_for_all_loads_to_finish stop governor done done instances of the benchmarks (loads), the aggregate elapsed time can be reduced anywhere from 5–20 percent. These results also show that if the number of instances of a benchmark running in parallel is increased, then aggregate elapsed time can be decreased further. Each instance of any benchmark is capable of fully utilizing all cores on the system; therefore, various threshold values used in the simulation didn’t make a significant difference. Again, the first instances of each load will get the maximum thread count, which is equal to the number of physically available processors/cores. This ensures that the first benchmark to start will complete as fast as possible while others run slower. In Figure 4, the total speed-up (that is, decrease in elapsed time of all benchmarks running simultaneously) is 1.23x. Only one out of four benchmarks (matvec) was negatively impacted in this simulation run. After analyzing all the simulation results, it became clear that with this framework, the execution time of each benchmark, and the order in which they are started, made a difference in the aggregate performance. The best aggregate elapsed time improvement was achieved when the benchmark that takes the least amount of time to complete was started first, and the second fastest benchmark as the second. This can be explained in the following manner: Let Li be any given benchmark (load), TLi be the execution time for a benchmark, and n the number of benchmarks. If benchmarks’ time to completion is: TL1 <..<TL(i-1) < TLi <…<TLn then the best results are achieved when L1 is started first, then L2. However, it is not guaranteed that L1 will pick up the available cores when L1 completes; any benchmark can pick up the available cores based on the fact that they communicate with the load governor independently and based on their Mix Run Test Results In the real world, however, it is more common to have multiple multithreaded applications running in parallel and competing for the limited number of cores available on the system, rather than running the same application in parallel. As multithreaded applications are more widely available, this The uniform simulation results (Figure 3) show that regardless of the number of 52 Dr. Dobb’s Journal l www.ddj.com l September 2008 http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - September 2008

Dr. Dobb's Journal - September 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Developer’s Notebook A Conversation With Erik Demaine Application Lifecycle Management Meets Model-Driven Development Building a Robust Development Environment Real Users Really Matter Matching Wildcards: An Algorithm The Android Mobile Phone Platform Managing Application Thread Use Signalling Integer Overflows in Java .NET Development & the IBM WebSphere Portal Server The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - September 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.