[arch-dev-public] RFC: Use x86_64-v2 architecture
Hi all, A new RFC has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2 Summary: Make -march=x86_64-v2 the default for our packages. This assumes the following instruction sets which are essentially available on all but the oldest AMD CPUs: CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3 Please visit the above link for discussion. Allan
On 3/2/21 8:51 AM, Allan McRae via arch-dev-public wrote:
Hi all,
A new RFC has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2
Summary: Make -march=x86_64-v2 the default for our packages. This assumes the following instruction sets which are essentially available on all but the oldest AMD CPUs:
CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
Please visit the above link for discussion.
Allan
Hi, Oh no!, bad news for me. I am still running my two machines on AMD Athlon 64 X2. I love Arch, I do not want to leave it :( I am sure that lots of people are on the same position. I am reply here since I am not a archdev anymore so I do not have access to gitlab. Why no build with these flags for packages that really takes advantage of this? Take care.
On 2/3/21 9:51 pm, Allan McRae wrote:
Hi all,
A new RFC has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2
Summary: Make -march=x86_64-v2 the default for our packages. This assumes the following instruction sets which are essentially available on all but the oldest AMD CPUs:
CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
Please visit the above link for discussion.
I'm following this up with a more detailed explanation than in the RFC, because this is really a discussion about the core of Arch Linux. The clear disadvantage of this proposal is that processors older than ~2008 will no longer be supported. We have heard from people who run Arch on these processors, because they will be affected. But that does not mean theses are a high proportion. I suspect we caused more people to not be able to run Arch when we dropped i686 (based purely on the size of the immediate outrage...). What are the advantages? Optimization of binaries. It has been pointed out that glibc and some other packages do hardware detection that allows the use of optimized routines for some functions, so this limits benefits. Great for that software, but not all software than can benefit does this. Also some packages already have variants provided with a -sse4 or -avx2 suffix where there is a major benefit. But this is done on an as-wanted basis, and is a maintenance burden. While the performance gains we will get are debatable in size, another major benefit is power usage. I recompiled my entire system as a test last year to something equivalent to x86_64-v3 (so more optimised than the proposal) and saw a *substantial* increase in battery life on my laptop under usual usage. So there are advantages beyond pure speed improvements. I think this discussion comes down to how Arch Linux wants to position itself and its guiding philosophies. In the early days, the selling points of Arch were rolling release, optimised binaries, and simple packaging (including lack of splitting). We still do rolling release. But I'd venture that openSUSE Tumbleweed does it in a more robust way these days. Our lack of package splitting (e.g. including development headers in the package), does have significant advantages still. However, we have lost our lead on optimized binaries. When we provided i686, other distros were still doing i386 or maybe i486. At that stage, Arch was rejecting older processors. RHEL have announced they will use x86_64-v2 for EL9 [1]. I have not seen any discussion of this, but you would assume Fedora would do it first. Given SUSE was involved in the definition of the three new x86_64 microarchitectures, I'd expect them to move there too. That would make Tumbleweed very attractive over Arch (and I say that with a vested interest in the Arch package manager...). Is Arch a distribution that supports processors that are more than a decade old? There are dozens of other distros that do that too. Or do we drop support for a small fraction of hardware in current use (as we have done on previous occasions) and continue to push the boundaries of a binary based Linux distribution? Are we a distribution that takes a leap before other distros, or just another rolling release distro? Allan [1] https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-li...
On 3/2/21 7:54 PM, Allan McRae via arch-dev-public wrote:
On 2/3/21 9:51 pm, Allan McRae wrote:
Hi all,
A new RFC has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2
Summary: Make -march=x86_64-v2 the default for our packages. This assumes the following instruction sets which are essentially available on all but the oldest AMD CPUs:
CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
Please visit the above link for discussion.
I'm following this up with a more detailed explanation than in the RFC, because this is really a discussion about the core of Arch Linux.
The clear disadvantage of this proposal is that processors older than ~2008 will no longer be supported. We have heard from people who run Arch on these processors, because they will be affected. But that does not mean theses are a high proportion. I suspect we caused more people to not be able to run Arch when we dropped i686 (based purely on the size of the immediate outrage...).
What are the advantages? Optimization of binaries.
It has been pointed out that glibc and some other packages do hardware detection that allows the use of optimized routines for some functions, so this limits benefits. Great for that software, but not all software than can benefit does this.
Also some packages already have variants provided with a -sse4 or -avx2 suffix where there is a major benefit. But this is done on an as-wanted basis, and is a maintenance burden.
While the performance gains we will get are debatable in size, another major benefit is power usage. I recompiled my entire system as a test last year to something equivalent to x86_64-v3 (so more optimised than the proposal) and saw a *substantial* increase in battery life on my laptop under usual usage. So there are advantages beyond pure speed improvements.
I think this discussion comes down to how Arch Linux wants to position itself and its guiding philosophies. In the early days, the selling points of Arch were rolling release, optimised binaries, and simple packaging (including lack of splitting).
We still do rolling release. But I'd venture that openSUSE Tumbleweed does it in a more robust way these days. Our lack of package splitting (e.g. including development headers in the package), does have significant advantages still. However, we have lost our lead on optimized binaries.
When we provided i686, other distros were still doing i386 or maybe i486. At that stage, Arch was rejecting older processors. RHEL have announced they will use x86_64-v2 for EL9 [1]. I have not seen any discussion of this, but you would assume Fedora would do it first. Given SUSE was involved in the definition of the three new x86_64 microarchitectures, I'd expect them to move there too. That would make Tumbleweed very attractive over Arch (and I say that with a vested interest in the Arch package manager...).
Is Arch a distribution that supports processors that are more than a decade old? There are dozens of other distros that do that too. Or do we drop support for a small fraction of hardware in current use (as we have done on previous occasions) and continue to push the boundaries of a binary based Linux distribution? Are we a distribution that takes a leap before other distros, or just another rolling release distro?
I wonder, might this be an interesting time to reintroduce multiple architectures? We used to offer i686 and x86_64. Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go right to -v4. -- Eli Schwartz Bug Wrangler and Trusted User
On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote:
I wonder, might this be an interesting time to reintroduce multiple architectures?
We used to offer i686 and x86_64.
Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go right to -v4.
That is a possibility that has been discussed over the years. It was previously decided that we needed other architecture builds to be automated, and thus automated package signing. This becomes a possibility once we manage to sign databases (which will hit a decade of pacman support in October!). Allan
On 3/2/21 8:10 PM, Allan McRae via arch-dev-public wrote:
On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote:
I wonder, might this be an interesting time to reintroduce multiple architectures?
We used to offer i686 and x86_64.
Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go right to -v4.
That is a possibility that has been discussed over the years. It was previously decided that we needed other architecture builds to be automated, and thus automated package signing. This becomes a possibility once we manage to sign databases (which will hit a decade of pacman support in October!).
I wasn't on the packaging team back when i686 was supported, so I don't know about the experience firsthand. But I thought it was just "run extra-*-build twice and commit the result"? Like i686 builds from a developer with an x86_64 laptop, this is something that should be doable for all architectures from one machine. Building the more advanced architectures might, for some people, require using build.archlinux.org (via offload-build), which come to think of it supports x86-64-v3 but not x86-64-v4... I'm aware of discussion about CPU architectures that are not x86 and which, by and large, members of the packaging team don't have hardware for. (RISC-V, aarch64) This is thoroughly blocked on the theory of autobuilding for practical reasons in ways that x86-64-v2 is not. -- Eli Schwartz Bug Wrangler and Trusted User
On 3/3/21 11:23 am, Eli Schwartz via arch-dev-public wrote:
On 3/2/21 8:10 PM, Allan McRae via arch-dev-public wrote:
On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote:
I wonder, might this be an interesting time to reintroduce multiple architectures?
We used to offer i686 and x86_64.
Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go right to -v4.
That is a possibility that has been discussed over the years. It was previously decided that we needed other architecture builds to be automated, and thus automated package signing. This becomes a possibility once we manage to sign databases (which will hit a decade of pacman support in October!).
I wasn't on the packaging team back when i686 was supported, so I don't know about the experience firsthand. But I thought it was just "run extra-*-build twice and commit the result"?
I assume you also test the packages you build... That was the main issue with i686. So it could be brought back, but is a lot of manual effort for something that should be automated. Allan
On Wed, 2021-03-03 at 11:10 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote:
I wonder, might this be an interesting time to reintroduce multiple architectures?
We used to offer i686 and x86_64.
Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go right to -v4.
That is a possibility that has been discussed over the years. It was previously decided that we needed other architecture builds to be automated, and thus automated package signing. This becomes a possibility once we manage to sign databases (which will hit a decade of pacman support in October!).
Allan
Is it possible to get pacman to allow us to enable multiple architectures at once and prioritize one of them? This way we could just do x86_64 and the maintainer could opt-in into x86_64-* if it makes sense for the package. This would not introduce new effort to maintainers and would solve the issue quite nicely IMO. Cheers, Filipe Laíns
On 3/3/21 11:56 am, Filipe Laíns wrote:
On Wed, 2021-03-03 at 11:10 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote:
I wonder, might this be an interesting time to reintroduce multiple architectures?
We used to offer i686 and x86_64.
Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go right to -v4.
That is a possibility that has been discussed over the years. It was previously decided that we needed other architecture builds to be automated, and thus automated package signing. This becomes a possibility once we manage to sign databases (which will hit a decade of pacman support in October!).
Allan
Is it possible to get pacman to allow us to enable multiple architectures at once and prioritize one of them? This way we could just do x86_64 and the maintainer could opt-in into x86_64-* if it makes sense for the package.
This would not introduce new effort to maintainers and would solve the issue quite nicely IMO.
No it is not possible in pacman (without abusing fall through when failing to download a package from a server). Allan
On 3/2/21 9:12 PM, Allan McRae via arch-dev-public wrote:
On 3/3/21 11:56 am, Filipe Laíns wrote:
On Wed, 2021-03-03 at 11:10 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote:
I wonder, might this be an interesting time to reintroduce multiple architectures?
We used to offer i686 and x86_64.
Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go right to -v4.
That is a possibility that has been discussed over the years. It was previously decided that we needed other architecture builds to be automated, and thus automated package signing. This becomes a possibility once we manage to sign databases (which will hit a decade of pacman support in October!).
Allan
Is it possible to get pacman to allow us to enable multiple architectures at once and prioritize one of them? This way we could just do x86_64 and the maintainer could opt-in into x86_64-* if it makes sense for the package.
This would not introduce new effort to maintainers and would solve the issue quite nicely IMO.
No it is not possible in pacman (without abusing fall through when failing to download a package from a server).
Right, we could have some packages built for arch=(x86_64) but with optimizations and package them in a [community-optimized] repo or something. This seems complicated and doesn't handle conflicting filenames -- which is a serious problem for the server pool and archive. Usually clashes would be eliminated by keying off of the architecture; only one of each package per arch. This would not permit fallthrough though. pacman could, theoretically, learn to support multiple "Architecture"s in pacman.conf, e.g. configure it to support Architecture = x86_64-v2 x86_64 and accept both types of packages. This would be needed in order to support selectively optimizing packages while keeping the same pkgname. -- Eli Schwartz Bug Wrangler and Trusted User
On Wed, 2021-03-03 at 12:12 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 11:56 am, Filipe Laíns wrote:
On Wed, 2021-03-03 at 11:10 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote:
I wonder, might this be an interesting time to reintroduce multiple architectures?
We used to offer i686 and x86_64.
Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go right to -v4.
That is a possibility that has been discussed over the years. It was previously decided that we needed other architecture builds to be automated, and thus automated package signing. This becomes a possibility once we manage to sign databases (which will hit a decade of pacman support in October!).
Allan
Is it possible to get pacman to allow us to enable multiple architectures at once and prioritize one of them? This way we could just do x86_64 and the maintainer could opt-in into x86_64-* if it makes sense for the package.
This would not introduce new effort to maintainers and would solve the issue quite nicely IMO.
No it is not possible in pacman (without abusing fall through when failing to download a package from a server).
Allan
Well, can we add it? What are the technical limitations here? I vaguely remember that package names colliding in the DB could be an issue, is there any way we can solve that? Do you have any suggestions on how this could be fixed? Filipe Laíns
On 3/3/21 7:31 pm, Filipe Laíns wrote:
On Wed, 2021-03-03 at 12:12 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 11:56 am, Filipe Laíns wrote:
On Wed, 2021-03-03 at 11:10 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote:
I wonder, might this be an interesting time to reintroduce multiple architectures?
We used to offer i686 and x86_64.
Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go right to -v4.
That is a possibility that has been discussed over the years. It was previously decided that we needed other architecture builds to be automated, and thus automated package signing. This becomes a possibility once we manage to sign databases (which will hit a decade of pacman support in October!).
Allan
Is it possible to get pacman to allow us to enable multiple architectures at once and prioritize one of them? This way we could just do x86_64 and the maintainer could opt-in into x86_64-* if it makes sense for the package.
This would not introduce new effort to maintainers and would solve the issue quite nicely IMO.
No it is not possible in pacman (without abusing fall through when failing to download a package from a server).
Well, can we add it? What are the technical limitations here? I vaguely remember that package names colliding in the DB could be an issue, is there any way we can solve that? Do you have any suggestions on how this could be fixed?
You would create "core-x86_64-v2" and "extra-x86_64-v2" repos that could be enabled above the current ones. That would involve downloading twice the repos and figuring out our package pool (as you can not do that with different architecture strings). Cleaner to have two separate architecture builds. Allan
On Wed, 2021-03-03 at 19:44 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 7:31 pm, Filipe Laíns wrote:
On Wed, 2021-03-03 at 12:12 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 11:56 am, Filipe Laíns wrote:
On Wed, 2021-03-03 at 11:10 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote:
I wonder, might this be an interesting time to reintroduce multiple architectures?
We used to offer i686 and x86_64.
Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go right to -v4.
That is a possibility that has been discussed over the years. It was previously decided that we needed other architecture builds to be automated, and thus automated package signing. This becomes a possibility once we manage to sign databases (which will hit a decade of pacman support in October!).
Allan
Is it possible to get pacman to allow us to enable multiple architectures at once and prioritize one of them? This way we could just do x86_64 and the maintainer could opt-in into x86_64-* if it makes sense for the package.
This would not introduce new effort to maintainers and would solve the issue quite nicely IMO.
No it is not possible in pacman (without abusing fall through when failing to download a package from a server).
Well, can we add it? What are the technical limitations here? I vaguely remember that package names colliding in the DB could be an issue, is there any way we can solve that? Do you have any suggestions on how this could be fixed?
You would create "core-x86_64-v2" and "extra-x86_64-v2" repos that could be enabled above the current ones. That would involve downloading twice the repos and figuring out our package pool (as you can not do that with different architecture strings). Cleaner to have two separate architecture builds.
Allan
That is a reasonable enough approach, I think, though not optimal. I agree that it would be better to have separate architecture builds. I'd also really like to have this handled automatically by pacman, instead of having user having to manually enable it. Is there nothing we can do to fix the collision in the DB? Right now, the DB is located at https://mirror/core/os/x86_64/core.db Perhaps this does not make that much sense, but what about splitting the arch DBs? https://mirror/core/os/{any,x86_64,x86_64-v2,...}/code.db Does downloading the same data split across a few DBs take that much time? And wouldn't this be mitigated by parallel downloads? This is just me spit-balling... Filipe Laíns
On 3/3/21 8:32 pm, Filipe Laíns wrote:
On Wed, 2021-03-03 at 19:44 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 7:31 pm, Filipe Laíns wrote:
On Wed, 2021-03-03 at 12:12 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 11:56 am, Filipe Laíns wrote:
On Wed, 2021-03-03 at 11:10 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote: > I wonder, might this be an interesting time to reintroduce multiple > architectures? > > We used to offer i686 and x86_64. > > Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go > right > to -v4. >
That is a possibility that has been discussed over the years. It was previously decided that we needed other architecture builds to be automated, and thus automated package signing. This becomes a possibility once we manage to sign databases (which will hit a decade of pacman support in October!).
Allan
Is it possible to get pacman to allow us to enable multiple architectures at once and prioritize one of them? This way we could just do x86_64 and the maintainer could opt-in into x86_64-* if it makes sense for the package.
This would not introduce new effort to maintainers and would solve the issue quite nicely IMO.
No it is not possible in pacman (without abusing fall through when failing to download a package from a server).
Well, can we add it? What are the technical limitations here? I vaguely remember that package names colliding in the DB could be an issue, is there any way we can solve that? Do you have any suggestions on how this could be fixed?
You would create "core-x86_64-v2" and "extra-x86_64-v2" repos that could be enabled above the current ones. That would involve downloading twice the repos and figuring out our package pool (as you can not do that with different architecture strings). Cleaner to have two separate architecture builds.
Allan
That is a reasonable enough approach, I think, though not optimal. I agree that it would be better to have separate architecture builds. I'd also really like to have this handled automatically by pacman, instead of having user having to manually enable it.
Is there nothing we can do to fix the collision in the DB?
Right now, the DB is located at https://mirror/core/os/x86_64/core.db Perhaps this does not make that much sense, but what about splitting the arch DBs? https://mirror/core/os/{any,x86_64,x86_64-v2,...}/code.db Does downloading the same data split across a few DBs take that much time? And wouldn't this be mitigated by parallel downloads? This is just me spit-balling...
I'd hate to be the dbscripts maintainer who implements that! Also, $arch in mirror URLs would likely have issues, as it would need be x86_64 unless there was a complete x86_64-v2 build. I think a partial x86_64-v2 port would be more effort than having a full one. Allan
On Wed, 2021-03-03 at 20:52 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 8:32 pm, Filipe Laíns wrote:
On Wed, 2021-03-03 at 19:44 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 7:31 pm, Filipe Laíns wrote:
On Wed, 2021-03-03 at 12:12 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 11:56 am, Filipe Laíns wrote:
On Wed, 2021-03-03 at 11:10 +1000, Allan McRae via arch-dev-public wrote: > On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote: > > I wonder, might this be an interesting time to reintroduce > > multiple > > architectures? > > > > We used to offer i686 and x86_64. > > > > Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go > > right > > to -v4. > > > > That is a possibility that has been discussed over the years. It > was > previously decided that we needed other architecture builds to be > automated, and thus automated package signing. This becomes a > possibility once we manage to sign databases (which will hit a > decade > of > pacman support in October!). > > Allan
Is it possible to get pacman to allow us to enable multiple architectures at once and prioritize one of them? This way we could just do x86_64 and the maintainer could opt-in into x86_64-* if it makes sense for the package.
This would not introduce new effort to maintainers and would solve the issue quite nicely IMO.
No it is not possible in pacman (without abusing fall through when failing to download a package from a server).
Well, can we add it? What are the technical limitations here? I vaguely remember that package names colliding in the DB could be an issue, is there any way we can solve that? Do you have any suggestions on how this could be fixed?
You would create "core-x86_64-v2" and "extra-x86_64-v2" repos that could be enabled above the current ones. That would involve downloading twice the repos and figuring out our package pool (as you can not do that with different architecture strings). Cleaner to have two separate architecture builds.
Allan
That is a reasonable enough approach, I think, though not optimal. I agree that it would be better to have separate architecture builds. I'd also really like to have this handled automatically by pacman, instead of having user having to manually enable it.
Is there nothing we can do to fix the collision in the DB?
Right now, the DB is located at https://mirror/core/os/x86_64/core.db Perhaps this does not make that much sense, but what about splitting the arch DBs? https://mirror/core/os/{any,x86_64,x86_64-v2,...}/code.db Does downloading the same data split across a few DBs take that much time? And wouldn't this be mitigated by parallel downloads? This is just me spit-balling...
I'd hate to be the dbscripts maintainer who implements that! Also, $arch in mirror URLs would likely have issues, as it would need be x86_64 unless there was a complete x86_64-v2 build.
I think a partial x86_64-v2 port would be more effort than having a full one.
Allan
We are already rewriting dbscripts for the git migration anyway, so I think it's worth exploring. Why would the mirror URLs be an issue if we are using $arch as a placeholder? Sorry if I wasn't clear, but I meant that we would have a partial port! pacman would download all the DBs for the supported archs, hence my question about the DBs. It would look at x86_64-v2 first and if the package wasn't there, it would then look at x86_64. Makes sense? This could cause some breakage, but we work around that. Filipe Laíns
On Wed, Mar 03, 2021 at 11:00:38AM +0000, Filipe Laíns via arch-dev-public wrote:
On Wed, 2021-03-03 at 20:52 +1000, Allan McRae via arch-dev-public wrote:
I'd hate to be the dbscripts maintainer who implements that! Also, $arch in mirror URLs would likely have issues, as it would need be x86_64 unless there was a complete x86_64-v2 build.
I think a partial x86_64-v2 port would be more effort than having a full one.
Allan
We are already rewriting dbscripts for the git migration anyway, so I think it's worth exploring.
We are not rewriting anything (yet) and this is not happening unless more people are interested hacking on the abmysmal dread that is dbscripts. Nothing is going to be explored without someone willing to hack on the code, and that has been few people. -- Morten Linderud PGP: 9C02FF419FECBE16
On 3/3/21 9:00 pm, Filipe Laíns wrote:
On Wed, 2021-03-03 at 20:52 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 8:32 pm, Filipe Laíns wrote:
On Wed, 2021-03-03 at 19:44 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 7:31 pm, Filipe Laíns wrote:
On Wed, 2021-03-03 at 12:12 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 11:56 am, Filipe Laíns wrote: > On Wed, 2021-03-03 at 11:10 +1000, Allan McRae via arch-dev-public > wrote: >> On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote: >>> I wonder, might this be an interesting time to reintroduce >>> multiple >>> architectures? >>> >>> We used to offer i686 and x86_64. >>> >>> Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go >>> right >>> to -v4. >>> >> >> That is a possibility that has been discussed over the years. It >> was >> previously decided that we needed other architecture builds to be >> automated, and thus automated package signing. This becomes a >> possibility once we manage to sign databases (which will hit a >> decade >> of >> pacman support in October!). >> >> Allan > > Is it possible to get pacman to allow us to enable multiple > architectures at > once and prioritize one of them? This way we could just do x86_64 > and > the > maintainer could opt-in into x86_64-* if it makes sense for the > package. > > This would not introduce new effort to maintainers and would solve > the > issue > quite nicely IMO. >
No it is not possible in pacman (without abusing fall through when failing to download a package from a server).
Well, can we add it? What are the technical limitations here? I vaguely remember that package names colliding in the DB could be an issue, is there any way we can solve that? Do you have any suggestions on how this could be fixed?
You would create "core-x86_64-v2" and "extra-x86_64-v2" repos that could be enabled above the current ones. That would involve downloading twice the repos and figuring out our package pool (as you can not do that with different architecture strings). Cleaner to have two separate architecture builds.
Allan
That is a reasonable enough approach, I think, though not optimal. I agree that it would be better to have separate architecture builds. I'd also really like to have this handled automatically by pacman, instead of having user having to manually enable it.
Is there nothing we can do to fix the collision in the DB?
Right now, the DB is located at https://mirror/core/os/x86_64/core.db Perhaps this does not make that much sense, but what about splitting the arch DBs? https://mirror/core/os/{any,x86_64,x86_64-v2,...}/code.db Does downloading the same data split across a few DBs take that much time? And wouldn't this be mitigated by parallel downloads? This is just me spit-balling...
I'd hate to be the dbscripts maintainer who implements that! Also, $arch in mirror URLs would likely have issues, as it would need be x86_64 unless there was a complete x86_64-v2 build.
I think a partial x86_64-v2 port would be more effort than having a full one.
Allan
We are already rewriting dbscripts for the git migration anyway, so I think it's worth exploring. Why would the mirror URLs be an issue if we are using $arch as a placeholder?
Sorry if I wasn't clear, but I meant that we would have a partial port! pacman would download all the DBs for the supported archs, hence my question about the DBs. It would look at x86_64-v2 first and if the package wasn't there, it would then look at x86_64. Makes sense? This could cause some breakage, but we work around that.
The mirror in our mirrorlist file use "$arch" which pacman replaces with the architecture of what it needs to download. Without a complete port, that value would remain as x86_64. So now you need to put each mirror in the mirrorlist file twice (one with x86_64-v2 and one with x86_64), and you would have to assume they stayed in sync or risk partial updates. I think a partial port would require more effort in the long run than a complete one. And if we can do x86_64-v2, we might as well do -v3 too. Allan
On Wed, 2021-03-03 at 21:11 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 9:00 pm, Filipe Laíns wrote:
On Wed, 2021-03-03 at 20:52 +1000, Allan McRae via arch-dev-public wrote:
I'd hate to be the dbscripts maintainer who implements that! Also, $arch in mirror URLs would likely have issues, as it would need be x86_64 unless there was a complete x86_64-v2 build.
I think a partial x86_64-v2 port would be more effort than having a full one.
Allan
We are already rewriting dbscripts for the git migration anyway, so I think it's worth exploring. Why would the mirror URLs be an issue if we are using $arch as a placeholder?
Sorry if I wasn't clear, but I meant that we would have a partial port! pacman would download all the DBs for the supported archs, hence my question about the DBs. It would look at x86_64-v2 first and if the package wasn't there, it would then look at x86_64. Makes sense? This could cause some breakage, but we work around that.
The mirror in our mirrorlist file use "$arch" which pacman replaces with the architecture of what it needs to download. Without a complete port, that value would remain as x86_64. So now you need to put each mirror in the mirrorlist file twice (one with x86_64-v2 and one with x86_64), and you would have to assume they stayed in sync or risk partial updates.
I think a partial port would require more effort in the long run than a complete one. And if we can do x86_64-v2, we might as well do -v3 too.
Allan
Well, pacman could change the behavior here and instead of simply replacing the variable and declaring one sever entry, it could take raw string, evaluate it as each $arch and save the URL for each variant. What I am proposing is to essentially split core.db into one database for each arch. So, let's say the enabled arch are any, x86_64 and x86_64-v2. Then Server = https://mirror/$repo/os/$arch would register the following DBs. https://mirror/core/os/any/core.db https://mirror/core/os/x86_64/core.db https://mirror/core/os/x86_64-v2/core.db x86_64-v2 would have precedence over x86_64, if there is a package there, it would be used, if not then x86_64 would be checked. A full port would introduce a lot of more effort into the packaging workflow. Personally, I maintain a lot of packages and would definitely be affected, this would have an heavy impact my productivity. My proposal allows me to for eg. only do arch=(x86_64 x86_64-v2) in srslte in similar packages, keeping arch=(x86_64) in the rest. Does that make sense to you? :) I think the main counterargument I see for this proposal is the splitting of databases maybe slowing down sync a bit, but honestly, do we really care about that amount of performance hit? And wouldn't that be mitigated with parallel downloads? Filipe Laíns
On 4/3/21 6:38 am, Filipe Laíns wrote:
On Wed, 2021-03-03 at 21:11 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 9:00 pm, Filipe Laíns wrote:
On Wed, 2021-03-03 at 20:52 +1000, Allan McRae via arch-dev-public wrote:
I'd hate to be the dbscripts maintainer who implements that! Also, $arch in mirror URLs would likely have issues, as it would need be x86_64 unless there was a complete x86_64-v2 build.
I think a partial x86_64-v2 port would be more effort than having a full one.
Allan
We are already rewriting dbscripts for the git migration anyway, so I think it's worth exploring. Why would the mirror URLs be an issue if we are using $arch as a placeholder?
Sorry if I wasn't clear, but I meant that we would have a partial port! pacman would download all the DBs for the supported archs, hence my question about the DBs. It would look at x86_64-v2 first and if the package wasn't there, it would then look at x86_64. Makes sense? This could cause some breakage, but we work around that.
The mirror in our mirrorlist file use "$arch" which pacman replaces with the architecture of what it needs to download. Without a complete port, that value would remain as x86_64. So now you need to put each mirror in the mirrorlist file twice (one with x86_64-v2 and one with x86_64), and you would have to assume they stayed in sync or risk partial updates.
I think a partial port would require more effort in the long run than a complete one. And if we can do x86_64-v2, we might as well do -v3 too.
Allan
Well, pacman could change the behavior here and instead of simply replacing the variable and declaring one sever entry, it could take raw string, evaluate it as each $arch and save the URL for each variant.
What I am proposing is to essentially split core.db into one database for each arch.
So, let's say the enabled arch are any, x86_64 and x86_64-v2. Then
Server = https://mirror/$repo/os/$arch
would register the following DBs.
https://mirror/core/os/any/core.db https://mirror/core/os/x86_64/core.db https://mirror/core/os/x86_64-v2/core.db
x86_64-v2 would have precedence over x86_64, if there is a package there, it would be used, if not then x86_64 would be checked.
A full port would introduce a lot of more effort into the packaging workflow. Personally, I maintain a lot of packages and would definitely be affected, this would have an heavy impact my productivity.
My proposal allows me to for eg. only do arch=(x86_64 x86_64-v2) in srslte in similar packages, keeping arch=(x86_64) in the rest.
Does that make sense to you? :)
I think the main counterargument I see for this proposal is the splitting of databases maybe slowing down sync a bit, but honestly, do we really care about that amount of performance hit? And wouldn't that be mitigated with parallel downloads?
The exact same is achieved by having a "core-v2" and an "core" db, where only the x86_64-v2 optimized packages appear in "core-v2". But there would need to be two separate package pools due to name clashes. The dbscripts maintainer has already said no to this. Options realistically are: 1) bump the baseline 2) provide a second more optimized port. Allan
On Wed, 3 Mar 2021 at 23:34, Allan McRae via arch-dev-public <arch-dev-public@lists.archlinux.org> wrote:
Options realistically are:
1) bump the baseline 2) provide a second more optimized port.
3) defer this until better tooling is available to implement (2) Since the RFC is about bumping -march to x86_64-v2, it either gets accepted and my desktop computer can no longer run Arch, or the RFC gets rejected and another approach is proposed in the future. Discussing alternative implementations seems out of scope. For what is worth, you mentioned RHEL 9 adopting x86_64-v2 but I'm not sure it translates well to Arch; companies have shorter replacement timelines for servers and workstations so it makes sense for upcoming RHEL releases to target newer hardware. Furthermore, older machines can stay with RHEL 8 until 2029; Arch doesn't have a fallback like that.
On Wed, 3 Mar 2021 at 23:13, Evangelos Foutras via arch-dev-public <arch-dev-public@lists.archlinux.org> wrote:
On Wed, 3 Mar 2021 at 23:34, Allan McRae via arch-dev-public <arch-dev-public@lists.archlinux.org> wrote:
Options realistically are:
1) bump the baseline 2) provide a second more optimized port.
3) defer this until better tooling is available to implement (2)
Since the RFC is about bumping -march to x86_64-v2, it either gets accepted and my desktop computer can no longer run Arch, or the RFC gets rejected and another approach is proposed in the future. Discussing alternative implementations seems out of scope.
For what is worth, you mentioned RHEL 9 adopting x86_64-v2 but I'm not sure it translates well to Arch; companies have shorter replacement timelines for servers and workstations so it makes sense for upcoming RHEL releases to target newer hardware. Furthermore, older machines can stay with RHEL 8 until 2029; Arch doesn't have a fallback like that.
I'll also back 3). I think having a general mechanism for this and not just bumping baseline and then being able to ship baseline, -v2, -v3, -v4 with that hypothetical general mechanism would make more sense and be less of a hack. Otherwise, we're just going to have the same conversation again down the road.
On 4/3/21 8:30 am, Sven-Hendrik Haase via arch-dev-public wrote:
I'll also back 3). I think having a general mechanism for this and not just bumping baseline and then being able to ship baseline, -v2, -v3, -v4 with that hypothetical general mechanism would make more sense and be less of a hack. Otherwise, we're just going to have the same conversation again down the road.
This RFC essentially comes down to where Arch positions itself. When Arch was founded, it was explicitly built for modern CPUs and that was stated as one of its distinguishing features. Firstly i586, then bumped to i686. This RFC is asking whether we still follow this founding principle. BTW, the tooling to do a -v2 and/or -v3 port is already there. Nothing much has changed in terms of tooling since we removed i686. So adding a port is simple. What is an issue is whether we want a build server to monitor the repos for differences and automatically fill them. That would require package signing infrastructure that we have not achieve for databases in 9.5 years... Allan
On 4/3/21 8:13 am, Evangelos Foutras wrote:
On Wed, 3 Mar 2021 at 23:34, Allan McRae via arch-dev-public <arch-dev-public@lists.archlinux.org> wrote:
Options realistically are:
1) bump the baseline 2) provide a second more optimized port.
3) defer this until better tooling is available to implement (2)
Since the RFC is about bumping -march to x86_64-v2, it either gets accepted and my desktop computer can no longer run Arch, or the RFC gets rejected and another approach is proposed in the future. Discussing alternative implementations seems out of scope.
This is the discussion period to shape the RFC into a form that is acceptable. If (1) is not acceptable, it can transition to (2) if people want that approach. Allan
On 3/3/21 10:54 am, Allan McRae via arch-dev-public wrote:
On 2/3/21 9:51 pm, Allan McRae wrote:
Hi all,
A new RFC has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2
Summary: Make -march=x86_64-v2 the default for our packages. This assumes the following instruction sets which are essentially available on all but the oldest AMD CPUs:
CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
Please visit the above link for discussion.
Lets put discussion on this RFC on hold for a while. Clearly there is a reasonable amount of objection to making x86-64-v2 the default. While this mostly appears to be objection based on personal circumstances and not on the basis of whether this change is good for the distro, I will work within these limits. A lot of comments have suggested adding x86-64-v2 and -v3 as additional architectures instead. I will revamp the the proposal to take that approach. Though, to do this automated would require more work it may be the push we need for a signing enclave to be set up. Allan
On Thu, 2021-03-04 at 21:33 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 10:54 am, Allan McRae via arch-dev-public wrote:
On 2/3/21 9:51 pm, Allan McRae wrote:
Hi all,
A new RFC has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2
Summary: Make -march=x86_64-v2 the default for our packages. This assumes the following instruction sets which are essentially available on all but the oldest AMD CPUs:
CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
Please visit the above link for discussion.
Lets put discussion on this RFC on hold for a while. Clearly there is a reasonable amount of objection to making x86-64-v2 the default. While this mostly appears to be objection based on personal circumstances and not on the basis of whether this change is good for the distro, I will work within these limits.
A lot of comments have suggested adding x86-64-v2 and -v3 as additional architectures instead. I will revamp the the proposal to take that approach. Though, to do this automated would require more work it may be the push we need for a signing enclave to be set up.
Allan
Thank you. Though, I find this a bit dismissive of my feedback arguing that this would very likely not have any significant effect whatsoever in performance, and that it fails to solve the ISA extensions issue we have. While there was some feedback based on personal circumstances, I provided objective argumentation about how the proposal as is is probably not a good idea and not the best path forward. Filipe Laíns
On 4/3/21 9:51 pm, Filipe Laíns wrote:
On Thu, 2021-03-04 at 21:33 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 10:54 am, Allan McRae via arch-dev-public wrote:
On 2/3/21 9:51 pm, Allan McRae wrote:
Hi all,
A new RFC has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2
Summary: Make -march=x86_64-v2 the default for our packages. This assumes the following instruction sets which are essentially available on all but the oldest AMD CPUs:
CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
Please visit the above link for discussion.
Lets put discussion on this RFC on hold for a while. Clearly there is a reasonable amount of objection to making x86-64-v2 the default. While this mostly appears to be objection based on personal circumstances and not on the basis of whether this change is good for the distro, I will work within these limits.
A lot of comments have suggested adding x86-64-v2 and -v3 as additional architectures instead. I will revamp the the proposal to take that approach. Though, to do this automated would require more work it may be the push we need for a signing enclave to be set up.
Allan
Thank you. Though, I find this a bit dismissive of my feedback arguing that this would very likely not have any significant effect whatsoever in performance, and that it fails to solve the ISA extensions issue we have. While there was some feedback based on personal circumstances, I provided objective argumentation about how the proposal as is is probably not a good idea and not the best path forward.
As I said, I am reworking the RFC, so your comments are not ignored but instead just not addressed yet. You are correct that a lot of software where the gains are biggest already provide optimized paths. But there are still gains to be had, and not just in performance. When I recompiled my system with something similar to x86-64-v3, I gained significant battery life on my laptop on daily use. The power saving is likely more noticealbe than speed gains. As part of the updated RFC, I will get some benchmarks included. And I know some packages have multiple variants provided with different optimization level. But the user needs to find them to use them. Looking a pkgstats, that may happen for a decent proportion of tensorflow users, but the other packages not so much. And there are issues with discoverability, and choice of optimization levels. Allan
On 3/4/21 6:33 AM, Allan McRae via arch-dev-public wrote:
On 3/3/21 10:54 am, Allan McRae via arch-dev-public wrote:
On 2/3/21 9:51 pm, Allan McRae wrote:
Hi all,
A new RFC has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2
Summary: Make -march=x86_64-v2 the default for our packages. This assumes the following instruction sets which are essentially available on all but the oldest AMD CPUs:
CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
Please visit the above link for discussion.
Lets put discussion on this RFC on hold for a while. Clearly there is a reasonable amount of objection to making x86-64-v2 the default. While this mostly appears to be objection based on personal circumstances and not on the basis of whether this change is good for the distro, I will work within these limits.
A lot of comments have suggested adding x86-64-v2 and -v3 as additional architectures instead. I will revamp the the proposal to take that approach. Though, to do this automated would require more work it may be the push we need for a signing enclave to be set up.
For the record -- the RFC has now been revamped. The new form of the proposal is to add a -v3 (skipping right over -v2) additional architecture. ``` Alternatives Considered ----------------------- Moving the baseline to x86-64-v2 was discussed, but the gains were not considered enough to justify removal of support for hardware without SSE4.2. ``` -- Eli Schwartz Bug Wrangler and Trusted User
On 13/3/21 6:47 am, Eli Schwartz via arch-dev-public wrote:
On 3/4/21 6:33 AM, Allan McRae via arch-dev-public wrote:
On 3/3/21 10:54 am, Allan McRae via arch-dev-public wrote:
On 2/3/21 9:51 pm, Allan McRae wrote:
Hi all,
A new RFC has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2
Summary: Make -march=x86_64-v2 the default for our packages. This assumes the following instruction sets which are essentially available on all but the oldest AMD CPUs:
CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
Please visit the above link for discussion.
Lets put discussion on this RFC on hold for a while. Clearly there is a reasonable amount of objection to making x86-64-v2 the default. While this mostly appears to be objection based on personal circumstances and not on the basis of whether this change is good for the distro, I will work within these limits.
A lot of comments have suggested adding x86-64-v2 and -v3 as additional architectures instead. I will revamp the the proposal to take that approach. Though, to do this automated would require more work it may be the push we need for a signing enclave to be set up.
For the record -- the RFC has now been revamped. The new form of the proposal is to add a -v3 (skipping right over -v2) additional architecture.
``` Alternatives Considered -----------------------
Moving the baseline to x86-64-v2 was discussed, but the gains were not considered enough to justify removal of support for hardware without SSE4.2. ```
As an FYI - I'm still working on the RFC update. I forgot that pushing to my branch updated the merge request... I'll post a new RFC on the mailing list once it is ready for comment. People are of course free to comment as I work on it so it is in better shape once it is submitted. Allan
On 3/2/21 12:51 PM, Allan McRae via arch-dev-public wrote:
Hi all,
A new RFC has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2
Summary: Make -march=x86_64-v2 the default for our packages. This assumes the following instruction sets which are essentially available on all but the oldest AMD CPUs:
CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
Please visit the above link for discussion.
Allan
Is there a way to test if my system supports those instructions? Maybe a user poll can give us a better overview how many people are affected? ~Nico
On 3/3/21 6:33 pm, NicoHood via arch-dev-public wrote:
On 3/2/21 12:51 PM, Allan McRae via arch-dev-public wrote:
Hi all,
A new RFC has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2
Summary: Make -march=x86_64-v2 the default for our packages. This assumes the following instruction sets which are essentially available on all but the oldest AMD CPUs:
CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
Please visit the above link for discussion.
Allan
Is there a way to test if my system supports those instructions?
cat /proc/cpuinfo | grep sse4_2 If you have support for that, then the rest should be fine.
Maybe a user poll can give us a better overview how many people are affected?
People who are affected have more motivation to answer than those who are not. Any poll would be meaningless. A
participants (8)
-
Allan McRae
-
Eli Schwartz
-
Evangelos Foutras
-
Filipe Laíns
-
Gerardo Exequiel Pozzi
-
Morten Linderud
-
NicoHood
-
Sven-Hendrik Haase