Skip to main content

[JAI-IMAGEIO] JAI and multiple threads

1 reply [Last post]
Anonymous

Hello.

I'm using JAI in a multi-threading context and I've got some
questions. I've a batch-processing class which performs the same
operation on a set of images. For clarity, let's say I've got 100
images that are processed sequentially in 130 seconds. Now I've
changed my code so two images are processed at the same time (I'm
running the code on a MacBook Pro with a dual-core, this is a way to
exploit the second processor). I see that the parallelized code
completes in 75 seconds. Now, the algorithm is perfectly
parallelizable, as it mostly works on different images; there are
just a pair of common images which are used read-only by both
threads. In other words, I've got images A, B and X(i), 0 < i < 100.
Thread #1 accesses A, B and X(m); Thread #2 accesses A, B and X(n),
with m != n.

On these premises, I'd expect something closer to 130/2 = 65 seconds,
as there should be just a few seconds overhead above the optimal
time. What I'm missing? Can those 10 more seconds be due to the
access to common images (maybe there's some synchronized block in JAI
raster data
access?). In this case, would I benefit from duplicating the common
images so each thread works on a completely separate set of objects?

For the record, I'm running in Java pure mode, as on Mac OS X 10.4
there's not native library support (yet).

Thanks in advance.

--
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
http://www.tidalwave.it/blog - Fabrizio.Giudici@tidalwave.it
mobile: +39 348.150.6941 - fax: +39 027.005.105.36

[att1.html]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Brian Burkhalter

My feeble memory tells me that I did some tests on multi-threaded performance
in JAI some time back. My recollection may be faulty and this might apply to
only the platform I was using and only under a particular set of constraints
so I cannot guarantee what correct inferences may be drawn from it now.

The best I can remember the testing ran an operation chain consisting of a
number of operations applied to tiled images. The platform in question was
Solaris-SPARC. Using machines with up to at least 8 CPUs (probably more like
16 or 32), the TileScheduler parallelism was set to the number of CPUs. In
these tests it was found that for the generic parallel processing equation
TN = (C + (1-C)/N)*T1 where 'C' is the fractional non-parallelizable
overhead, the value of C was approximately 0.1 so that we have

time_for_N_CPUs = (0.1 + 0.9/number_of_CPUs)*time_for_1_CPU

Therefore for 2 CPUs the time should be approximately 0.55*T1 so if T1 is 130
as in your case you would get 71.5 which is closer to the 75 you saw instead
of the 65 you wanted.

In other words the JAI op chain appears to be achieving around 90% of the
theoretical limit at least according to the testing I did so many moons ago.
At the time that did not seem too bad. ;-)

Brian

On Thu, 7 Sep 2006, Fabrizio Giudici wrote:

> I'm using JAI in a multi-threading context and I've got some questions. I've
> a batch-processing class which performs the same operation on a set of
> images. For clarity, let's say I've got 100 images that are processed
> sequentially in 130 seconds. Now I've changed my code so two images are
> processed at the same time (I'm running the code on a MacBook Pro with a
> dual-core, this is a way to exploit the second processor). I see that the
> parallelized code completes in 75 seconds. Now, the algorithm is perfectly
> parallelizable, as it mostly works on different images; there are just a pair
> of common images which are used read-only by both threads. In other words,
> I've got images A, B and X(i), 0 < i < 100. Thread #1 accesses A, B and X(m);
> Thread #2 accesses A, B and X(n), with m != n.
>
> On these premises, I'd expect something closer to 130/2 = 65 seconds, as
> there should be just a few seconds overhead above the optimal time. What I'm
> missing? Can those 10 more seconds be due to the access to common images
> (maybe there's some synchronized block in JAI raster data
> access?). In this case, would I benefit from duplicating the common images so
> each thread works on a completely separate set of objects?
>
> For the record, I'm running in Java pure mode, as on Mac OS X 10.4 there's
> not native library support (yet).

----------------
Brian Burkhalter
Java Media, Imaging, and Graphics
Sun Microsystems, Inc.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net