RE: i386 backend

["David Rasmussen" <pinkfloydhomer at yahoo dot com>]

> David Rasmussen wrote:
> >
> > >
> >
> > 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.
>

Why do you assume that I can do that? If I could mix object files from
different compilers, then I might be able to do it. But the 10 most critical
functions are interrelated in complex ways, so I can't just isolate one.

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

It can't. Not in a manner that reflects directly how it is used in the
program, however. I might be able to make something that tests this function
a million times on a set of test input. But I still can't be sure, that this
is where gcc has problems. There are other critical functions as well, and
they don't make sense out of context. It would be very difficult to isolate
these functions.

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

No, but I have to have some idea of what kind of code to isolate.

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

I would be willing to do that. In fact, I will try in the next couple of
days, to isolate some critical code, if it is possible. I'm just not sure
that it is, in any natural way.

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

In _my_ experience (which might of course not be representative for
experiences in general), MSVC++ generated code performs in the range -5% -
60% faster than gcc generated code, with a distribution which is roughly
normal. That is to say, gcc is sometimes faster, but not often and not by
much, whereis the opposite is more often the case. In _my_ experience.

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

True.