T
Travers Naran
Braving the fearful stories of fatal bugs (which seems to be related to
your for loop predicate changing while the loop is running), I plunged
into Java 7. Specifically to explore...
*orchestral chord*
java.util.concurrent
OK, I admit this is melodramatic, but so far, I am noticing some
interesting and curious things.
System:
* Windows 7 64-bit
* Java 7 SDK with NetBeans
* Pentual dual-core E5200 @ 2.50 GHz per core
* 4 GB RAM
My test program: the world's simplest (or dumbest) Mandelbrot set
plotter complete with color mapping using Math.log (which was NOT the
bottleneck according to my profiler)
I have noticed:
* ForkJoinPool will create two threads even if I ask for 1
It looks like it won't use the one thread, but it's still created.
* I got better run times with parallelism=1 than with the default (2)
I suspect this result might be replicated with parallelism set to n-1
(n==# of cores in your system). It seems ForkJoinPool (quite sensibly)
creates a thread just to do work while leaving your main thread alone
and idled. So if you run ForkJoinPool asynchronously--using
..execute()--you may get degraded performance because your main thread
and one of the worker threads are sharing a core.
* Using an inner class to implement RecursiveAction to access the parent
class is a REALLY bad idea!
I noticed my #1 hotspot, after optimizing other things, was access$600
and access$700 on my parent class. I was puzzled for a little bit until
I found out it's related to synchronized access for the parent class.
*thuds heads*.
When I moved the two methods I was accessing into my RecursiveAction,
there was an appreciable speed-up according to NetBean's profiler. I
went from 13 483 ms / 4 321 415 invocations to none.
To give some perspective, my iterationsToColor method, which calls
Math.log, was only about 5.8% of my execution time compares to 31.7% in
access$600. Now, it's up to 52% of the time--which I can optimize out
with a pre-computed lookup table.
So lessons learned:
1. Profile, profile, profile before you optimize.
2. If you use an inner class to implement RecursiveAction, be mindful of
calling or accessing members of its parent class. It will strangle your
performance.
your for loop predicate changing while the loop is running), I plunged
into Java 7. Specifically to explore...
*orchestral chord*
java.util.concurrent
OK, I admit this is melodramatic, but so far, I am noticing some
interesting and curious things.
System:
* Windows 7 64-bit
* Java 7 SDK with NetBeans
* Pentual dual-core E5200 @ 2.50 GHz per core
* 4 GB RAM
My test program: the world's simplest (or dumbest) Mandelbrot set
plotter complete with color mapping using Math.log (which was NOT the
bottleneck according to my profiler)
I have noticed:
* ForkJoinPool will create two threads even if I ask for 1
It looks like it won't use the one thread, but it's still created.
* I got better run times with parallelism=1 than with the default (2)
I suspect this result might be replicated with parallelism set to n-1
(n==# of cores in your system). It seems ForkJoinPool (quite sensibly)
creates a thread just to do work while leaving your main thread alone
and idled. So if you run ForkJoinPool asynchronously--using
..execute()--you may get degraded performance because your main thread
and one of the worker threads are sharing a core.
* Using an inner class to implement RecursiveAction to access the parent
class is a REALLY bad idea!
I noticed my #1 hotspot, after optimizing other things, was access$600
and access$700 on my parent class. I was puzzled for a little bit until
I found out it's related to synchronized access for the parent class.
*thuds heads*.
When I moved the two methods I was accessing into my RecursiveAction,
there was an appreciable speed-up according to NetBean's profiler. I
went from 13 483 ms / 4 321 415 invocations to none.
To give some perspective, my iterationsToColor method, which calls
Math.log, was only about 5.8% of my execution time compares to 31.7% in
access$600. Now, it's up to 52% of the time--which I can optimize out
with a pre-computed lookup table.
So lessons learned:
1. Profile, profile, profile before you optimize.
2. If you use an inner class to implement RecursiveAction, be mindful of
calling or accessing members of its parent class. It will strangle your
performance.