[closed] Will Arch transition to x86-64-v2 CPU requirement?

enihcam · 2022-11-28 15:28:45

Will Arch transition to x86-64-v2 CPU requirement, just like OpenSUSE?

https://www.phoronix.com/news/openSUSE- … -x86-64-v2

refs:
x86-64 baseline All x86-64 CPUs CMOV, CMPXCHG8B, FPU, FXSR, MMX, FXSR, SCE, SSE, SSE2
x86-64-v2 circa 2009 Nehalem / Jaguar CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
x86-64-v3 circa 2015 Haswell / Excavator AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, XSAVE

Last edited by enihcam (2023-01-27 02:26:20)

Scimmia · 2022-11-28 15:29:36

No, the plan is v3 alongside base x86-64

enihcam · 2022-11-28 15:31:25

Scimmia wrote:

No, the plan is v3 alongside base x86-64

Cool!

enihcam · 2022-12-03 11:04:28

Is there a timeline of this plan already?

Scimmia wrote:

No, the plan is v3 alongside base x86-64

Slithery · 2022-12-03 14:42:56

When it's ready.

HLFH · 2022-12-26 07:51:19

Sad. My CPU is x86-64-v2, I would have loved a transition to x86-64-v2 CPU requirement.

cfr · 2022-12-27 01:08:06

HLFH wrote:

Sad. My CPU is x86-64-v2, I would have loved a transition to x86-64-v2 CPU requirement.

Rendering everyone else's hardware incompatible? Or did you mean 'support' rather than 'requirement'?

codemac · 2023-01-05 19:04:50

You can always recompile your packages that you care about using ABS. This is what I've been doing for various packages (kernel, emacs) for many years.

The vast vast majority of software will not see any significant improvement going from x86_64 -> "-v2" or "-v3". Especially big packages that try to dynamically detect CPU types in their binaries anyways.

Pick a few programs you care enough to recompile, and use march / mtune = native. I only upgrade my kernel (and various kernel related packages) if I hit a bug, or if it's been more than 6 months. Then I use package group along with PkgIgnore to make sure new updates don't overwrite them. The kernel is a bit annoying due to how many other packages this means you're tracking, but something like emacs is relatively straight forward.

graysky · 2023-01-05 19:44:33

@codemac - for the kernel, you need to modify the kernel code as it does not honor your *FLAGS. See: https://github.com/graysky2/kernel_compiler_patch

Last edited by graysky (2023-01-05 19:49:12)

codemac · 2023-01-05 21:49:35

KCFLAGS, KCPPFLAGS, etc are always appended at the end of your flags, so they take precedence: https://github.com/torvalds/linux/blob/ … file#L1112

I just set those in my build() PKGBUILD.

The patch you refer to seems to be about adding them as options to `make config` which certainly no one needs to be doing if they're building a package for themselves. Let me know if I misunderstand your patch.

graysky · 2023-01-05 21:59:57

The kernel doesn't work that way in my experience. Test it yourself:

% grep march /etc/makepkg.conf
CFLAGS="-march=znver3 -O2 -pipe -fno-plt -fexceptions \

% cd /path/to/linux
% makepkg -s
...
% ps aux | grep march
facade      54933  0.0  0.0  63308 30260 pts/1    R+   16:57   0:00 /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/cc1 -quiet -nostdinc -I ./arch/x86/include -I 
./arch/x86/include/generated -I ./include -I ./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I ./include/uapi -I ./include/generated/uapi -D __KERNEL__ -D 
CC_USING_FENTRY -D KBUILD_MODFILE="arch/x86/events/intel/ds" -D KBUILD_BASENAME="ds" -D KBUILD_MODNAME="ds" -D __KBUILD_MODNAME=kmod_ds -include 
./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -MMD arch/x86/events/intel/.ds.o.d arch/x86/events/intel/ds.c -quiet -
dumpdir arch/x86/events/intel/ -dumpbase ds.c -dumpbase-ext .c -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -mno-80387 -mno-fp-ret-in-387 -mpreferred-
stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -mindirect-branch=thunk-extern -mindirect-branch-register -mindirect-branch-cs-prefix -
mfunction-return=thunk-extern -mharden-sls=all -mrecord-mcount -mfentry -march=x86-64 -g -gdwarf-5 -O2 -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -
Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -Wno-sign-compare -Wno-frame-address -Wformat-truncation=0 -Wformat-
overflow=0 -Wno-address-of-packed-member -Wframe-larger-than=2048 -Wno-main -Wno-unused-but-set-variable -Wunused-const-variable=0 -Wdangling-pointer=0 -
Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type -Wno-stringop-truncation -Wstringop-overflow=0 -Wno-restrict -Wno-maybe-uninitialized -Wno-array-
bounds -Walloc-size-larger-than=18446744073709551615EiB -Wimplicit-fallthrough=5 -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-
packed-not-aligned -std=gnu11 -p -fmacro-prefix-map=./= -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -fcf-protection=branch -falign-jumps=1 -falign-loops=1 -fno-
asynchronous-unwind-tables -fno-jump-tables -fno-delete-null-pointer-checks -fno-allow-store-data-races -fstack-protector-strong -ftrivial-auto-var-init=zero -fno-stack-clash-
protection -fno-strict-overflow -fstack-check=no -fconserve-stack -o /tmp/ccPHl4wl.s

