No, parallelization is only a special type of concurrency (at least as the terms are used in the software engineering discipline, if you don't like those terms I'll quote C. S. Lewis, "When I use a word,' Humpty Dumpty said in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less"). The latter is growing in importance when dealing with operations that are CPU bound, though realistically still not a major concern for most applications today. The former is a major concern in virtually any software application.
On Mar 6, 5:25 am, Russel Winder <[email protected]> wrote: > 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 > < 1KViewDownload -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
