- To: David Edelsohn <dje at watson dot ibm dot com>
- Subject: Re: The new scheduler and x86 CPUs
- From: Vladimir Makarov <vmakarov at redhat dot com>
- Date: Wed, 29 Aug 2001 12:42:33 -0400
- References: <200108291520.LAA27960@makai.watson.ibm.com>
David Edelsohn wrote:
>
> Please respond to my question on the GCC mailinglist about whether
> the DFA scheduler shows benefits.
>
> Thanks, David
I am sorry, David. I did not get your email (as the first Jakob's
email. Benjamin Kosnik wrote me about it). Probably because a new
server was recently installed in our office. I'll try to figure out
it. It is important. Now please, use vmakarov@redhat.com (not
vmakarov@touchme.toronto.redhat.com or
vmakarov@tooth.toronto.redhat.com).
David Edelsohn wrote:
> Does the new scheduler produce any significant performance
>improvement in the code GCC generates commensurate with its compile-time
>cost?
>
Additional compilation time of genautomata.o is about 3 sec on my
computer (550Mhz Pentium III). So what improvement should be for 3 sec
additional compilation?
> Both my experience with the new DFA scheduler targeted at PowerPC
>delivered with GNUPro and the GCC for IA-64 Summit minutes report that the
>scheduler compile time was no faster than the Haifa Scheduler and the
>scheduler did it not generate faster code. The software pipelining did
>not seem to be effective either, mainly because of dependency information
>infrastructure still lacking in GCC.
>
I did not write the description for PowerPc. I could look at that to
find is something wrong. I can not promise to do it soon.
I had several percent increase for haifa scheduler on Fujutsu VLIW
processor when I used the first cycle multipass scheduler. The
multipass scheduler works only for DFA based scheduler and the speed of
the pipeline hazard recognizer is very important here (because it tries
many schedules to choose better one). For powerpc, pipeline hazard
recognizer consumes small fraction of all scheduler work time. So there
is no improvement in compilation time.
I don't know about the IA-64 Summit minutes report. But I think it was
based on my work. I've tried to use multipass scheduler to improve IA64
scheduling. There was no improvement (more correctly it was 0.3 - 0.5 %
improvement on SPECint95) and because the scheduler used multipass
scheduling, the compiler was much slower. I sped up the recognizer.
And I am going to speed it more. But even original recognizer is
faster. I had only 1 month for this work (to write description, write
multipass scheduler, tune compiler). I've did many mistakes in the
description therefore the compiler using DFA based scheduler generates
bad IA64 templates (as I know old scheduler based compiler does not
generate templates).
As for software pipelining, I am not going to add RCSP soon. I wrote
in my comments in RCSP at least 7 places where RCSP could be and should
be improved. But even now I have some Fujitsu tests (these are small
tests like sorting) where the current RCSP for a Fujitsu VLIW processors
gave 20-40% improvements (on simulator).
> In theory, the DFA scheduler and software pipelining should be
>much better. Until the new work demonstrates an improvement and is shown
>to be robust, I think it should be on a branch, as GCC's development
>policy specifies.
>
I see now at least one advantage, more convenient description.
Although people can say it is a matter of taste. Should code added to
gcc main branch only fix bugs or improve the code?
Ok, If the steering committee decide to move it into the branch, I'll
move it.
> What evidence shows that the DFA scheduler and software pipeliner
>have evolved beyond a work in progress?
Making it public is important. It is an infrastructure. If I have no
time for this, somebody might want to use it and improve it.
Vlad