Re: i386 backend

[James Dennett <jdennett at acm dot org>]

David Rasmussen wrote:
> 
> >
> > But that *is* the point.  You can be *much* more precise in reporting
> > *where* the problem is.  If you have been serious about benchmarking
> > your code in any way, then it should be clear to you what parts of
> > your code are having slowdown problems.  That is what is being asked of
> > you, and frankly, it is not too much to ask since this is exactly the
> > kind of analysis you should be doing anyway if you are at all worried
> > about performance.
> >
> 
> I am not sure I understand what you mean. I have a pretty deep insight in
> where my programs "hotspots" are. I have compiled it with many different
> compilers, profiled it with different profilers etc. But how can I tell
> where the problem with gcc is from that, when I know nothing about the
> internals of a compiler?

Isolate one piece of standalone code which runs more slowly if compiled
with gcc than if compiled with another of your compilers.  You need no
knowledge of gcc's internals to do that.

> The biggest "hotspot" in my program is an evaluation function which uses
> appx. 30% of the time, according to profilers. This evaluation function is
> mainly integer arithmetics and array lookups, in a very complex way. We're
> talking appx. 2000 lines of code for one function that eventually just
> returns an int.

If that code can be isolated, it might make a splendid test case.

> 
> > The compiler developers know of many places in which the compiler can
> > be improved and the vagaries of the 1386 architecture make it a
> > particularly nasty test case for a general purpose compiler targeted
> > at a wide variety of machine architectures.  Whether or not the
> > problems you are experiencing are known or unknown, simple or complex
> > is something that can only be answered if and when you do at least
> > some of the work to identify specifics.
> >
> 
> I still don't know _how_ I should identify the specifics, as I am not a
> compiler writer, and have no idea what code is being produced in my specific
> case. 

You don't have to be a compiler writer to isolate a piece of code
which executes much more slowly when compiled with gcc than when
compiled with compiler XYZ.

Would you be willing/able to do that?  It seems likely that if you
take it that far, one of gcc's many volunteers will diagnose the
problem, and maybe it will get fixed sooner.

> But since gcc is almost always slower, no matter what it compiles,

That would be surprising, particularly if you are suggesting that
gcc is usually *significantly* slower.

> I
> assumed that it was not just one problem, but a generally ineffecient
> backend.

Of course, it could be neither.  It is likely more than one problem,
but that's not as bad as the whole backend being inefficient.

-- James Dennett