[pooma-dev] AltView* classes

[James Crotinger]

Hi all,

Jeffrey's email shook a few more things loose. :)

Yes, more classes means more parse time, but the issue was link time. The
Blanca folk did explicit instantiation of as much stuff as they could. My
recollection was that without explicit instantiation, there was a link-time
compile for every view in every file that took a view, or something like
that. There was a problem doing implicit instantiation of the views
themselves, though I don't remember what the issue was. The solution was to
move the enum into the AltView class and explicitly instantiate all of
these. With this addition, the linker always found the sv variable and no
additional link-time compile was needed.

This is obviously coming from some pretty rusty neurons, but I believe this
is the crux of the issue. For large codes, POOMA is a pig at link/compile
time (depending on the instantiation model) and there were various possibly
non-obvious factorings made along the way in order to try to keep this under
control.

	Jim

------------------------------------------------------------------------
James A. Crotinger                           email:     jimc at numerix.com
NumeriX, LLC                                 phone:  (505) 424-4477 x104
2960 Rodeo Park Dr. W.
Santa Fe, NM 87505
 

> -----Original Message-----
> From: Richard Guenther [mailto:rguenth at tat.physik.uni-tuebingen.de]
> Sent: Tuesday, March 02, 2004 9:54 AM
> To: Jeffrey D. Oldham
> Cc: James Crotinger; 'pooma-dev at pooma.codesourcery.com'
> Subject: Re: [pooma-dev] AltView* classes
> 
> Jeffrey D. Oldham wrote:
> >
> > James Crotinger wrote:
> >
> >> Hi Richard,
> >>
> >> This tickled a neuron the other day, but I couldn't recall the details.
> >>
> >> The AltView classes were put in to reduce link times and sizes for
> >> large codes. The classes that have enums end up having a link-time
> >> cost, both in space and time. I believe this refactoring was done to
> >> reduce the cardinality of classes having the "sv" enum. My
> >> recollection is that this, and other similar "optimizations", had a
> >> pretty substantial impact on link-time for Blanca. Unless these are
> >> hurting something else, I would tend to leave them in.
> 
> It seems they are only used for return type creation which hinted me
> that it may have beed a compiler bug workaround (so does the CVS
> histroy).  As an optimization this looks worthless at it just adds
> classes to parse. No?
> 
> 
> > The POOMA CVS repository history goes back to at least 1998 March.  For
> > example, see the log for src/Array/Array.h.  This log gives an entry for
> > AltView0 and AltView1Implementation:
> >
> > revision 1.141
> > date: 2001/05/25 17:42:48;  author: oldham;  state: Exp;  lines: +47 -6
> > branches:  1.141.4;
> > 2001-05-25  Jeffrey D. Oldham <oldham at codesourcery.com>
> >     * Array/Array.h (View0): Modify initial comment to indicate
> >     changes should also be made to AltView0.
> >     (AltView0): New class to avoid explicit instantiation problems.
> 
> The same comment is above the classes in the source, but it's not very
> helpful in trying to figure out what these problems are/were.
> 
> It's in my tree now, so I won't forget about it at least until the next
> treediff to CVS.
> 
> Richard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20040302/cef1262d/attachment.html>