The -march=znver3 is not honored.

You can add a literal 'echo $CFLAGS' to your PKGBUILD to see that makepkg is using them:

% makepkg -s
...
  -> Prepared linux-minimum version 6.1.3-1-minimum
-march=znver3 -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection

Last edited by graysky (2023-01-05 22:02:21)

codemac · 2023-01-05 22:02:51

Right, which is why I set different flags (KCFLAGS) in a different file (PKGBUILD). I think we're saying roughly the same thing.

graysky · 2023-01-05 22:10:34

Can you show the lines you added to your PKGBUILD's build function? Are you suggesting:

  export KCFLAGS=' -march=znver3'
  export KCPPFLAGS=' -march=znver3'
  make LLVM=$_LLVM LLVM_IAS=$_LLVM all

Last edited by graysky (2023-01-05 22:14:20)

codemac · 2023-01-06 00:52:54

Just go to your kernel package's source directory.

Run "make -n KCFLAGS=myflags all" in your src/ directory. This runs make in dry run mode and prints the commands it was going to run.

See that your flags are included and rejoice.

Some of the command lines are long long long, and run for very short periods of time, which means ps aux may truncate them and miss them.

What I do is put "make KCFLAGS="-march=native -mtune=native" htmldocs all" in my PKGBUILD

graysky · 2023-01-06 09:52:01

The patch I maintain works for folks who want to select it in the nconfig or menuconfig but your way is more simplistic, I like it.

enihcam · 2023-01-25 17:24:22

codemac wrote:

You can always recompile your packages that you care about using ABS. This is what I've been doing for various packages (kernel, emacs) for many years.
The vast vast majority of software will not see any significant improvement going from x86_64 -> "-v2" or "-v3". Especially big packages that try to dynamically detect CPU types in their binaries anyways.
Pick a few programs you care enough to recompile, and use march / mtune = native. I only upgrade my kernel (and various kernel related packages) if I hit a bug, or if it's been more than 6 months. Then I use package group along with PkgIgnore to make sure new updates don't overwrite them. The kernel is a bit annoying due to how many other packages this means you're tracking, but something like emacs is relatively straight forward.

An arch-based distro, CachyOS claims that all its packages "are compiled with LTO and x86-64-v3 optimization, security flags and performance improvements".

The following commands do everything for you.

wget https://build.cachyos.org/cachyos-repo.tar.xz
tar xvf cachyos-repo.tar.xz
cd cachyos-repo
sudo ./cachyos-repo.sh

Trilby · 2023-01-25 19:09:35

Why are you posting on the arch forums with advice on how to run a script to conver their system to another distro? And more importantly, why would one use that script to enable a repo which is trivial to do? And yet more importantly, why would one trust software built by a third party when that ridiculous script is the only bit of information available to assess their competence?

Head_on_a_Stick · 2023-01-25 19:23:06

The script runs a partial upgrade at the end. Oh dear.

enihcam · 2023-01-26 12:44:44

Trilby wrote:

Why are you posting on the arch forums with advice on how to run a script to conver their system to another distro? And more importantly, why would one use that script to enable a repo which is trivial to do? And yet more importantly, why would one trust software built by a third party when that ridiculous script is the only bit of information available to assess their competence?

because I assume you can read the script before run?

d.ALT · 2023-01-26 12:56:37

enihcam wrote:

Trilby wrote:
Why are you posting on the arch forums with advice on how to run a script to conver their system to another distro? And more importantly, why would one use that script to enable a repo which is trivial to do? And yet more importantly, why would one trust software built by a third party when that ridiculous script is the only bit of information available to assess their competence?
because I assume you can read the script before run?

I think Tribly wants you to be aware of this:

Trilby wrote:

trust software built by a third party when that ridiculous script is the only bit of information available to assess their competence?

Trilby · 2023-01-26 13:49:08

Yes, I didn't think I veiled my disdain for that script at all. I'm rarely guilty of couching criticisms in too much subtlety. I'll see if I can rectify that in this case:

That script is ridiculously long and complex aiming to do a trivial task that any archer could do on their own in a small fraction of the time it would take them to read that whole script. I didn't even get to the partial upgrade issue in the script in my reading, I stopped after countless foolish uses of grep / awk / function-encapsulation-for-no-reason-other-than-obscurity / etc. So indeed I can read the script, but will not, as it's shit. Some other less cynical archer, however, might stumble upon your post and follow it blindly and suffer negative consequences of doing so.

