On 7 January 2011 13:50, Carl Jokl <[email protected]> wrote: > This is somewhat related to the topic or at least the spirit of why > the statement was made. > > Considering that even when some tasks are capable of being split up > and executed in parallel it is not always a performance win to do so > vs processing sequentially I wonder how valid the current push for > highly parallel processing and very high numbers of cores. There is > already a fair amount of code which has to be executed sequentially. > > Fine-grained concurrency *is* becoming much more relevant. As parallelism shifts from multi-processors in the HPC world towards multi-cores on the desktop (think 1000+ cores), new levels of support will be implemented on the hardware, and the cost of synchronizing threads will drop dramatically. For example, one current trick is for a core to listen in on another core writing data out to the L2 cache, so it doesn't have to re-fetch data on hitting a memory barrier, we'll only see more of this sort of thing in the future.
Core counts will soon push up to 3 figures and beyond. At this point imperative paradigms, laden with side-effects, are really going to struggle to manage more than a handful of threads. Given that people and their ingrained habits are so much slower to change than the technology we use, it seems vital that the developer community as a whole should already have started shifting towards designs and paradigms that will scale well in this brave new world. -- Kevin Wright gtalk / msn : [email protected] <[email protected]>mail: [email protected] vibe / skype: kev.lee.wright twitter: @thecoda -- 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.
