Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

On 2020-05-07 13:04, Noah Meyerhans wrote: > On Wed, May 06, 2020 at 04:15:09PM +0200, Aurelien Jarno wrote: > > > >One solution for this would be to ship the optimized library in the same > > > >package as the default library. Now this is not acceptable for embedded > > > >systems as they might

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

On Wed, May 06, 2020 at 04:15:09PM +0200, Aurelien Jarno wrote: > > >One solution for this would be to ship the optimized library in the same > > >package as the default library. Now this is not acceptable for embedded > > >systems as they might not need that library and can't remove it. This is >

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

On Wed, May 06, 2020 at 01:56:24PM +0100, Steve McIntyre wrote: >... > On Sun, May 03, 2020 at 11:53:35PM +0200, Aurelien Jarno wrote: > > > >One solution for this would be to ship the optimized library in the same > >package as the default library. Now this is not acceptable for embedded >

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

On 2020-05-06 13:56, Steve McIntyre wrote: > Hey Aurelien, > > On Sun, May 03, 2020 at 11:53:35PM +0200, Aurelien Jarno wrote: > > > >One solution for this would be to ship the optimized library in the same > >package as the default library. Now this is not acceptable for embedded > >systems as

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

Hey Aurelien, On Sun, May 03, 2020 at 11:53:35PM +0200, Aurelien Jarno wrote: > >One solution for this would be to ship the optimized library in the same >package as the default library. Now this is not acceptable for embedded >systems as they might not need that library and can't remove it. This

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

On Mon, May 04, 2020 at 02:45:41PM -0400, Noah Meyerhans wrote: >... > I wonder if it'd make sense for libc to be a virtual package, with > functionality provided by optimized builds and dependencies satisfied > via Provides. I don't know how well dpkg would cope with transitioning > between

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

On Sun, May 03, 2020 at 11:53:35PM +0200, Aurelien Jarno wrote: > The hardware capabilities system works fine upstream, but doesn't work > for us because: > 1) we want to be able to upgrade major upstream version online (as > opposed to fedora for example) > 2) we ship the optimized libraries in a

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

On 2020-04-21 18:37, Noah Meyerhans wrote: > > To be honest from a glibc maintenance point of view it's something I > > would like to avoid. We haven't been actively trying to remove the > > remaining optimized libraries (on i386, hurd and alpha), but we have > > tried to avoid adding new ones.

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

* Florian Weimer: > I raised the matter of compiler defaults on the GCC list: > > The link is now:

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

I raised the matter of compiler defaults on the GCC list: Thanks, Florian

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

* Noah Meyerhans: > On Sun, Apr 12, 2020 at 12:18:35PM +0200, Aurelien Jarno wrote: >> > Significant performance impact has also been observed in less contrived >> > cases (MariaDB and Postgres), but I don't have a repro to share. >> >> But indeed what counts is number on real workloads. It

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

On Wed, Apr 22, 2020 at 05:48:27PM +0100, Steve McIntyre wrote: > Hi folks! Hiya, > > I'm adding a CC to Steve Capper, a colleague in Arm who's our expert > here for this kind of question. He's also a DM in Debian... :-) Now I feel guilty about not doing enough Debian :-). > > On Tue, Apr

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

On Wed, Apr 22, 2020 at 01:08:46PM -0400, Noah Meyerhans wrote: >On Wed, Apr 22, 2020 at 05:48:27PM +0100, Steve McIntyre wrote: >> I think the -moutline-atomics is probably good to enable by default >> once we've got it (gcc 10). that's the suggestion I've heard from gcc >> folks in Arm. > >JFTR,

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

On Wed, Apr 22, 2020 at 05:48:27PM +0100, Steve McIntyre wrote: > I think the -moutline-atomics is probably good to enable by default > once we've got it (gcc 10). that's the suggestion I've heard from gcc > folks in Arm. JFTR, it's been backported to gcc 9 and is available in Debian's gcc-9 as

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

Hi folks! I'm adding a CC to Steve Capper, a colleague in Arm who's our expert here for this kind of question. He's also a DM in Debian... :-) On Tue, Apr 21, 2020 at 06:37:07PM -0400, Noah Meyerhans wrote: >On Sun, Apr 12, 2020 at 12:18:35PM +0200, Aurelien Jarno wrote: > >> It would also be

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

Hi, On 2020-04-10 13:16, Noah Meyerhans wrote: > Package: src:glibc > Version: 2.30-4 > Severity: wishlist > X-Debbugs-CC: debian-...@lists.debian.org > > The ARMv8.1 spec, as implemented by the ARM Neoverse N1 processor, > introduces a set of instructions [1] that result in significant

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

On Sat, Apr 11, 2020 at 10:23:54PM +0200, Florian Weimer wrote: > Or put differently: If upstream doesn't want to default to > -moutline-atomics, why should Debian? Well, ultimately we own our build configurations and the optimizations we enable therein. If we don't want to enable

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

* Noah Meyerhans: > On Sat, Apr 11, 2020 at 09:14:11PM +0200, Florian Weimer wrote: >> > At least if I'm reading the code right (which I may very well not be >> > doing, being generally unfamiliar with gcc internals), -mtune=generic >> > enables the equivalent of ARMv8 support: >> > >> >

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

On Sat, Apr 11, 2020 at 09:14:11PM +0200, Florian Weimer wrote: > > At least if I'm reading the code right (which I may very well not be > > doing, being generally unfamiliar with gcc internals), -mtune=generic > > enables the equivalent of ARMv8 support: > > > >

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

* Noah Meyerhans: > On Sat, Apr 11, 2020 at 08:44:29AM +0200, Florian Weimer wrote: >> > Gcc provides two ways to enable support for these instructions at build >> > time. The simplest, and least disruptive, is to enable -moutline-atomics >> > globally in the arm64 glibc build. >> >> Shouldn't

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

On Sat, Apr 11, 2020 at 08:44:29AM +0200, Florian Weimer wrote: > > Gcc provides two ways to enable support for these instructions at build > > time. The simplest, and least disruptive, is to enable -moutline-atomics > > globally in the arm64 glibc build. > > Shouldn't GCC do this by default, at

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

* Noah Meyerhans: > Gcc provides two ways to enable support for these instructions at build > time. The simplest, and least disruptive, is to enable -moutline-atomics > globally in the arm64 glibc build. Shouldn't GCC do this by default, at least for -mtune=generic?

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

Package: src:glibc Version: 2.30-4 Severity: wishlist X-Debbugs-CC: debian-...@lists.debian.org The ARMv8.1 spec, as implemented by the ARM Neoverse N1 processor, introduces a set of instructions [1] that result in significant performance improvements for multithreaded applications. Sample code