However, d.ALT is right on the more important point, that even if that script was not harmful but just very poorly written, it would raise suspicion about the quality of the actual packages in that other distros repos.

In any case claiming that archers should be capable of recognizing that your advice is harmful is no excuse for posting it. Posting links to harmful scripts and instructions for users to run said scripts as root should get one blatantly chastized and publicly ridiculed if not banned.

Further suggesting that users here switch to some other distro for no apparent reason (are you connected w/ that distro somehow) which will result in their systems no longer being supported here is yet again a disservice to them.

Last edited by Trilby (2023-01-26 13:55:35)

Awebb · 2023-01-26 13:52:11

run() {
    if $_install; then
        run_install
    elif $_remove; then
        run_remove
    fi

    yes | pacman -Sy
}

run

Oh my.

seth · 2023-01-26 14:42:47

The natural consequence of decades of teaching programming at the example of java…

enihcam · 2023-01-26 18:17:49

Trilby wrote:

Yes, I didn't think I veiled my disdain for that script at all. I'm rarely guilty of couching criticisms in too much subtlety. I'll see if I can rectify that in this case:
That script is ridiculously long and complex aiming to do a trivial task that any archer could do on their own in a small fraction of the time it would take them to read that whole script. I didn't even get to the partial upgrade issue in the script in my reading, I stopped after countless foolish uses of grep / awk / function-encapsulation-for-no-reason-other-than-obscurity / etc. So indeed I can read the script, but will not, as it's shit. Some other less cynical archer, however, might stumble upon your post and follow it blindly and suffer negative consequences of doing so.
However, d.ALT is right on the more important point, that even if that script was not harmful but just very poorly written, it would raise suspicion about the quality of the actual packages in that other distros repos.
In any case claiming that archers should be capable of recognizing that your advice is harmful is no excuse for posting it. Posting links to harmful scripts and instructions for users to run said scripts as root should get one blatantly chastized and publicly ridiculed if not banned.
Further suggesting that users here switch to some other distro for no apparent reason (are you connected w/ that distro somehow) which will result in their systems no longer being supported here is yet again a disservice to them.

I've been using Arch for production for more than a decade. I have my own disciplines of maintenance of my arch boxes. I use etckeeper + version control of various configurations; I use as fewer AUR packages as possible; I use certificates instead of passwords; I limit privileges of all systemd services; I read doc + code if something goes wrong; I figure out everything about it before I fix it; if I can't patch the fix, I file bugs (to kernel, systemd, etc.); I even use UPS for power backup. Back to the story, i've already stated that CachyOS is "an Arch-based distro". As an Archer, he/she should understand that if he/she had to reach to the goal of completion of 'x86-64-v3' transition, this would be the the only way. What can the most 'negative consequence' be for those blindly followers? Just re-install, I guess, because they play Arch just for testing, curiosity, or fun. They don't care about their systems. They don't want to learn and grow up with Arch. They don't know about declarative, consistency, simplicity. They don't even understand what Arch really is about. Just go back to Ubuntu, Mint, Mac or Windows...I even don't think it's worthy to spend a single second in this conversation. I'd prefer discussing how to help Arch in its v3 transition, however please read the previous replies I got, none of them are not helpful.

CarbonChauvinist · 2023-01-26 21:52:02

I've been using the ALHP unofficial user repo to get v3 builds and has worked pretty well so far.

It's described as a

Go based buildbot to build official Archlinux repos with x86-64 feature levels, -O3 and LTO

It currently only builds for v3 and v2 and here's their current package status page to see which packages are currently being built (by default excludes all "any" architecture packages).

This is not an endorsement, you're responsible for your own vetting... but, just letting others know this is a potential option if they're interested in further exploring.

Arch Linux

#1 2022-11-28 15:28:45

[closed] Will Arch transition to x86-64-v2 CPU requirement?

#2 2022-11-28 15:29:36

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#3 2022-11-28 15:31:25

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#4 2022-12-03 11:04:28

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#5 2022-12-03 14:42:56

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#6 2022-12-26 07:51:19

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#7 2022-12-27 01:08:06

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#8 2023-01-05 19:04:50

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#9 2023-01-05 19:44:33

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#10 2023-01-05 21:49:35

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#11 2023-01-05 21:59:57

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#12 2023-01-05 22:02:51

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#13 2023-01-05 22:10:34

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#14 2023-01-06 00:52:54

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#15 2023-01-06 09:52:01

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#16 2023-01-25 17:24:22

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#17 2023-01-25 19:09:35

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#18 2023-01-25 19:23:06

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#19 2023-01-26 12:44:44

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#20 2023-01-26 12:56:37

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#21 2023-01-26 13:49:08

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#22 2023-01-26 13:52:11

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#23 2023-01-26 14:42:47

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#24 2023-01-26 18:17:49

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

#25 2023-01-26 21:52:02

Re: [closed] Will Arch transition to x86-64-v2 CPU requirement?

Board footer