The short version of the story - By setting gc=false and adding the
following parameter to the VM command line" -XX:+AggressiveHeap, ECJ used
28% less computational time. Same seed.
The performance increase is a result of instructing the JVM to use a
more efficient garbage collection algorithm.
Note, using this switch uses memory more aggressively, so you may want
to read on.
The long version of the story.
I have been using ECJ for the last year and in the past few months
became interested in increasing performance. To that end, I added timers
to each of the major operations of ECJ. Here's what a typical report my
look like:
> Java Default GC Parameters
>
> Run Time:93.94 -> 100.00%
> Setup:3.98 -> 4.23%
> Evaluate:17.94 -> 19.09%
> PostEval Stats:4.32 -> 4.60%
> Breed:67.02 -> 71.34%
> Final Stats:0.90 -> 0.96%
First number is seconds and second number is percent of CPU time.
I was surprised to see that breeding consumed such a large proportion of
the CPU consumption - 71%. Timers were added to specific functions inside
of breeding:
> Run Time:93.94 -> 100.00%
> Setup:3.98 -> 4.23%
> Evaluate:17.94 -> 19.09%
> PostEval Stats:4.32 -> 4.60%
> Breed:67.02 -> 71.34%
> --PrepareToProduce:7.47 -> 7.95%
> --Produce:59.38 -> 63.21%
> ----Produce_BreedingSources:0.78 -> 0.83%
> ----Produce_Produce:57.95 -> 61.68%
> ------CrossOverPipeline_Breed6:33.62 -> 35.79%
> -------CrossOverPipeline_Breed7_childAllocate:8.02 -> 8.54%
> Final Stats:0.90 -> 0.96%
One line of code “obj.children = new GPNode[children.length]” was found to
consume 8.54% of the CPU time. This line of code allocates memory from the
heap for tree children - a very common operation in breeding.
A first tack against this consumer was to think that dynamic object
allocation was eating processor time. This could be cured by statically
defining a collection of nodes that the GP could recycle through without
JVM memory allocation/de-allocation. This was briefly explored until
realizing that creating/maintaining such a collection would require
extensive code changes.
A second and ultimately successful tack was to consider the de-allocation
side. Was the JVM’s garbage collection consuming the processor time?
Garbage collection is performed by the JVM without needing to be
programmed directly – one of the beauties of Java – no memory leaks. In
most programs, this does not introduce performance degradation. However,
most programs don’t allocate millions of objects per second as ECJ.
While Sun Java does offer some access to performing explicit garbage
collection in code, doing this in ECJ only introduced additional
performance degradation. The other way to control GC is through JVM
command line parameters. After a bit of internet research, the following
command GC/Heap parameters were discovered and tested.
> 75000 individuls x 5gen
> Command Line Switch Total Run Time
> --none-- 11.5s
> -XX:+UseParallelGC 13.7s
> -XX:+UseConcMarkSweepGC 16.5s
> -Xincgc 16.7s
> -XX:+UseAdaptiveSizePolicy 11.6s
> -XX:+AggressiveHeap 7.2s
After determining the best command line switch, I tested combinations of
ECJ's garabge collection and the switch.
> 75000 inds x 50gen – testing switch with ECJ code GC
> Command Line Switch ECJ GC Total Run Time
> --none-- none 93.9s
> -XX:+AggressiveHeap none 62.0s
> --none-- normal 100.1s
> -XX:+AggressiveHeap normal 78.8s
> -none aggreesive 111.2s
> -XX:+AggressiveHeap aggressive 91.0s
As can be observed from the above results, using -XX:+AggressiveHeap and
turning off ECJ GC resulted in the much fastred run times by far.
A note on memory usage. -XX:+AggressiveHeap is just that - aggressive. If
you get an "Out of Heap Memory" error when using this switch, then you
will need to setthe VM parameter Xmx???m. This parameter sets the maximum
heap size and units are megabytes. The smallest value I ever use is:
Xmx75m. I'm running symbolic regression with average trees sizes of 18. My
rule of thumb is to allocate 2M of memory for every 1,000 individuals. For
example, a run of 200,000 individuals, I will set the parameter to
Xmx400m. Your needs may be more or less depending on your tree/population
sizes. There's a balance here. It needs to be set high enough so there's
enough heap space. It needs to be set low enough as to not aggressively
consume so much memory that you start doing disk page swaps, especially if
you're running multiple simultaneous runs. Again, this might not be an
issue for smaller populations, non-paralell runs or if you have vast
amounts of memory.
For more information on the -XX:+AggressiveHeap switch and other heap
related switches:
http://java.sun.com/j2se/1.4.2/reference/whitepapers/
I'd love to hear back from any of you who experiment with this.
Also, if there's popular demand, I can include the Performance
Monitoring Class that I've created.
best initentions, Chris Ellingwood
(University of Vermont, Botany)
-----------
Configuration I:
Sun Java: 1.5.0_05
Dual Processor Xeon 3.6 GHZ
Windows XP - 64 bit
ECJ 11
Configuration II:
Sun Java: 1.5.0_05
Pentium 4 - 2.4 GHZ
Windows XP
ECJ 11
|
