Re: 3.2 vs 3.1 speed

[Vladimir Makarov <vmakarov at redhat dot com>]

Dan Nicolaescu wrote:
> 
> "Vladimir N. Makarov" <vmakarov@redhat.com> writes:
> 
>   > Dan Nicolaescu wrote:
>   >
>   > > I did a little test on the speed of 3.2 and 3.1 using the example
>   > > posted earlier today on a Sparc machine with 1GB RAM.
>   > > 3.2 was last updated on May 25.
>   > >
>   > > 3.2 is _slower_ than 3.1 at compiling the same preprocessed file.
>   > >
>   > > It looks like the main reasons for the speed decrease are: garbage
>   > > collection, expand and scheduling.
>   > > The times are the ones reported by -ftime-report
>   > >
>   > > The source code used is at: http://www.ics.uci.edu/~dann/orb.i.bz2
>   > >
>   > > Hope somebody can figure out what is going on...
>   >
>   > Hi, Dan.  I'll look at the 1st insn scheduling (the 2nd insn
>   > scheduling is actually faster) today.  As David, I suspect the
>   > code is slower because scheduling lookahead.  I think that the
>   > specific features of code is in long ready queues.  I have some
>   > ideas how to improve such behavior.
> 
> David asked me yesterday to try different lookahead values, and I
> did. I tried 3, 2 and 1. The difference in sched1 times was
> insignificant, less than .5 out of 16seconds total for sched1.
> 
> It's great that you will speedup scheduling with lookahead, but I have
> doubts that it will help in this case.

   Yes, you are right.  This is not because of the lookahead code.  Its
time fraction is tiny (according gprof).  What I found is more time
spent in alloc_INSN_LIST and free_INSN_LIST_list (it means more insn
dependencies).  I don't know C++ front-end but it looks the code became
bigger (10%) may be because of inliner.  Therefore compiler works slower
now.

Vlad