MSDN Magazine - October 2008 - (Page 86) C O D I N G TO O L S Improved Support For Parallelism In The Next Version Of Visual Studio Stephen Toub and Hazim Shafi It wasn’t too long ago that many software performance bottlenecks could be fixed simply by a trip to the local computer store. Consumers and companies with the means and motivation to buy new computers every 18 to 24 months would find with every new purchase their compute-intensive applications running twice as fast as before. Alas, those good old days would appear to be behind us. Gone are the days of exponential increases in CPU speed, largely due to pesky laws of physics that are preventing hardware manufacturers from economically and ecologically scaling clock speeds at rates anywhere near to what we’re accustomed to—and to what modern advances in software demand. Instead, the influx of transistors as This article is based on prerelease versions of Visual C++, Visual Studio, and the .NET Framework. All information herein is subject to change. This article discusses: • Expressing parallelism in managed code • Expressing parallelism in native code • Debugging parallel applications • Profiling parallel applications Technologies discussed: Visual Studio, Multithreading 86 msdn magazine outlined by Moore’s law is enabling chip manufacturers to exponentially scale the number of cores available in commodity hardware. Today, it’s rare to find single-core machines on sale in the United States, with dual-core being the norm. Next year, expect the typical consumer machine on sale to be a quad-core, with eight-core as the norm to follow shortly thereafter. Unfortunately, the majority of the software today will not automatically take advantage of such exponential growth in processor count. To do so, software must be written in a manner that supports safe and effective decomposition of its constituent components such that these individual parts can be computed in parallel and distributed across all of the cores, thus realizing the potential that multicore and manycore systems promise. Such expression of parallelism with today’s preeminent programming languages, frameworks, and development environments is no cakewalk. Multithreaded programming, for anything but the most trivial of systems, is incredibly difficult and error prone today. Parallel patterns are not prevalent, well-known, or easy to implement. Even when an application can be constructed to take advantage of concurrency, functional correctness and performance problems frequently arise, from the most well-known race conditions and deadlocks to the more obscure cache coherency overheads, lock convoys, and priority inversion. Moreover, even if developers were able to conquer such patterns, the time and effort involved in doing so places a burden on busi-
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.