[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Speeding up ATLAS build time


Here is an updated patch file.  I think this
should work (it seems to work right for me
at any rate).

I chose 2*n because on many serial machines
with many compilers, "-j 2" is more efficient
than "-j 1".  The reader's digest version is
that the system can often overlap I/O with
CPU processing with two jobs.

The dependency information should not be lost,
so everything should work exactly as before,
only faster.

I have added a test for "gmake -j 2" for those
machine with gmake but a broken make.

Please give these patches a spin and let me
know what you think.  Do you have both uni-
processor and SMP machines to play with?



> -----Original Message-----
> From: R Clint Whaley [mailto:rwhaley@cs.utk.edu]
> Sent: Thursday, March 08, 2001 6:51 PM
> To: staelin@exch.hpl.hp.com
> Cc: atlas-comm@cs.utk.edu
> Subject: RE: Speeding up ATLAS build time
> Carl,
> Just a few boneheaded questions . . .
> First, it looks like -j does not work with SunOS or AIX or 
> IRIX make.  Can
> anyone with some knowledge of these guys comment (I don't 
> have access to
> their man pages at present)?  Since gnu make is often used on 
> these systems,
> it's not a killer, but surely they have an equivalent?
> >"make -j N" it is set to "make -j n" where "n"
> >is 2 * ncpu.
> Why is it 2*ncpu rather than ncpu?  Is -j 2 more efficient 
> than no -j on
> a serial machine?
> >Then I went through all the makefiles in "makes"
> >and edited them to use $(PMAKE) to build object
> >files, usually by moving the object files from
> >the dependency line to a $(PMAKE) line in the
> >target build section.
> But the dependency information is not lost, right?  For 
> instance, it is
> still true that already-built libs will not be rearchived, 
> and that missing
> files will be compiled, yes?
> Sorry to send questions rather than just scoping the stuff, 
> but I'm afraid
> time constrainsts mean that I will probably want to scope it 
> out once you
> have the whole thing working and debugged, just to avoid 
> spending the time
> several times, even though I realize the process would be 
> helped by doing
> it iteratively . . .
> Thanks,
> Clint