View previous topic :: View next topic |
Author |
Message |
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Mon Dec 17, 2018 2:38 pm Post subject: |
|
|
5ace wrote: | Compile @world with -march=generic |
You shouldn't that, because '-march=generic' is invalid. The GCC man page says:
Quote: | There is no -march=generic option because -march indicates the instruction set the compiler can use, and there is no generic instruction set applicable to all processors |
|
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54099 Location: 56N 3W
|
Posted: Mon Dec 17, 2018 2:40 pm Post subject: |
|
|
C5ace,
That will be -march unset and -mtune=generic. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Mon Dec 17, 2018 2:53 pm Post subject: |
|
|
erm67 wrote: | -march local on x86 CPU is usually more powerful |
Sorry, but GCC does not support '-march local'. Did you mean "-march=native"? |
|
Back to top |
|
|
erm67 l33t
Joined: 01 Nov 2005 Posts: 653 Location: EU
|
Posted: Mon Dec 17, 2018 2:53 pm Post subject: |
|
|
mike155 wrote: | erm67 wrote: | -march local on x86 CPU is usually more powerful |
Sorry, but GCC does not support '-march local'. Did you mean "-march=native"? |
of course, sorry _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
|
Cuong Nguyen Apprentice
Joined: 18 Jan 2018 Posts: 152
|
Posted: Mon Dec 17, 2018 3:39 pm Post subject: |
|
|
erm67 wrote: | -march local on x86 CPU is usually more powerful that -march=<cpu name> because it also tunes for the cache size of the current CPU |
Indeed, there are 3 params of CPU cache settings, vary upon CPU sub-specs for Server or Laptop
For example:
For server:
--param l2-cache-size=12288 -mtune=westmere
For laptop:
--param l2-cache-size=3072 -mtune=ivybridge
L2-cache for laptop is 1/4 as for server. |
|
Back to top |
|
|
erm67 l33t
Joined: 01 Nov 2005 Posts: 653 Location: EU
|
Posted: Mon Dec 17, 2018 5:47 pm Post subject: |
|
|
There are also other flags beside ther CPU model ones like the ones set by gentooLTO:
https://github.com/InBetweenNames/gentooLTO _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
|
Terry_Davis n00b
Joined: 20 Dec 2019 Posts: 35
|
Posted: Tue Dec 31, 2019 5:01 pm Post subject: |
|
|
erm67 wrote: | Quote: | Is there any benchmark to prove that per cpu settings help improve execution speed? |
It is not easy to find Gentoo specific benchmarks but since apparently your question is OS agnostic try to give a look at the benchmarks for Clear Linux on Phoronix:
|
Ya I wish Gentoo users were more into coercing people to show off benchmarks
I would certainly like to see how far it can be stretched for latency, bandwidth, and overall performance. Popularity might increase now that Moore's law has not held true. |
|
Back to top |
|
|
erm67 l33t
Joined: 01 Nov 2005 Posts: 653 Location: EU
|
Posted: Tue Dec 31, 2019 6:01 pm Post subject: |
|
|
Why risk to make a bad impression:
https://www.phoronix.com/scan.php?page=article&item=linux-50-march&num=1
All benchmarks are flawed if the results are not what you expect.
Maybe -march=native could make a difference since it also tunes the cache size.
Clear linux however is really faster, and that makes some "features" sond even more stupid.
Hey nobody informed me that the fascist strip-flags is now optional in glibc:
Code: | if ! use custom-cflags; then
# Over-zealous CFLAGS can often cause problems. What may work for one
# person may not work for another. To avoid a large influx of bugs
# relating to failed builds, we strip most CFLAGS out to ensure as few
# problems as possible.
strip-flags
# Lock glibc at -O2; we want to be conservative here.
filter-flags '-O?'
append-flags -O2
fi
|
_________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Wed Jan 01, 2020 7:58 pm Post subject: |
|
|
Interesting choice of hyperbole for something you immediately also describe as optional. |
|
Back to top |
|
|
Ionen Developer
Joined: 06 Dec 2018 Posts: 2702
|
Posted: Wed Jan 01, 2020 8:08 pm Post subject: |
|
|
erm67 wrote: | Hey nobody informed me that the fascist strip-flags is now optional in glibc | If those bother you in other packages, it's easy to override, just add some or all of Code: | strip-flags() { ewarn "strip-flags() ignored"; }
filter-flags() { ewarn "filter-flags() ignored: $@"; }
replace-flags() { ewarn "replace-flags() ignored: $@"; } | to /etc/portage/bashrc. Left warnings just so know what's going on. append-flags() may sometime override things too but added flags are often more important (I have a function that can filter flags from this like -O2 but leaves the rest alone, not that I use -O3 anymore so I don't care much for it Edit: alternatively recall clear linux has an incremental-only -O patch that prevents -O3 then -O2 from resulting in -O2). At your own risks of course but I been happily rolling with that for a while. |
|
Back to top |
|
|
erm67 l33t
Joined: 01 Nov 2005 Posts: 653 Location: EU
|
Posted: Wed Jan 01, 2020 9:33 pm Post subject: |
|
|
Ant P. wrote: | Interesting choice of hyperbole for something you immediately also describe as optional. |
It is now optional ....... that is very recent. I clearly remember a lot of discussions here (years ago with wildhorse and others) with people that enjoyed some CFLAGS and most of them did not know about that function .... and there was no warning that it was being used.That is very fascist from people that (ab)uses the word freedom of choice at every occasion. I mean freedom of choice would be make it optional and configurable, feel free to ignore the bugs if the reporter uses something else, I mean I turn one by one every optimization off using package.env if there is a problem ... still IMHO is not a good reason for that.
remember https://bugs.gentoo.org/74072? the solution is ignore the bug report not remove the flags
FreeBSD and openBSD pass down every cflag and can even be used for the kernel
A lot of people comes to gentoo because they think their computers will be faster and might get upset when they discover that their super cflags get stripped without notice and without warning... and all they get is a mandatory totally unoptimized glibc, possibly slower than what other distro offers.
What about making mandatory to submit emerge --info with every bug report and automatically rejecting those that contain non standard flags? would be smarter and more effective probably.
I am pretty sure that most distro uses something better than just plain -O2 and most benchmark prove that -march=<cpu> makes very little difference in real life, that explains the result of benchmarks, it is not a conspiracy.
previously I used a script that patched the class after every emerge --sync every, than what the gentooLTO overlay provided, I just ripped some parts from it. I am quite satisfied with my subset of flags, mostly a conservative subset of O3, but I should see if I can do something better, I also use armv8 cpu and some things are a bit different. The -march flags are a bit strange because there was a bug in gcc parsing optional cpu features for armv8 a lot of time ago ... some can be omitted now that the bug has been fixed.
Code: | NTHREADS="2"
FLTO="-flto=${NTHREADS}"
GRAPHITE="-fgraphite-identity -ftree-loop-distribution -floop-nest-optimize -floop-strip-mine -floop-interchange -floop-block -ftree-loop-distribute-patterns"
NOPLT="-fno-plt"
CFLAGS="-O2 -march=armv8-a+crc+fp+simd+crypto -mcpu=cortex-a73.cortex-a53+crc+fp+simd+crypto -ftree-vectorize -mtune=cortex-a73.cortex-a53 ${FLTO} ${GRAPHITE} ${NOPLT} -fuse-linker-plugin -pipe --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,-O1,--as-needed,--hash-style=gnu,--sort-common,-z,relro,-z,now ${CXXFLAGS}"
|
I used them for years (also in glibc) without probems but it is a server. I used zrelro znow previously but removed them because I had the impression that were slowing things down but I recently read the om armv8 I must also use no-plt together zrelro znow (like archlinuxarm does). This means that it would be fucking stupid strip -fno-plt from my cflags if I use zrelro znow _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
|
erm67 l33t
Joined: 01 Nov 2005 Posts: 653 Location: EU
|
Posted: Wed Jan 08, 2020 1:51 pm Post subject: |
|
|
Ionen wrote: | erm67 wrote: | Hey nobody informed me that the fascist strip-flags is now optional in glibc | If those bother you in other packages, it's easy to override, just add some or all of Code: | strip-flags() { ewarn "strip-flags() ignored"; }
filter-flags() { ewarn "filter-flags() ignored: $@"; }
replace-flags() { ewarn "replace-flags() ignored: $@"; } | to /etc/portage/bashrc. Left warnings just so know what's going on. append-flags() may sometime override things too but added flags are often more important (I have a function that can filter flags from this like -O2 but leaves the rest alone, not that I use -O3 anymore so I don't care much for it Edit: alternatively recall clear linux has an incremental-only -O patch that prevents -O3 then -O2 from resulting in -O2). At your own risks of course but I been happily rolling with that for a while. |
Well I just emerge -e world with '-fno-plt and -z,relro -z,now' (including glibc) and everything works fine Not so strange since arclinuxarm use those flags systemwide and a lot less extreme that -O3. _________________ Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
Back to top |
|
|
Ionen Developer
Joined: 06 Dec 2018 Posts: 2702
|
Posted: Wed Jan 08, 2020 2:04 pm Post subject: |
|
|
erm67 wrote: | Well I just emerge -e world with '-fno-plt and -z,relro -z,now' (including glibc) and everything works fine Not so strange since arclinuxarm use those flags systemwide and a lot less extreme that -O3. | -fno-plt on glibc does cause it to fail a few tests, but those are all about lazy bindings and since both no-plt and -z now break lazy bindings, but it's really a non-issue for what I've seen. If used, Xorg "may" still needs lazy bindings depending on configuration, but the state of glibc doesn't matter for it.
I really like -fno-plt myself, I've seen fair performance improvements in a few personal tests as it removes some overhead, and lazy bindings are typically considered a security risk anyway. |
|
Back to top |
|
|
|