RE: [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: address@hidden
NumeriX, LLC                                 phone:  (505) 424-4477 x104
2960 Rodeo Park Dr. W.
Santa Fe, NM 87505

-----Original Message-----
From: Richard Guenther [mailto:address@hidden]
Sent: Wednesday, March 12, 2003 4:06 PM
To: Jeffrey Oldham
Cc: address@hidden
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.