On Sat, 2011-03-05 at 22:15 -0800, Nick Brown wrote: > Parallelization probably isn't too big of a deal for today's typical > software engineer. Concurrency, on the other hand is, regardless of > the number of cores on your system. How many people still write [ . . . ]
You are joking aren't you? Concurrency and parallelism are subtly different things whilst at the same time being subtly the same thing -- at least in computing jargon. The average software engineer / software developer / programmer appears to be fairly poor at either. Parallelization is just as big a deal as concurrency. The interesting question is "When?" as much as "How?". The shift from increasing clock speed to increasing core count was fairly inevitable given chip engineering and physics. The dominance of the computational, aka HPC, mindset with regard to the new era of pervasive parallelism was also fairly predictable. The reemergence of actor models, dataflow models, CSP, data parallelism models, was definitely predictable -- and due to their history of being related to speeding up computation in HPC reinforces the HPC-related mindset in the discussion. The rise of GPGPU for data parallel computations as well as graphics ones -- graphics ones generally being a form of data parallel computation, of course -- has reinforced the focus being on computation. Application such as OpenOffice.org and that ilk have very restricted parallelization opportunities, they are even-driven systems best handled by event-driven architectures and frameworks -- though the event handlers may be able to harness parallelism in short bursts. The focus surely has to be not on so much on parallelization of a given application but on the parallelization of the whole set of applications running concurrently (*). This is as much an operating system and hypervisor issue as an application programming one. The real problem the chip manufacturers have is memory, not processors. Tilera, Intel, NVIDIA, AMD, etc. have basically solved the problem of packing more processors in grids. Great for HPC computation, irrelevant for OpenOffice.org. Tilera even have nice ways of creating processor groups by making the hypervisor integral firmware (I believe Intel are going this route as well). This gives the beginnings of an integrated view of hardware, operating systems (plural), and applications. The problem is and will remain memory bandwidth. The era of a single central memory is coming to an end. Processors will have to move to distributed memory. The new issues will be more analogous to the distributed computing issues of clusters, but at processor speeds not network speeds. In this context, shared-memory multi-threading isn't even an enabling technology, it's a backward looking hindrance. Does this mean that Java, indeed the whole JVM milieu as we know it ceases to be relevant? There is a danger of this. The Java Platform has increasingly become a "big iron" platform with a traditional view of "big iron". The new systems have to be based of graphs of smaller processors. Can the Java Platform cope with this second phase of what is the Multicore Revolution? (*) Notice the original meaning of concurrent here, a synonym for parallel, computing has hijacked this term with a subtly different meaning :-) -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
