Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1036158: gcc-13: Please raise baseline for alpha to EV56
1 view
Skip to first unread message
John Paul Adrian Glaubitz
May 16, 2023, 3:50:04 AM5/16/23
to
Source: gcc-13
Version: 13.1.0-2
Severity: normal
User: debian...@lists.debian.org
Usertags: alpha
X-Debbugs-Cc: debian...@lists.debian.org
Hello!
After a long discussion on IRC and the mailing list, we have agreed to raise the
baseline for the alpha architecture to EV56 to improve the generated code and fix
a number of issues. The change is already being implemented in the glibc packages
which switches to EV56 [1] since hwcaps are no longer available with glibc 2.37 [2].
Could you raise the baseline for gcc on alpha to EV56?
I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56".
Thanks,
Adrian
> [1] https://salsa.debian.org/glibc-team/glibc/-/commit/7af7b56d5f5fef7a4f3c011b36774e4556563d3d
> [2] https://salsa.debian.org/glibc-team/glibc/-/commit/4d57b6af3efd1d6af277b2eb67fe9ee500e7ae68
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Version: 13.1.0-2
Severity: normal
User: debian...@lists.debian.org
Usertags: alpha
X-Debbugs-Cc: debian...@lists.debian.org
Hello!
After a long discussion on IRC and the mailing list, we have agreed to raise the
baseline for the alpha architecture to EV56 to improve the generated code and fix
a number of issues. The change is already being implemented in the glibc packages
which switches to EV56 [1] since hwcaps are no longer available with glibc 2.37 [2].
Could you raise the baseline for gcc on alpha to EV56?
I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56".
Thanks,
Adrian
> [1] https://salsa.debian.org/glibc-team/glibc/-/commit/7af7b56d5f5fef7a4f3c011b36774e4556563d3d
> [2] https://salsa.debian.org/glibc-team/glibc/-/commit/4d57b6af3efd1d6af277b2eb67fe9ee500e7ae68
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
John Paul Adrian Glaubitz
May 17, 2023, 5:40:05 AM5/17/23
to
Hi Michael!
On Tue, 2023-05-16 at 20:25 +1200, Michael Cree wrote:
>
> I suggest the following in debian/rules2:
>
> ifneq (,$(findstring alpha,$(DEB_TARGET_ARCH)))
> CONFARGS += --with-cpu=ev56 --with-tune=ev6
> endif
>
> (the --with-tune only affects instruction scheduling and better tunes
> code for ev6 and more recent machines, but allows execution down to
> ev56.) I have tested this in the past with a rebuild of most packages
> that are in the base essential chroot in the past and it works well.
Doesn't that come with a speed penalty for EV56 machines? I'm asking because EV56 is
currently the baseline for QEMU when emulating Alpha.
Adrian
On Tue, 2023-05-16 at 20:25 +1200, Michael Cree wrote:
> On Tue, May 16, 2023 at 09:38:56AM +0200, John Paul Adrian Glaubitz wrote:
> > After a long discussion on IRC and the mailing list, we have agreed to raise the
> > baseline for the alpha architecture to EV56 to improve the generated code and fix
> > a number of issues. The change is already being implemented in the glibc packages
> > which switches to EV56 [1] since hwcaps are no longer available with glibc 2.37 [2].
> >
> > Could you raise the baseline for gcc on alpha to EV56?
> >
> > I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56".
>
> Yes, please!
> > After a long discussion on IRC and the mailing list, we have agreed to raise the
> > baseline for the alpha architecture to EV56 to improve the generated code and fix
> > a number of issues. The change is already being implemented in the glibc packages
> > which switches to EV56 [1] since hwcaps are no longer available with glibc 2.37 [2].
> >
> > Could you raise the baseline for gcc on alpha to EV56?
> >
> > I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56".
>
>
> I suggest the following in debian/rules2:
>
> ifneq (,$(findstring alpha,$(DEB_TARGET_ARCH)))
> CONFARGS += --with-cpu=ev56 --with-tune=ev6
> endif
>
> (the --with-tune only affects instruction scheduling and better tunes
> code for ev6 and more recent machines, but allows execution down to
> ev56.) I have tested this in the past with a rebuild of most packages
> that are in the base essential chroot in the past and it works well.
Doesn't that come with a speed penalty for EV56 machines? I'm asking because EV56 is
currently the baseline for QEMU when emulating Alpha.
Adrian
Frank Scheiner
May 17, 2023, 3:30:03 PM5/17/23
to
Hi all,
On 17.05.23 11:27, John Paul Adrian Glaubitz wrote:
> Hi Michael!
>
> On Tue, 2023-05-16 at 20:25 +1200, Michael Cree wrote:
>> On Tue, May 16, 2023 at 09:38:56AM +0200, John Paul Adrian Glaubitz wrote:
>>> After a long discussion on IRC and the mailing list, we have agreed to raise the
>>> baseline for the alpha architecture to EV56 to improve the generated code and fix
>>> a number of issues. The change is already being implemented in the glibc packages
>>> which switches to EV56 [1] since hwcaps are no longer available with glibc 2.37 [2].
>>>
>>> Could you raise the baseline for gcc on alpha to EV56?
>>>
>>> I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56".
>>
>> Yes, please!
>>
>> I suggest the following in debian/rules2:
>>
>> ifneq (,$(findstring alpha,$(DEB_TARGET_ARCH)))
>> CONFARGS += --with-cpu=ev56 --with-tune=ev6
>> endif
>>
>> (the --with-tune only affects instruction scheduling and better tunes
>> code for ev6 and more recent machines, but allows execution down to
>> ev56.) I have tested this in the past with a rebuild of most packages
>> that are in the base essential chroot in the past and it works well.
>
> Doesn't that come with a speed penalty for EV56 machines? I'm asking because EV56 is
> currently the baseline for QEMU when emulating Alpha.
How high will it be? I have some numbers from my PWS 500au for 7z 16.02
and openssl 3.0.7, so we could compare that later on.
With everything below EV56 dropped, I'd say let's get everything out of
the later (real) machines and use "ev67" here. Even my DS20E already
uses EV67s.
UPDATE: Reading through [1] and [2], it looks like there's no difference
between EV6 and EV67 for instruction scheduling. So fine as proposed.
[1]: https://gcc.gnu.org/onlinedocs/gcc/DEC-Alpha-Options.html
[2]:
https://uprrp2.uprrp.edu/help?key=SQLPRE72~SQLPRE_Command_Line~Arguments~ARCHITECTURE&title=VMS%20Help&referer=
Cheers,
Frank
On 17.05.23 11:27, John Paul Adrian Glaubitz wrote:
> Hi Michael!
>
> On Tue, 2023-05-16 at 20:25 +1200, Michael Cree wrote:
>> On Tue, May 16, 2023 at 09:38:56AM +0200, John Paul Adrian Glaubitz wrote:
>>> After a long discussion on IRC and the mailing list, we have agreed to raise the
>>> baseline for the alpha architecture to EV56 to improve the generated code and fix
>>> a number of issues. The change is already being implemented in the glibc packages
>>> which switches to EV56 [1] since hwcaps are no longer available with glibc 2.37 [2].
>>>
>>> Could you raise the baseline for gcc on alpha to EV56?
>>>
>>> I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56".
>>
>> Yes, please!
>>
>> I suggest the following in debian/rules2:
>>
>> ifneq (,$(findstring alpha,$(DEB_TARGET_ARCH)))
>> CONFARGS += --with-cpu=ev56 --with-tune=ev6
>> endif
>>
>> (the --with-tune only affects instruction scheduling and better tunes
>> code for ev6 and more recent machines, but allows execution down to
>> ev56.) I have tested this in the past with a rebuild of most packages
>> that are in the base essential chroot in the past and it works well.
>
> Doesn't that come with a speed penalty for EV56 machines? I'm asking because EV56 is
> currently the baseline for QEMU when emulating Alpha.
and openssl 3.0.7, so we could compare that later on.
With everything below EV56 dropped, I'd say let's get everything out of
the later (real) machines and use "ev67" here. Even my DS20E already
uses EV67s.
UPDATE: Reading through [1] and [2], it looks like there's no difference
between EV6 and EV67 for instruction scheduling. So fine as proposed.
[1]: https://gcc.gnu.org/onlinedocs/gcc/DEC-Alpha-Options.html
[2]:
https://uprrp2.uprrp.edu/help?key=SQLPRE72~SQLPRE_Command_Line~Arguments~ARCHITECTURE&title=VMS%20Help&referer=
Cheers,
Frank
Michael Cree
May 19, 2023, 5:30:03 PM5/19/23
to
On Wed, May 17, 2023 at 11:27:43AM +0200, John Paul Adrian Glaubitz wrote:
> Hi Michael!
>
> On Tue, 2023-05-16 at 20:25 +1200, Michael Cree wrote:
> > On Tue, May 16, 2023 at 09:38:56AM +0200, John Paul Adrian Glaubitz wrote:
> > > After a long discussion on IRC and the mailing list, we have agreed to raise the
> > > baseline for the alpha architecture to EV56 to improve the generated code and fix
> > > a number of issues. The change is already being implemented in the glibc packages
> > > which switches to EV56 [1] since hwcaps are no longer available with glibc 2.37 [2].
> > >
> > > Could you raise the baseline for gcc on alpha to EV56?
> > >
> > > I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56".
> >
> > Yes, please!
> >
> > I suggest the following in debian/rules2:
> >
> > ifneq (,$(findstring alpha,$(DEB_TARGET_ARCH)))
> > CONFARGS += --with-cpu=ev56 --with-tune=ev6
> > endif
> >
> > (the --with-tune only affects instruction scheduling and better tunes
> > code for ev6 and more recent machines, but allows execution down to
> > ev56.) I have tested this in the past with a rebuild of most packages
> > that are in the base essential chroot in the past and it works well.
>
> Doesn't that come with a speed penalty for EV56 machines? I'm asking because EV56 is
> currently the baseline for QEMU when emulating Alpha.
I was under the impression that qemu was ev6/ev67 being machine type
> Hi Michael!
>
> On Tue, 2023-05-16 at 20:25 +1200, Michael Cree wrote:
> > On Tue, May 16, 2023 at 09:38:56AM +0200, John Paul Adrian Glaubitz wrote:
> > > After a long discussion on IRC and the mailing list, we have agreed to raise the
> > > baseline for the alpha architecture to EV56 to improve the generated code and fix
> > > a number of issues. The change is already being implemented in the glibc packages
> > > which switches to EV56 [1] since hwcaps are no longer available with glibc 2.37 [2].
> > >
> > > Could you raise the baseline for gcc on alpha to EV56?
> > >
> > > I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56".
> >
> > Yes, please!
> >
> > I suggest the following in debian/rules2:
> >
> > ifneq (,$(findstring alpha,$(DEB_TARGET_ARCH)))
> > CONFARGS += --with-cpu=ev56 --with-tune=ev6
> > endif
> >
> > (the --with-tune only affects instruction scheduling and better tunes
> > code for ev6 and more recent machines, but allows execution down to
> > ev56.) I have tested this in the past with a rebuild of most packages
> > that are in the base essential chroot in the past and it works well.
>
> Doesn't that come with a speed penalty for EV56 machines? I'm asking because EV56 is
> currently the baseline for QEMU when emulating Alpha.
clipper which emulates an ES40. Am I mistaken?
With regards instruction scheduling EV56 is in-order two-instructions
[1] executed per cycle. EV6 and EV67 are out-of-order [2]
four-instructions executed per cycle. Hence, for ev6/ev67 it can be
advantageous to bring forward instructions that are data (operand)
ready and delaying by four cpu-instructions those that depend on a
result of a previous instruction instead of placing them immediately
after the previous instruction to guarantee they don't waste an
instruction slot in the same cpu cycle. [3]
The deleterious impact on ev56 of doing this will be very small to
utterly negligible. It is not worth worrying about.
Regards,
Michael.
[1] Here I am talking about most integer register/register operate
instructions. Memory, integer multiply and floating-point instructions
have longer latencies.
[2] Note that out-of-order does not mean the cpu can bring forward
data ready instructions that have not yet been seen in the instruction
pipeline. That is why we ask the compiler to place them earlier.
[3] Even more advantageous on ev6/ev67 is to loop unroll and evaluate
two iterations of the loop in parallel, i.e., intertwine the two
computational pathways. When I did tests some time ago with gcc (4.6
and earlier versions) the compiler did not do this well, whereas my
manually optimised machine code was getting better than three
instructions executed per cpu cyle on certain code.
0 new messages