Arch Linux Looking To Employ LTO By Default, Possibly Raise x86-64 Requirements

[ayumu]

An obvious option would be to support subarchitectures, like archlinux32 does.

[schmidtbag]

What is the percent increase in performance with LTO, and what is the percent increase in RAM usage? If the performance matches or exceeds memory usage, I think it's fine. Although I despise the notion of "RAM is there to be used" as a way to dismiss bloat, I wouldn't consider it bloat if it's making software overall run faster. If this is only increasing the memory footprint of binaries, that's hardly a problem worth worrying about at all.

[kpedersen]

I don't see why the vast majority of Archlinux users should suffer reduced performance just so people with more than 12 year old hardware aren't left behind. This is absurd. This is not Debian we are talking about, this is Archlinux.

I am inclined to agree with you. Whilst I am a massive fan of old crap and when it comes to Linux, I also tend prefer Arch due to the ports-like package management and it is light (so great for old slow crap).

However for people like me we already have Arch32 (https://archlinux32.org/) which is thriving. This is especially useful because even though FreeBSD usually has very good support for ancient hardware, sometimes there are pesky unsupported platforms that Linux can just about keep them useful.

Perhaps the Arch community isn't quite large enough to maintain 4 flavours (Modern-only 64-bit Intel, Older 64-bit Intel, 32-bit intel, ARM)

[HD7950]

I have been using Archlinux for more than 13 years, and one of my main complaints was that for such a rolling release/bleeding edge distro, they were always very conservative on their compilation options. I don't understand why anyone would require running the latest and greatest on such obsolete hardware. For those who for whatever reason still are using cpus older than Intel's Nehalem (which is a dinosaur by modern standards), they can get another more stable distribution for their old hardware. Even for Archlinux, nothing stops those requiring the older architecture support to just take the upstream arch and create their own repositories with legacy support. I don't see why the vast majority of Archlinux users should suffer reduced performance just so people with more than 12 year old hardware aren't left behind. This is absurd. This is not Debian we are talking about, this is Archlinux.

I totally agree with you.

Arch user since 2009.

[ms178]

What is the percent increase in performance with LTO, and what is the percent increase in RAM usage? If the performance matches or exceeds memory usage, I think it's fine. Although I despise the notion of "RAM is there to be used" as a way to dismiss bloat, I wouldn't consider it bloat if it's making software overall run faster. If this is only increasing the memory footprint of binaries, that's hardly a problem worth worrying about at all.

I am not aware of increased RAM usage due to LTO-build binaries. The build process consumes much more RAM with LTO though and the issue was only occuring within debug builds. So this is hardly a point end users should care about. It is more of a problem for developers though.

[angrypie]

Distros are between a rock and hard place since Intel enjoys fusing off extensions so much, e.g. they can't build with v3 because that would exclude almost all Pentiums and Celerons (no AVX). Only recently they decided to grace the Earth with AVX/AVX2-enabled Pentiums.

The last time AMD did that was with the K8 Sempron. Even their lowest embedded Ryzen V1000 has all extensions intact.

[szymon_g]

I'm running SUSE Tumbleweed today . Who knows what I'll be running tomorrow because, believe it or not, the lack of an official zfs-dkms package irks me. Currently using their ZFS package from the filesystems repo. If I install an alternate kernel....welp, no more ZFS disks....

I agree with the other part of your post, but why would you use the ZFS? btrfs is perfectly usable (well, maybe not on the weir raid configurations)

[kneekoo]

While I personally would be fine with raising the requirements, what stops them to offer all flavors (or at least v1 - v3)? Sure it would mean more ressources needed for package infrastructure.

That's 3 times more storage for binary packages on the official repositories, and the same thing for all the mirrors. Not all mirrors can afford such a fast increase in storage requirements, especially when more distros go with the same idea around the same time. So if people lose mirrors for such a reason, that's not great.

[ms178]

Distros are between a rock and hard place since Intel enjoys fusing off extensions so much, e.g. they can't build with v3 because that would exclude almost all Pentiums and Celerons (no AVX). Only recently they decided to grace the Earth with AVX/AVX2-enabled Pentiums.

The last time AMD did that was with the K8 Sempron. Even their lowest embedded Ryzen V1000 has all extensions intact.

With v2 as a baseline there is no problem even with these Pentium and Celerons, out of my head I see only older Intel and AMD CPUs would be left at the baseline (Core 2, Phenom and Phenom II don't support SSE 4.2), but if they cared they should have bought a more capable CPU by now. Concerning v3 support, Intel's product segmentation policies backfire now for these users. The realities of today show that ISA support matters and if these users cared about long-term usage they should have bought another CPU.

[angrypie]

With v2 as a baseline there is no problem even with these Pentium and Celerons, out of my head I see only older Intel and AMD CPUs would be left at the baseline (Core 2, Phenom and Phenom II don't support SSE 4.2), but if they cared they should have bought a more capable CPU by now. Concerning v3 support, Intel's product segmentation policies backfire now for these users. The realities of today show that ISA support matters and if these users cared about long-term usage they should have bought another CPU.

Yeah, Phenom II and Core 2 are already obsolete for the most part. The upside is that some people might be able to upgrade their Phenoms to a lowly FX CPU, which has all the required extensions and is faster than a Phenom for anything but legacy x86 instructions.