MSDN Magazine - December 2008 - (Page 18)

dedicated machines (no other significantly expensive applications were running at the same time). But although there was not much noise, there were unexpected variations that were quite difficult to understand. In real-life systems, it will often be the case that more than one application (and hence more threads) is competing for the resources. In the case of our ThreadPool, noise may even be introduced by different application domains executing at the same time. appearance that the app is being productive when in reality it’s wasting CPU time. This also happens in single-processor environments, but it becomes more obvious in manycore. As we’ve seen, defective concurrency control can increase the occurrence of certain problems, even more if parallelism is used. Additionally, concurrency management for multiple tasks has become even more challenging when multiple cores are present. One example is related to the memConcurrency Level ory hierarchy issue. Trying to follow a Figure 2 Throughput as a Function of Concurrency Concurrency Control simple rationale based on the example Level The number of threads in an enviin Figure 2, increasing concurrency ronment (concurrency level) is very important since it affects the levels up to some point can be beneficial; however, in a multicore behavior and performance of the environment and its applications. environment it is not trivial to determine where the threads are For instance, a low concurrency level with one thread per core is needed. For instance, if a processor is being overloaded for some desirable for apps that are CPU-intensive (furthermore, the mini- reason (due to bad scheduling, for example) while the other promum number of threads in a system is usually set to be the same as cessors are being under utilized, the overall throughput can be the number of cores). On the other hand, high concurrency levels very low, but when new threads are added they could be assigned can result in excessive context switching or resource contention. erroneously to the wrong processing unit. Figure 2 shows a typical example of how the concurrency level Conversely, if the concurrency level is very high but the overall affects the performance of an app. (Note that the blue dots are ob- throughput is starting to degrade, we could decide to start removing servations captured at each concurrency level. The black line shows threads, but the threads removed could be taken away from those the fitted curve for these experiments to processors that actually need them and help us visualize the type of function that whose throughput in particular could be describes the behavior.) The way we meaimproved by adding more threads. sure performance in this context is with Figure 3 shows how naively trying to throughput, which is measured as number change the concurrency levels can result of completed WorkItems per second. in unexpected behavior. The experiment This plot was generated using an exconsists of a series of runs of a test appliperimental app that runs WorkItems for cation using different amounts of work to a certain time (each WorkItem has 100ms execute (WorkItems) and the execution of execution time with 10ms of CPU usage time of each WorkItem (workload). and 90ms of waiting). The experiment was In the top section of Figure 3 are the run several times on a dual-core 2GHz results for this test running on the Threadmachine to collect the data and evaluate Pool. The throughput is poor but shows Workload possible noise and variations. The theosome consistency along all of the trials. retical maximum for the throughput on The bottom half of Figure 3 shows the this machine is 200 completions per secresults obtained by making some naive ond at a concurrency level of 20. Howadjustments to the concurrency control ever, we can see that, experimentally, the logic to try to improve the way threads are throughput peaks at 150 a little bit before added and removed. We can see that there the concurrency level of 20 is reached, are many variations in the throughput, and then it degrades. The degradation is and regardless of the amount of work, the mainly due to context switching. adjustments result in what seems more During this experiment, the CPU was like noise than better control. maximized (however, after a certain point Some points may appear to be improvthis does yield optimal throughput). A ing for specific combinations of values, Workload 100% CPU usage can mean that data is which suggests that different types of conbeing pulled from memory for threads Figure 3 Changing Concurrency Levels Can currency control adjustments are necesthat aren’t really being used; this gives the Result in Unexpected Behavior sary depending on the type of app. Throughput 18 msdn magazine Throughput Throughput CLR Inside Out

Table of Contents Feed for the Digital Edition of MSDN Magazine - December 2008

MSDN Magazine - December 2008 Contents Toolbox CLR Inside Out Advanced Basics Cutting Edge Patterns In Practice Team System Real-World WF Visual Studio OBA Tools SOA Data Access Geneva Framework Test Run Foundations Windows With C++ Going Places End Bracket

MSDN Magazine - December 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.