Print

Guest View: Java + multicore = good news



Email
October 15, 2008 —  (Page 1 of 4)
Dual-core processors are ubiquitous in desktop computers and laptops today; four to eight cores are common in servers, and within the lifetime of the next version of the JDK (Java 7), we are likely to see servers with dozens of cores become available in bulk.

Moore’s Law has given us unimaginable increases in computing power for more than over a generation. But a few years ago—as CPU thermal densities approached that of a small furnace—the strategy of cramming ever smaller transistors on chips that run at ever increasing frequencies seemed destined to hit a wall.

So chip designers pulled a new trick out of their sleeves: They leveraged the increasing transistor densities to fit more cores onto a single chip. While Moore’s Law continues to fit more transistors on chip, it is no longer a given that each new generation of CPUs will automatically run our existing algorithms faster.

It is now up to us to ensure that our code is ready to take advantage of the new generation of multicore CPUs. Our current theory, algorithms, languages and tools have all evolved around the sequential paradigm. The move to a truly parallel world will be a fundamental shift.

At first glance, the task of parallelizing our applications looks no different from multithreaded programming. The Java language is widely praised for having a simple yet powerful threading model that makes writing effective multithreaded applications mainstream. It may therefore seem likely that the ease of writing multithreaded applications will enable us to surmount the challenge of writing multicore applications, but in practice it may not be so easy.

The canonical multithreaded application in Java (such as the Web or application server) processes multiple users or connections concurrently, in multiple threads. That architecture is not only well understood, it is also very well supported by underlying frameworks, whether Web or application servers, to the extent that the average programmer hardly has to think about this issue. The complex tasks for thread pooling and scheduling are efficiently handled, and effectively hidden, by the framework. All we need to do as application programmers is write out servlet or Enterprise JavaBeans on the correct template, and we’re good to go.



Related Search Term(s): Java, multicore, software development

Pages 1 2 3 4 


Share this link: http://sdt.bz/32943
 


Comments


02/11/2009 10:09:50 AM EST

Multicore servers will face the demands of developers to replace network/LAN traffic by in-machine messages. So they will have to offer fine tuning tools for process and resource communication and prioritizing which are machine specific and OS native. Please understand that I am sceptical when we talk about Java using these interfaces as long as I do not see a valid USB library - maybe I missed there sth actual but the problems there where impressing me deeply. I think forking/unforking is only part of the problem and definetely the article does NOT describe a Java specific advantage through technology.

Germanythomas wellbrock


02/11/2009 03:45:21 PM EST

Avik Thanks for the article. It's interesting to see the Java fork/join, and contrast it with the Erlang approach. One question and one comment: Do you think Fibonacci is a good candidate for parallisation? Essentially you are doing almost double the processing effort to compute any given Fibonacci number, since the previous result is not re-used as per dynamic programming. I.e. the 2x speedup can be gained by using a better sequential implementaion. Putting aside the issue of the suitability of the Fibonacci example, I think some readers would be interested to see an Erlang solution to a parallel Fibonacci problem. It uses a parallel map implementation that I've mentioned here: http://21ccw.blogspot.com/2008/05/parallel-quicksort-in-erlang-part-ii.html, which is about 12 lines of code. And the implementaiton (without the threshold support): p_fib(0) -> 0; p_fib(1) -> 1; p_fib(N) -> [F1, F2] = pmap:pmap(fun p_fib/1, [N-1, N-2]), F1 + F2. Which basically maps a function over a list, and the function is evaluated in a separate Erlang process (NOT related to OS processes). To me this is a much simpler (and hence more reliable solution). YMMV Benjamin

United KingdomBenjamin Nortier


close
NEXT ARTICLE
News Briefs: July 15, 2008
Enea is named to the board of CP-TA, Teradata introduces a new version of its data warehousing tool and SOA Software upgraded its Repository Manager to accommodate its Policy Manager software Read More...
 
 
 




News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>

   
 
 

 


Download Current Issue
APRIL 2014 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?