[Insight-developers] Threading, RandomImageSource and MultiThreader

[Lorensen, William E (CRD)]

Folks,
As I mentioned at last Friday's tcon, threading was not using multiple processors on Solaris systems
(thanks to Simon Warfield, BWH, for pointing this out 10 months ago on the vtk users list!).

The threads, by default, run consecutively, not concurrently. I added a call to
pthread_setconcurrency(# of threads). This call is just a suggestion to the OS. However, my tests did
seem to run on multiple CPUs.

But, I noticed the test, which had a RandomImageSource, was using 4 times as much system time as user
time. After further investigation, we build the problem down to the drand48() call that vnl_sample
was using to generate random numbers. The man page says that drand48() is thread safe. We speculate
that it must be mutexing (or some other form of locking) the seed. The seed retains state for the
next random number generation.

Sure enough, when I replaced the drand48() call with an inlined random number benerator, the user and
system times dropped drastically.

Here are some times:

10 processor Sun, drand48: 108.65u 140.45s 1:21.66 305.0%
no threading... 23.16u 0.55s 0:24.65 96.1%
in line random number... 40.99u 0.62s 0:06.09 683.2%

Notice that the non threaded was faster than the threaded with drand48()!

I've checked in the new RandomImageSource. However, it's randomness may not be up to par.

Bill