[NTLUG:Discuss] pthreads on Linux
Peter A. Koren
pkoren at hex.net
Sun Aug 12 00:05:24 CDT 2001
Here I am replying to my own post. That way I am really replying
to those of you who responded to my threading post.
I rewrote the algorithm to make the number of parallel threads an
input parameter. Running five threads or less causes some
performance loss, probably because there are times when all are
blocked on a mutex or semaphore. Above 50 threads there is some gain
in performance. Of course, only two threads can actually run in
parallel on this dual processor system.
But still the non threaded version is considerably faster. I have to
agree that bus contention is the culprit. A serious SMP system built
for number crunching requires a high bandwidth bus. Given the costs
involved, it might not be worth it. The Beowulf approach may just be
the right one.
Each thread in the differential evolution algorithm needs access to the
bulk of the data. It is inherent to the algorithm, so locality of data
can not be exploited and the data needed certainly can not fit into the
register set.
On the bright side, a dual CPU system is great for running one number
crunching task, because the machine remains responsive on more mundane
tasks. When I run my threaded code, the GUI stuff goes catatonic, as
both CPUs approach 100% utilization.
Well, it was fun trying out threads. BTW, here is the URL for the main
differential evolution site:
http://www.ICSI.Berkeley.edu/~storn/code.html
It really is a very clever algorithm, borrowing the "memory" of Genetic
Algorithms by using a population, and stealing and improving upon the
annealing schedule of simulated annealing. If you study the technique,
you can see that the annealing schedule is adaptive without actually
having to code it as an added feature. It just occurs naturally as the
optimization parameters converge.
I made a small bug fix (C version) and came up with another strategy set
which performs better on most problems. I'll have to contact the
original
authors about it.
-- Pete
"Peter A. Koren" wrote:
>
> Steve Baker wrote:
> >
> > Chris Cox wrote:
> > >
...SNIP
> Peter Koren
More information about the Discuss
mailing list