freepooma-devel
[Top][All Lists]
Advanced

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

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


From: Richard Guenther
Subject: RE: [pooma-dev] [PATCH] Re: Two New Array Failures
Date: Thu, 13 Mar 2003 09:52:11 +0100 (CET)

On Thu, 13 Mar 2003, James Crotinger wrote:

> 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.

Be aware that I only added a member to the expression _engine_ - this one
isnt constructed recursively, but only one time per expression (if I'm
right).

Also the only other way to fix some of the problems I'm seeing is to make
all Engine::domain() return copies of their domain and fix up all
potential callers to be aware of this.

But yes, some performance regression tests seem useful, though I dont have
KCC available and SGI CC in maybe too old version, as this doesnt pass the
regression tests we already have. I have some small code of performance
test that checks the same term with expression templates, a stencil and
scalarcode, I'll improve that and look how to easily turn that into some
automatic testing.

Richard.

> 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

--
Richard Guenther <address@hidden>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]