• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Will threaded apps automagically benefit from n-core?

 
Robin Sharma
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy!

There's a lotta talk about parallelism and multi-core processors doing the rounds. So, if i have an already threaded Java app, wouldn't it just automagically run faster if moved from a single core to an n-core architecure? Or would it require some additional changes/tweaks/reconfigs etc?

Thanks.
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Depends on whose JVM you're using, but if it's Sun's, then I believe it will use all the cores/CPUs that are available. That's without you needing to do anything special.

What is does require you to do is to write your code in a multi-threaded way. Multiple core/CPUs won't much benefit a single-threaded program. Although Java always has some extra system threads, so no Java app is truly single-threaded.
 
Robin Sharma
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Peter Chase:
Depends on whose JVM you're using, but if it's Sun's, then I believe it will use all the cores/CPUs that are available. That's without you needing to do anything special.

What is does require you to do is to write your code in a multi-threaded way. Multiple core/CPUs won't much benefit a single-threaded program. Although Java always has some extra system threads, so no Java app is truly single-threaded.


Peter, are there any sample multi-threaded Java programs which I can run on the two types of architectures and see the actual difference? I mean some sort of benchmark Java programs written specifically for this purpose. Or if I have to write one, what should it do to best highlight the performance difference?

I have a single core and a dual core m/c available, and both have Sun's JDK 1.6 u2.

Thanks.
 
Henry Wong
author
Marshal
Pie
Posts: 21490
84
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Robin,

Sun switched to use the native threading libraries many many versions ago. This means on Windows, Java threads will map to windows threads. On Linux, to posix threads. On Solaris, to Solaris threads. Etc...

Whether a thread will use a different processor core, or stay on the same core as other threads, is completely dependant on the underlying thread system. For Windows, Linux, and Solaris, the native threading system will use all the cores available.

The easiest way to test this is to write a runnable class that spends some time doing something compute intensive. It can't be doing I/O or anything that just eats up time (like sleep or wait) -- but something like calculating the fibonacci sequence or something. Also these operation should not share any variables or do any type of synchronization.

If you start one thread with this class, it should take X time to compete. If you start two threads, it should also take the same X time to compete. Etc. This will keep going until you reach the number of processor cores available on your machine. Then you will degrade, as the cores will need to take on the task of more than one runnable each.

Henry
 
Robin Sharma
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Henry Wong:
Robin,

Sun switched to use the native threading libraries many many versions ago. This means on Windows, Java threads will map to windows threads. On Linux, to posix threads. On Solaris, to Solaris threads. Etc...

Whether a thread will use a different processor core, or stay on the same core as other threads, is completely dependant on the underlying thread system. For Windows, Linux, and Solaris, the native threading system will use all the cores available.

The easiest way to test this is to write a runnable class that spends some time doing something compute intensive. It can't be doing I/O or anything that just eats up time (like sleep or wait) -- but something like calculating the fibonacci sequence or something. Also these operation should not share any variables or do any type of synchronization.

If you start one thread with this class, it should take X time to compete. If you start two threads, it should also take the same X time to compete. Etc. This will keep going until you reach the number of processor cores available on your machine. Then you will degrade, as the cores will need to take on the task of more than one runnable each.

Henry


So Henry, from a Java standpoint, programming for multi-core wouldn't be different from programming for single core, if the application being designed is already threaded, right? The underlying OS would take care of the rest. Or do you see any gotchas that might happen when a threaded Java application is moved to an n-core architecture?

Thanks.
 
Henry Wong
author
Marshal
Pie
Posts: 21490
84
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Or do you see any gotchas that might happen when a threaded Java application is moved to an n-core architecture?


The main issue is probably the timing. Subtle race conditions which doesn't normally appear on a machine with 4 processor cores will likely occur on a machine with 200 processor cores.

Henry
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic