[Beowulf] Threaded code

[Robert G. Brown]

On Tue, 17 Aug 2004, Art Edwards wrote:

> Thanks for the input. We have determined that our atlas build is,
> indeed, threaded, and that it is reasonably well tuned for this system.
> For an 800x800 system we see the following for dgemm
> 
> /usr/lib64/libblas.a       430.540 MF
> ATLAS no threads	   3053.107 MF
> ATLAS with pthreads	   5115.086 MF
> 
> 1.67 is our speed up for 800x800. Now we have to learn about building
> a threaded fortran application. Are there any compiler swithes we need
> for g77 to build threaded code?

Sorry, I don't do fortran.  At least not unless somebody holds my dog
hostage or threatens to torch my car.

However, in C using threads is simply a matter of linking in the correct
thread library:

  LIBS = -lpthread -lmenu -lpanel -lcurses -lxml2 -lm

(from a threaded app I wrote).  Ditto in perl (which currently supports
threads, amazingly enough, in scripted code).  I'd guess that it is much
the same for fortran, with the usual caveat about c-style subroutine
calls and argument lists vs fortran-style calls and argument lists.

   rgb

> 
> Art Edwards
> 
> 
> On Tue, Aug 17, 2004 at 01:52:24PM -0400, Robert G. Brown wrote:
> > On Tue, 17 Aug 2004, Art Edwards wrote:
> > 
> > > I mean that when we run the threaded code and look at top, don't see two
> > > processors running. The load is always less than or equal to one. When
> > > we run two separate jobs, we see a load of 2. 
> > 
> > If you see a load of 2 and they complete in the time of 1, nothing is
> > wrong with SMP or the two processors, but your code, threaded or not,
> > isn't running in parallel.  As Mark suggested earlier, that makes me
> > suspect that your copy of ATLAS is either not threaded or not built for
> > your (SMP) system or both.
> > 
> > I'd suggest doing a proper build of ATLAS >>just<< for that system,
> > exploring the build options enough to be sure that the options you are
> > shooting for are turned on.  I also wouldn't be terribly surprised if
> > ATLAS doesn't speed up a whole lot when multithreaded.  It depends a bit
> > on where it is bottlenecked -- if it is bottlenecked at a shared
> > resource point, it could even slow down.  You're right back to the
> > fundamental problem of parallel program design -- it is very difficult
> > to automate because there are so many ways things can interact and
> > because work cannot always be done faster in parallel.
> > 
> >    rgb
> > 
> > > 
> > > Art Edwards
> > > 
> > > On Tue, Aug 17, 2004 at 07:45:32AM -0700, Alvin Oga wrote:
> > > > 
> > > > hi ya
> > > > 
> > > > yup.. that is dual cpu
> > > > 
> > > > On Tue, 17 Aug 2004, Art Edwards wrote:
> > > > 
> > > > > We are running SuSE 9.1 on a system with 8 GB of ram and two scsi disks.
> > > > > Here is /proc/cpuinfo
> > > > > processor       : 0
> > > > 
> > > > good
> > > > 
> > > > > processor       : 1
> > > > 
> > > > good
> > > > 
> > > > > Linux bladerunner 2.6.4-52-smp #1 SMP Wed Apr 7 01:58:54 UTC 2004 x86_64
> > > > > x86_64 x86_64 GNU/Linux
> > > > 
> > > > good
> > > > 
> > > > 
> > > > > > Newbie question:
> > > > > > 
> > > > > > We just purchased a dual opteron box that is running an SMP kernel. We
> > > > > > have built a fortran code using g77 and a pthreaded atlas. Currently, we
> > > > > > see only one processor. What really simple thing have we missed?
> > > > 
> > > > so what do you mean by "see only one processor" ??
> > > > 
> > > > c ya
> > > > alvin
> > > 
> > > 
> > 
> > -- 
> > Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
> > Duke University Dept. of Physics, Box 90305
> > Durham, N.C. 27708-0305
> > Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu
> > 
> > 
> 
> 

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu