| Re: Multithreading [message #29721] |
Wed, 20 March 2002 03:32  |
the_cacc
Messages: 104
Registered: October 2001
|
Senior Member |
|
|
"Karl Schultz" <kschultz@devnull.researchsystems.com> wrote in message news:<a77j60$ijh$1@news.rsinc.com>...
> "trouble" <the_cacc@hotmail.com> wrote in message
> news:5f9f0a23.0203190301.3c78e195@posting.google.com...
>> Maybe there really is someone out there getting n-fold speed ups,
>> however they sure don't want to brag about it...
>>
>> Ciao.
>
> There's quite a bit of information on multithreading on the RSI web site, in
> the IDL product section. There's an FAQ list and a white paper. The
> "What's new for 5.5" document contains a list of the routines that are
> threaded.
>
Yeah, read it. Just suprised no-one "real" is raving about their performance gains.
|
|
|
|
|
|
|
|
|
|
| Re: Multithreading [message #29763 is a reply to message #29740] |
Fri, 15 March 2002 17:09  |
Rick Towler
Messages: 821
Registered: August 1998
|
Senior Member |
|
|
"trouble" <the_cacc@hotmail.com> wrote in message
news:5f9f0a23.0203140619.479c464c@posting.google.com...
> Yo,
word up.
> Just curious, have many people got good performance gains from
> multithreading in 5.5? I'm on a single processor (drat!).
>
> Anyone like to share their findings - how much improvement, how many
> processors, what kind of programs? What platforms?
Not much exciting news to report in my case.
Dual Athlon MP 1200 on Tyan Thunder k7
512 MB PC2100 DDR
10k RPM Ultra 160 IBM HDDs
Geforce3 video card
Win2k Pro SP-2
I mostly develop OG applications so I wasn't expecting much. What was a
surprise is that by default on win32, IDL will not even split a computation
into multiple threads if the number of elements is fewer than 1000000.
There must be a lot of overhead! I did play with this minimum a little but
didn't see any benefit with the few applications I tested.
The applications I selected are surely not appropriate metrics to test IDL's
multithreading capabilities but I was curious to see if I would benefit in
my day to day use.
My first test was time_test_gr2.pro, 3 runs, 1st run discarded:
5.5 completed with a mean total of 45.9 secs per run
5.4 completed with a mean total of 46.2 secs per run
My second test was my own "fishbench" which consists of a 3d model of a fish
(in this case lovely walleye pollock #44) and a 3d polygon representing that
fish's acoustic reflectivity. There are about 40k triangles total, the
models are textured and there are multiple views with text and graphics
overlay. This shouldn't test multithreading at all since my "benchmark"
doesn't test setup time but only changes the model transform matrix and
redraws. This has always been "graphics bound" so don't expect much.
average of 3 runs:
5.5 - 25.4 frames/second
5.4 - 25.9 frames/second
The last test was the one I thought would show at least some improvement. I
modeled the acoustic backscatter of 4 fish using our kirchoff-ray mode
model. This model is like any other: get some data, do some stuff with it,
create some output, write it to file. The model makes good use of many of
the mathematical and array creation routines that are multithreaded in 5.5.
Alas, I don't think that any of the arrays exceeded the minimum number of
elements required for IDL to dip into the thread pool. I started to
experiment with the new cpu procedure but didn't see any benefits. I will
probably revisit this one.
time to model acoustics of 4 fish:
5.5 - 00:02:01
5.4 - 00:02:02
one second is probably well within the margin of error for this highly
refined benchmark.
So there you have it. I'm sure there are many who will benefit from
multithreading in 5.5 but I am not one of them.
-Rick
|
|
|
|
|
|
| Re: Multithreading [message #29851 is a reply to message #29721] |
Thu, 21 March 2002 02:42 |
weitkamp
Messages: 33
Registered: October 1998
|
Member |
|
|
the_cacc@hotmail.com (trouble) wrote in message news:<5f9f0a23.0203200332.3d1e3fbf@posting.google.com>...
>
> [...]
>
> Yeah, read it. Just suprised no-one "real" is raving about their performance gains.
Not much to rave about in my case. I mostly do two kinds of
numbercrunching. One is Fresnel wave propagation, where the essential
operations are FFTs of arrays of size between 1024^2 and 4096^2
pixels. The other is tomographic reconstruction using the RADON
function (new in 5.4). I've not had the time to do any systematic
investigation on 5.5's multithreading behavior, but here is my
experience so far:
For the 2D FFTs, IDL does multithreading, but without a substantial
gain in time. Could even be that it takes longer with 5.5 (I tried the
same thing with 5.4 and 5.5, the latter being roughly 15 percent
faster, but on a CPU with higher clockspeed). Sorry I can't give
figures on that and haven't yet tried both 5.4 and 5.5 with the same
task on the same machine (had no time) --- I'd be among those who will
appreciate if someone else does.
For the backprojection, RADON does not multithread at all (I try this
with 2048x2048 slices and 1250 projections for each slice). Given that
backprojection is an application where the layman suspects that
multithreading should be relatively easy to implement, I was certainly
disappointed by that. Seems to be a very commercial decision in that
there's definitely more people use FFT than backprojection, and those
who don't use any of the two have at least heard about Fourier
transforms.
Cheers,
Timm
Timm Weitkamp
European Synchrotron Radiation Facility (ESRF), Grenoble, France
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
