[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pthreads-devel
Subject:    [pthreads-devel] 2 Problems (cont.)
From:       Marco Lohse <mlohse () cs ! uni-sb ! de>
Date:       2001-11-06 8:21:27
[Download RAW message or body]

ognen@gene.pbi.nrc.ca wrote:
> 
> Hello,
> 
> interesting that you mentioned this.
> 
> i wrote a bioinformatics application that is an smp version of a widely
> used bioinformatics tool. This application usually launches num_CPUs+1
> threads which each have their own queue of requests they handle until all
> queues are exhausted. The threads completion is synchronized by a
> simulated barrier in the code. I patched 2.4.6 and installed ngpt
> (finally! ;) and ran the timings both ways (on a clean 2.4.6smp and on a
> patched one with ngpt). The tests with ngpt took 3-4 more times to
> complete - the crazy thing was that the threaded code (the one synched
> with a barrier) executed 3-4 times instead of only once! I could actually
> see all the sequences getting alligned 4 times in a row instead of just
> once.
> 

As I have put some printfs in the loops of my test program, another
thing I just noticed is that the execution is really 'jittering' with
IBM pthreads: I get like 20 printfs at once, then a short break, then
another 20 printfs and so on. With standard Linux pthreads the printfs
are executed regularly.
Another interesting thing: If I remove the guarding mutex of the inner
for-loop - of course - performance increases in both cases, but now it
seems to be the same and no 'jittering' in any case! So is there a
general problem with mutexes in IBM pthreads ?

Marco.

> I dont know what to make of this. I have tested my software on Linux
> 2.2.17, 2.4.5, 2.4.13, SunOS 5.6, SGI IRIX64 6.5, Tru64, OSF/1 and the
> application behaved as expected. The boxes were all between 1, 2, 4, 6,
> 12 and even 108 CPUs.
> 
> I expect that I will have some time soon to actually see what is going on.
> I realise it is not very useful but the application will not be released
> for the next 2-3 weeks with the source code.
> 
> Ognen
> 
> On Mon, 5 Nov 2001, Marco Lohse wrote:
> 
> > Ok, I just thought I should use this option because I do not have the
> > kernel patch installed, but then I somehow misunderstood the
> > instructions in the INSTALL ( as I can see from an other mail I am not
> > the only one to do so ... )
> >   --disable-kernel-patch: disable use of 2.4 kernel patch(default=no)
> >       This disables NGPT from making use of the 2.4 kernel patches that
> >       are part of the distribution.  If you have not installed the
> > kernel
> >       patch, rebuilt and are running the patched kernel, you should
> > select
> >       this option.
> >
> > My next question: I used ./configure without any options, and - as I
> > said - I do not have the kernel patch applied. Now I tested a simple
> > application with 2 threads, each with some for-loops which increment the
> > same integer guarded by a mutex. I get something like:
> >
> > > time ./simple
> > NGPT WARNING: required kernel patch not applied.
> >               Only userlevel threading enabled.
> > ...
> > 2.420u 1.130s 0:03.56 99.7%     0+0k 0+0io 148pf+0w
> >
> > Using the standard Linux pthreads I get:
> > 0.230u 0.420s 0:00.77 84.4%     0+0k 0+0io 145pf+0w
> >
> > Can I improve the performance with the kernel patch? Are there any other
> > options for configure I should try? I can send you the test program if
> > you want.
> >
> > Thanks,
> > Marco.

[prev in list] [next in list] [prev in thread] [next in thread]