New Architecture for Slackware 15.0

gbschenkel · 03-22-2021, 01:08 PM

Hi all, since I have two machines with Haswell and Broadwell processors, both Xeon E5, one v3 other v4, I was checking around again about using -march=native with GCC for building binary.

I found a thread on Arch they are talking about move to a newer architecture like x86_64-v3. I wonder if Slackware could do the same. I will try to run the same test in the next couple of days(can't do right now). I think this could help improve a lot the performance in Desktop and Servers, but I don't know the specs of all other Slackware Users.

This is the link about the thread on Arch https://lists.archlinux.org/pipermai...ch/048739.html

I used this command

Code:

gcc -march=native -v -E - < /dev/null 2>&1 | grep cc1 | perl -pe 's/ -mno-\S+//g; s/^.* - //g;'

and found my what instructions my processors can use it.

HASWELL(2014)(running Slackware)

Code:

-march=haswell -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mfma -mbmi -mbmi2 -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrdrnd -mf16c -mfsgsbase -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=35840 -mtune=haswell

BROADWELL(2016)(running Proxmox)

Code:

-march=broadwell -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mfma -mbmi -mbmi2 -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=46080 -mtune=broadwell

A bit more about the command which I used. https://stackoverflow.com/a/28205379

Emerson · 03-22-2021, 01:13 PM

There is GCC manual, for every major version, there is "whats new" for every version and there is online GCC changelog. If you are interested in all this then GCC online documentation is the place to start.

drumz · 03-22-2021, 01:17 PM

You should browse this thread if you want to rebuild every Slackware package yourself:

https://www.linuxquestions.org/quest...02/page51.html

Then try adding the appropriate flags when compiling to get your desired result. Good luck!

Also I think it would be better to browse Gentoo documentation for finding potential benefits of compiling with "-march=native".

EdGr · 03-22-2021, 01:27 PM

Slackware is not likely to move to a newer version of the 64-bit architecture since it supports very old hardware (including 32-bit!)

A pragmatic approach is for you to compile with -march=native any programs and libraries that you care about the performance increase. That will be programs that can take advantage of AVX.

I found that compiling with -march=native increased the speed of one program that I care about by 15% on my Haswell-E. That is a big enough difference for me to use -march=native for my local builds.
Ed

LuckyCyborg · 03-22-2021, 01:38 PM

Quote:

Originally Posted by gbschenkel

Hi all, since I have two machines with Haswell and Broadwell processors, both Xeon E5, one v3 other v4, I was checking around again about using -march=native with GCC for building binary.

I found a thread on Arch they are talking about move to a newer architecture like x86_64-v3. I wonder if Slackware could do the same. I will try to run the same test in the next couple of days(can't do right now). I think this could help improve a lot the performance in Desktop and Servers, but I don't know the specs of all other Slackware Users.

This is the link about the thread on Arch https://lists.archlinux.org/pipermai...ch/048739.html

I used this command

Code:

gcc -march=native -v -E - < /dev/null 2>&1 | grep cc1 | perl -pe 's/ -mno-\S+//g; s/^.* - //g;'

and found my what instructions my processors can use it.

HASWELL(2014)(running Slackware)

Code:

-march=haswell -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mfma -mbmi -mbmi2 -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrdrnd -mf16c -mfsgsbase -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=35840 -mtune=haswell

BROADWELL(2016)(running Proxmox)

Code:

-march=broadwell -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mfma -mbmi -mbmi2 -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=46080 -mtune=broadwell

A bit more about the command which I used. https://stackoverflow.com/a/28205379

Switching to using this "x86_64-v3", then to use the SSE4 extensions, will result on Slackware64 to be unable to run in a box with an AMD Phenom II x6 and 64GB DDR3 1600 MHz memory. Because unsupported too old hardware.

I do not think this will happen on our remaining life span.

gbschenkel · 03-22-2021, 02:48 PM

Maybe I didn't express my intention on my first post, I mean not to change the current x86_64 to it, but support a new official architecture for boost the performance in newer hardware, like:

Slackware-i686
Slackware-x86_64
Slackware-"x86_64-v3"

EdGr · 03-22-2021, 04:01 PM

Only a small number of programs benefit from architectural improvements beyond the base x86_64. These are floating-point intensive, i.e. not the kind that typically come with an OS.
Ed

gbschenkel · 03-24-2021, 02:21 AM

After benchmarking the same suite used in Arch discuss, I got this results.
https://openbenchmarking.org/result/...GBSC-210324633

I started using the same flags which Slackware and SlackBuilds use building his packages.(-O2 -fPIC)

----------
Flags used
----------
O2_fPIC_march=x86-64_mtune=generic

Code:

CFLAGS="-O2 -fPIC -march=x86-64 -mtune=generic" CXXFLAGS="-O2 -fPIC -march=x86-64 -mtune=generic"

O3_fPIC_march=x86-64_mtune=generic

Code:

CFLAGS="-O3 -fPIC -march=x86-64 -mtune=generic" CXXFLAGS="-O3 -fPIC -march=x86-64 -mtune=generic"

O2_fPIC_march=haswell_mtune=generic

Code:

CFLAGS="-O2 -fPIC -march=haswell -mtune=generic" CXXFLAGS="-O2 -fPIC -march=x86-64 -mtune=generic"

O3_fPIC_march=haswell_mtune=generic

Code:

CFLAGS="-O3 -fPIC -march=haswell -mtune=generic" CXXFLAGS="-O3 -fPIC -march=x86-64 -mtune=generic"

O2_fPIC_march=native

Code:

CFLAGS="-O2 -fPIC -march=native" CXXFLAGS="-O2 -fPIC -march=native"

O3_fPIC_march=native

Code:

CFLAGS="-O3 -fPIC -march=native" CXXFLAGS="-O3 -fPIC -march=native"

O2_fPIC_march=native_allMyCpuSFlags

Code:

CFLAGS="-O2 -fPIC -march=haswell -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mfma -mbmi -mbmi2 -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrdrnd -mf16c -mfsgsbase -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=35840 -mtune=haswell" CXXFLAGS="-O2 -fPIC -march=haswell -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mfma -mbmi -mbmi2 -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrdrnd -mf16c -mfsgsbase -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=35840 -mtune=haswell"

O3_fPIC_march=native_allMyCpuSFlags

Code:

CFLAGS="-O3 -fPIC -march=haswell -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mfma -mbmi -mbmi2 -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrdrnd -mf16c -mfsgsbase -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=35840 -mtune=haswell" CXXFLAGS="-O3 -fPIC -march=haswell -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mfma -mbmi -mbmi2 -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrdrnd -mf16c -mfsgsbase -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=35840 -mtune=haswell"

Command for retrieve the native flags

Code:

gcc -march=native -v -E - < /dev/null 2>&1 | grep cc1 | perl -pe 's/ -mno-\S+//g; s/^.* - //g;'

bassmadrigal · 03-24-2021, 11:27 AM

Quote:

Originally Posted by gbschenkel

Maybe I didn't express my intention on my first post, I mean not to change the current x86_64 to it, but support a new official architecture for boost the performance in newer hardware, like:

Slackware-i686
Slackware-x86_64
Slackware-"x86_64-v3"

I'm by no means a psychic, but if we look at the history of Slackware's 32bit version, it is unlikely that Pat would create two 64bit versions. Pat has had many 32bit architectures available, but only provided one version of 32bit Slackware. He only started transitioning from i486 to i586 in 2015, 22 years after i586 was introduced.

Even with -current, there's only 11 packages compiled for i686 (which was released in 1995), the kernel (with 3 packages, generic, huge, and modules), cargo, rust, xf86-video-intel, firefox, thunderbird, seamonkey, xaos, and xine-ui. Everything else is based on i586.

Does this mean that Pat won't do a second 64bit version? No, but if history is an indicator, it's unlikely. Similarly, looking at history, it would likely be a long time before Pat would transition the x86_64 builds to x86_64-v3 (potentially 20+ years).

gbschenkel · 08-09-2021, 10:51 PM

Well I started to build the port to the new micro-architecture levels defined in the x86-64 psABI, using the slackware git source repo hosted by alienbob.

I am using the -march=x86-64-v3 with GCC 11.2 since 10.3 don't have this implemented.

After I compile all packages I will provide a public url to you guys tryout.

My aim is to try implement on top of Slackware the glibc-hwcaps which offers a way to load optimized libraries that use additional hardware features that might not be present on all systems, which is already included on glibc 2.33.https://www.phoronix.com/scan.php?pa...-Coming-HWCAPS

RedHat plans to use -march=x86-64-v2 on RHEL 9.https://developers.redhat.com/blog/2...ons_for_rhel_9

Also Suse is working on this stuff https://hackweek.suse.com/all/projec...age-generation.

Maybe I will need use the optimization flag "-O2 -ftree-vectorize" or change it to "-O3" where is enabled by default. I am checking some stuff from ClearLinux, like the FMV patch generator repository. I'm very raw on this subject(brazilian expression, don't know how will sound).

Additional links:
https://sourceware.org/pipermail/lib...ay/113757.html
https://sourceware.org/pipermail/lib...ne/115250.html
https://antlarr.io/2021/03/hackweek-...s-in-opensuse/

gbschenkel · 08-10-2021, 10:11 PM

A few more info, just posting to keep trace.

https://gitlab.archlinux.org/archlin...quests/2/diffs
https://gitlab.archlinux.org/archlin...quests/4/diffs
https://www.ucw.cz/~hubicka/slides/opensuse2018-e.pdf
https://hubicka.blogspot.com/2019/05...rocedural.html

avian · 08-12-2021, 08:05 AM

I know not many are replying to this, but I appreciate your efforts, please keep us posted. I'd be curious to try x86_64-v3 base, glibc, etc packages on a test install if you make them available.

gbschenkel · 02-06-2022, 10:07 PM

In the past 2 days I am refining the Slackware 15.0 source scripts to build with -march=x86-64-v3.
Some packages has issue because couldn't build against parallelism, as example, nvi couldn't install using parallel, needed to force

Code:

make -j1 install

to work.

All my changes on 15.0 are in https://gitlab.com/slackware-brazil/...ree/x86-64-v3/.

I am not ready to release the compiled files, since I am using make_world.sh and they put all files in OUTPUT_LOCATION without the hierarchy. I will move the files to Slackware folders and I will let a ftp, also a rsync to be easy to get or to upgrade to Slackware64:v3 15.0

Right now I am building Qt. Few other packages have not built, one is Plasma-Wayland who ask for Plasma-Wayland-Protocols to be installed, I think they are not in order, I will build it first outside of make_world.sh, then rerun make_word.sh, or just install it from the slackware repo, since it will be rebuilt later.

Well that is all, I will come back in couple of days.

nobodino · 02-07-2022, 02:20 AM

I may be interested by your optimizations for SFS : https://github.com/nobodino/slackware-from-scratch.
For the time being, I want to check the glibc-2.34 transition and then glibc-2.35.
But I will keep an eye on your project.

slackerDude · 02-07-2022, 10:40 AM

This sounds interesting. Does a Ryzen 1700 fall into the "x86_64-v3" category?

I can't think of any reason why this would be a problem, even if only some parts of the system are upgraded - compilation flags should not affect ABI compatability, right?