I agree with Reinier, there's a couple of points that tend to be ignored when discussing fine-grained parallelism.
- How many applications are actually CPU bound? Many tend to be I/O bound (network, disk) and additional cores or CPU speed doesn't add anyway near as much performance as an SSD or a smart distributed cache. - A very large number of business problems are highly contended and can not be parallelised. - Arguments for fine grained parallel implementations tend to ignore the cost of getting the data split across multiple cores. The most expensive operation on a modern CPU (excluding I/O) is a cache load, so there is a limit to the granularity to which parallelisation can be applied. The size of any data partition must be large enough to overcome that cost. - There is a complexity cost to parallelising a sequential algorithm. I worked with Joel Neely at this year round-up implementing a parallel string splitting algorithm using Scala. Unfortunately when run in parallel it actually went slower due to the copy cost of Scala's immutable list implementation (I dropped some detail onto the fortress list: http://article.gmane.org/gmane.comp.lang.fortress.general/858). I needed 16 cores to get it up to twice as fast and the an alternative simple imperative version was still an order of magnitude faster. - Despite what most people think, newer CPUs are continuing to improve the performance of single threaded code. The simple string splitting algorithm from above run 50% quicker on a Nehalem EX @ 2.4GHz than a Core 2 Duo also running @ 2.4GHz. With a Sandy Bridge CPU it should be even quicker again. Clock speed is not the only thing that determines CPU performance. L1, L2 & L3 cache size and speed, more instruction units, more registers, increased memory throughput, etc all play a part. Parallelisation is just another tool among many for achieving improved performance (albeit a very powerful one). My fear around the current trend toward focusing (perhaps obsessing) on parallelisation, rather than focusing on the actual business problem and picking the right tool for the job, will lead to solutions that amount to pushing square pegs into round holes. Resulting in unnecessarily complex solutions that may not be any faster. Mike. -- 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.
