Re: [pooma-dev] Compile Time Problems and Pooma 2

[Dave Nystrom]

Scott Haney writes:
 > 
 > On Tuesday, May 29, 2001, at 05:24 PM, Dave Nystrom wrote:
 > 
 > > Scott Haney writes:
 > >> As a general principle, we can agree that circular dependencies are 
 > >> bad.
 > >> Field is using auxiliary templates that need information from Field.
 > >> This problem can be worked around nicely in non-templated C++ code, but
 > >> it is difficult to work through with templates. However, maybe, by
 > >> re-factoring, this can be fixed. In particular, AltView1 doesn't use
 > >> that much of Field. I will give this a shot.
 > >
 > > Well, good luck.  Sounds like I've opened up a real can of worms.  Do 
 > > you
 > > have any comments on the rest of my original email from Sunday or my 
 > > response
 > > to Stephen.  I'm particularly interested in whether you think there is 
 > > much
 > > to be gained in terms of reducing the amount of code generated and 
 > > improving
 > > compile times by revisiting the logical design.
 > >
 > > --
 > > Dave Nystrom                       email: address@hidden
 > > LANL X-3                   phone: 505-667-7913     fax: 505-665-3046
 > 
 > I have no doubt that we can improve compile times. However, I'm not sure 
 > what to make of your numbers. They imply that something strange is 
 > happening on the SGI, but that's not really our target platform, so I 
 > don't believe that we should spend much time looking into this right 

I agree that the numbers I reported imply something strange going on with our 
SGI machine/compilers.  I thought it was strange enough that it should be
reported to pooma-dev in case you guys had some insight into the problem that 
I was missing.  I'm not really looking for a platform specific solution from
you guys.  Actually, my data indicates a temporary work around for the SGI is 
to just break up my files into much smaller files since the SGI C compiler
seems to scale more like quadratic with the size of the .int.c files.  Of
course I already have what I thought might be reasonable granularity there.
The instantiation requests for the Pooma 2 assign functions are currently
spread over 20 files.  I probably need to talk to someone from SGI about this 
data and see if they know what is going on as well.

I think that the SGI platform will be an important platform for our October 1 
deadline.  To my knowledge, Lee Ankeny has not been successful yet getting
any of our Pooma 1 based code compiling on the Compaq machines.  Perhaps that 
will change with the recent release of KCC-4.0e for Tru64 Unix 5.0.  BTW, do
you guys have accounts on the chi machine - an open Compaq machine?  I was
under the impression that you were supposed to have accounts there now.  I'm
worried about what compile times are going to be like on the Compaq as well.
I don't know enough about the machine yet but I wonder if our parallel builds 
will be limited to 4 processors.

 > now. Our priorities are, as I understand it, to (1) provide core 
 > capabilities in order to allow you guys to meet your October deadline 
 > and (2) to optimize performance and scalability. I'd put compile time 
 > performance in (2), but the contract clearly implies we should focus on 
 > run time first. That said, it is worth a little more time to investigate 

I don't disagree with these priorities at all.  And I don't have any
authority to change them either.  You guys just need to be aware that compile 
times are starting to affect the productivity of our work - including John,
Jean and Don.  A few months back I saw John compile all of our source code
base in 9 minutes.  I recently heard that it now takes 1.5 hours for them to
compile all our source code base - and that is using MetroWerks.  If there is 
any low hanging fruit to be picked from the compile time tree that will make
a difference then we could really use it.  If I can explicitly instantiate
all of the templates that the compiler is currently instantiating, I can
probably reduce our whole system compile times by a factor of at least 2 and
for developers who don't have to compile the Pooma2Instantiations library it
will probably be a much larger factor.  But, I don't think you can afford to
spend huge amounts of time on this right now.  I think we would agree on
that.

 > this View preinstantiation issue because it can elucidate some design 
 > principles that can be used to reduce the number of template 
 > instantiations as we go forward. In the long term, I believe that we may 
 > need to provide a tool of some sort to support pre-instantiation, but 
 > that is not a job for now.

Well again, good luck.  When I reported this problem 2-3 weeks ago, I thought 
it would be a simple fix.  I did not realize that it would be as involved as
it has turned out to be.  I hope you can come up with a simple and elegant
fix without spending much of your time on it.

BTW, I seem to be spending an awful lot of time responding to emails which
may or may not be productive.  But I'm still happy to provide anymore data or 
discuss this with anyone that wants to.  I just don't want to beat a dead
horse or spam everyone's InBox.

-- 
Dave Nystrom                    email: address@hidden
LANL X-3                        phone: 505-667-7913     fax: 505-665-3046