>>
Passionate about your results
  About Us      Services      Products    Industries  Partners    Careers    Awards News Contact Us 29

Stay connected with the
worldwide business
community
Multi-Core Processors – The Java vs. .NET Battle Tuesday, February 16, 2010

When CPU clock speeds accelerated past the 1 GHz mark, there were many who predicted that the 10 GHz mark was in sight. However, this proved to be premature as, manufacturing challenges apart, an exponential increase in clock rate led to corresponding increase in generated heat.

Parallelism presented itself as a viable alternative. While six core processors are available today, eight cores will be ready within the year. GPU cores are already running into their hundreds.

Parallelism necessitated custom software, and threads were introduced to leverage availability of multiple cores. But, along with threads, comes the problem of synchronization i.e. the ability to correctly manipulate collections (i.e. data structures) since the same list, map, or queue may end up being manipulated by different threads on different cores.

Java and C#, both being object oriented programming (OOP) languages with mutable data structures, have been trying to address this challenge for a while. Java 1.5 introduced the Java.util.concurrent package with concurrentXXXX collections and java.utilatomic with atomicXXX datatypes.

.NET 4.0/C# has now caught up with TaskParallel Library (See link below)

http://software.intel.com/en-us/blogs/2009/04/08/concurrent-collections-for-c-using-parallel-extensions/

This however has some limitations. Read comments from Gaston Hillar in the above link as explained here . . .

http://blogs.msdn.com/pfxteam/archive/2010/01/26/9953725.aspx

So does it mean Java is automatically multicore friendly?

No, but they “seem” to have made a very smart move. They just wrapped Intel Thread Building Blocks (TBB)

http://habanero.rice.edu/Habanero_Home.html
http://habanero.rice.edu/cnc.html

The brains behind Habanero Java…

http://www.media.rice.edu/media/NewsBot.asp?MODE=VIEW&ID=11728

But, it’s not part of standard Java yet. Also even if it’s possible to “parallelize” recursive functions (read Brian Goetz’s Java Concurrency in Practice — Applying Thread Pools) with ScheduledExecutorService, why should one do that?

Because there is the alternative of Functional Programming. Functional programming eliminates the need for synchronization by making data structures immutable and functions parallelizable.

But Haskell is hard. So Microsoft introduces F# — a diluted Haskell, but still better than C# & Java — with no synchronization issues

As it stands, Habanero Java is ahead of .NET Task Parallel Library, but .NET has F#. And the dance continues…

Posted by Srinivasan Balram | No Comments
Post a Comment

Name:


Email Address:


Website:


Comments:


 
  Blogger Profiles
 
 
 
 
  Linked in
 
 
 
 
  Marlabs on
Facebook
 
 
 
 
  Follow us
on Twitter
 
 
 
 
  Read our Feed