[pooma-dev] [PATCH] Re: Two New Array Failures

[James Crotinger]

I wouldn't apply this without careful performance testing on a large-ish
problem using KCC (or some other compiler that really inlines everything
that it is told to inline and optimizes the hell out of the results). This
seems like a reasonable thing to do, but I worry about adding additional
code to the construction of expressions since they are constructed
recursively and it is expected that a lot of stuff that goes on in their
usage will be inlined away. Back in the day we ran into a number of cases
where it was easy to push the optimizer over the edge and lose a lot of
performance with KCC and SGI CC (the only two compilers that, as far as I
know, have approached hand-coded loop speed for Pooma Array code, which is
THE goal.) This is most important in ExpressionEngines built out of
Brick-engines - i.e. the iterates that ultimately are created and evaluated
in evaluating a multipatch expression. If the loops over these expression
engines don't completely inline, and basically end up looking like what
you'd write by hand, you're hosed, from a performance perspective. Unless
things have changed dramatically, gcc 3 is not at the level of performance
to make this assessment. (Jeffrey, do you agree?)

	Jim

------------------------------------------------------------------------
James A. Crotinger                           email: jimc at proximation.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: Wednesday, March 12, 2003 4:06 PM
To: Jeffrey Oldham
Cc: pooma-dev at pooma.codesourcery.com
Subject: Re: [pooma-dev] [PATCH] Re: Two New Array Failures

On Wed, 12 Mar 2003, Richard Guenther wrote:

> Hi!
>
> The attached patch canonicalizes Engine::domain() const to return a
> const reference to its domain. It can do so by adding a domain_m
> member to the expression engine (pls review this part carefully, as
> in some of the constructors we might do things more optimally if I
> had understood what they actually do...).
>
> (We might do something similar to the Engine::layout() const methods,
> though this would affect many more engines to be added a layout_m member)
>
> Testing is still in progress, but the concept sounds reasonable?

Build and testing completed with no regressions in Engine, Array and Field
on ppc-linux with gcc 3.2.3

Ok to apply?

Thanks, Richard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20030313/02627c58/attachment.html>