Adventures in java.util.concurrent

Discussion in 'Java' started by Travers Naran, Aug 29, 2011.

  1. 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.
    Travers Naran, Aug 29, 2011
    #1
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Timo Nentwig

    java.util.concurrent: Blocking

    Timo Nentwig, Jun 24, 2004, in forum: Java
    Replies:
    4
    Views:
    578
    Timo Nentwig
    Jun 25, 2004
  2. chotchkie
    Replies:
    2
    Views:
    837
    chotchkie
    Aug 4, 2005
  3. Pep
    Replies:
    6
    Views:
    811
  4. Let me Think

    java.util.concurrent

    Let me Think, Oct 29, 2005, in forum: Java
    Replies:
    4
    Views:
    2,870
  5. Ake L
    Replies:
    7
    Views:
    4,258
    Ake L
    Dec 11, 2005
Loading...

Share This Page