View previous topic :: View next topic |
Author |
Message |
lazydog n00b
Joined: 26 Feb 2007 Posts: 64
|
Posted: Sat Jul 29, 2023 3:23 pm Post subject: [gelöst] Kompilierzeit firefox, thunderbird und andere |
|
|
Ich weiss, ein uraltes Thema und eigentlich lernt man damit zu leben, daß manche Pakete mitunter Stunden dauern bis der Compiler fertig ist.
Letztens ist mir aber ein Update von thunderbird sauer aufgestoßen und ich dachte "das gibts doch nicht...". Also habe ich mal angefangen zu suchen und zu schauen ob man da nicht doch ein bisschen optimieren könnte. Wenn man Suchmaschinen befragt wird sich oft über qtwebengine beschwert. Mit ein paar Handkniffen kann man KDE u.a. auch ohne webengine nutzen, ok. Aber legen wir mal harte Zahlen auf den Tisch:
Code: | mars ~ # genlop -t qtwebengine
* dev-qt/qtwebengine
Mon Jul 10 11:11:07 2023 >>> dev-qt/qtwebengine-5.15.10_p20230623
merge time: 55 minutes and 24 seconds. |
Naja gut, könnte schlimmer sein. Mal weiter schauen:
Code: | mars ~ # genlop -t firefox
* www-client/firefox
Mon Jul 10 00:40:48 2023 >>> www-client/firefox-102.13.0
merge time: 2 hours, 32 minutes and 15 seconds.
mars ~ # genlop -t thunderbird
* mail-client/thunderbird
Tue Jul 18 12:55:23 2023 >>> mail-client/thunderbird-102.13.0
merge time: 2 hours, 39 minutes and 42 seconds. |
Das ist natürlich ein Brett..
Sind firefox und thunderbird in den letzten Jahren derart gewachsen, daß man mit kompilieren gar nicht mehr hinterherkommt? Der Rechner ist gefühlt noch gar nicht fertig, schon ist wieder eine neue Version raus...
Oder klemmts bei mir irgendwo?
Meine CPU ist ein Ryzen 5 5800X3D, 64GB RAM
make.conf:
Code: | CFLAGS="-march=znver3 -O2 -pipe"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="${COMMON_FLAGS}"
FFLAGS="${COMMON_FLAGS}"
# NOTE: This stage was built with the bindist Use flag enabled
MAKEOPTS="-j14"
CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt rdrand sha sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3" |
Code: | /etc/fstab:
tmpfs /var/tmp/portage tmpfs size=48G,uid=portage,gid=portage,mode=775 0 0 |
USE-Flags für firefox sind default:
Code: |
* Found these USE flags for www-client/firefox-102.13.0:
U I
+ + clang : Use Clang compiler instead of GCC
+ + dbus : Enable dbus support for anything that needs it (gpsd, gnomemeeting, etc)
- - debug : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see
- - eme-free : Disable EME (DRM plugin) capability at build time
- - geckodriver : Enable WebDriver support
+ + gmp-autoupdate : Allow Gecko Media Plugins (binary blobs) to be automatically downloaded and kept up-to-date in user profiles
- - hardened : Activate default security enhancements for toolchain (gcc, glibc, binutils)
- - hwaccel : Force-enable hardware-accelerated rendering (Mozilla bug 594876)
- - jack : Add support for the JACK Audio Connection Kit
- - libproxy : Enable libproxy support
- - lto : Enable Link Time Optimization (LTO)
+ + openh264 : Use media-libs/openh264 for H264 support instead of downloading binary blob from Mozilla at runtime
- - pgo : Add support for profile-guided optimization for faster binaries - this option will double the compile time
+ + pulseaudio : Add sound server support via media-libs/libpulse (may be PulseAudio or Pipewire, or apulse if installed)
+ + screencast : Enable support for remote desktop and screen cast using PipeWire
- - sndio : Enable support for the media-sound/sndio backend
+ + system-av1 : Use the system-wide media-libs/dav1d and media-libs/libaom library instead of bundled
+ + system-harfbuzz : Use the system-wide media-libs/harfbuzz and media-gfx/graphite2 instead of bundled
+ + system-icu : Use the system-wide dev-libs/icu instead of bundled
+ + system-jpeg : Use the system-wide media-libs/libjpeg-turbo instead of bundled
+ + system-libevent : Use the system-wide dev-libs/libevent instead of bundled
+ + system-libvpx : Use the system-wide media-libs/libvpx instead of bundled
- - system-png : Use the system-wide media-libs/libpng instead of bundled (requires APNG patches)
+ + system-webp : Use the system-wide media-libs/libwebp instead of bundled
+ + wayland : Enable dev-libs/wayland backend
- - wifi : Enable necko-wifi for NetworkManager integration, |
Ich dachte ich werde ccache installieren, aber laut wiki würde das für neue Versionen von firefox gar nichts bringen:
https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Features#Caching_compilation_objects
Quote: | ccache is only helpful if the same application version will be recompiled many times; |
Das habe ich ja nicht vor, Compiler läuft nur an wenn neue Versionen rauskommen.
Auf reddit habe ich ein Thread gefunden, da schreibt jemand von 20 Minuten für firefox mit einem Intel i7-10875H CPU: https://www.reddit.com/r/Gentoo/comments/xpbrfl/compiling_firefox_and_thunderbird/
Beeindruckend Wie macht der das? Oder ist mein Ryzen so übel beim kompilieren?
Hab ich irgendwas übersehen?
Last edited by lazydog on Sat Aug 05, 2023 8:42 am; edited 1 time in total |
|
Back to top |
|
|
b3rT n00b
Joined: 09 Jun 2003 Posts: 72 Location: Germany
|
Posted: Sat Jul 29, 2023 7:08 pm Post subject: |
|
|
Mit ähnlichem Ryzen (Ryzen 7 5700X, 48 GB) komme ich auch unter 20 Minuten
Code: | Wed Jun 7 19:21:59 2023 >>> www-client/firefox-114.0
merge time: 18 minutes and 16 seconds.
Wed Jul 5 17:48:06 2023 >>> www-client/firefox-115.0
merge time: 19 minutes.
Thu Jul 13 08:18:19 2023 >>> www-client/firefox-115.0.2
merge time: 17 minutes and 21 seconds.
|
Was m.M.n viel bingt, ist in der Ramdisk zu kompilieren, aber das hast Du ja auch schon.
Code: | tmpfs on /var/tmp/portage type tmpfs (rw,relatime) |
Rest bei mir ist Standard, auch kein CCache. Code: |
[ebuild R ~] www-client/firefox-115.0.2:rapid::gentoo USE="X clang dbus gmp-autoupdate jumbo-build openh264 pulseaudio screencast system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-webp telemetry wayland -debug -eme-free -geckodriver -hardened -hwaccel -jack -libproxy -lto -pgo (-selinux) -sndio -system-png (-system-python-libs) (-valgrind) -wifi" L10N="de -ach -af -an -ar -ast -az -be -bg -bn -br -bs -ca -ca-valencia -cak -cs -cy -da -dsb -el -en-CA -en-GB -eo -es-AR -es-CL -es-ES -es-MX -et -eu -fa -ff -fi -fr -fur -fy -ga -gd -gl -gn -gu -he -hi -hr -hsb -hu -hy -ia -id -is -it -ja -ka -kab -kk -km -kn -ko -lij -lt -lv -mk -mr -ms -my -nb -ne -nl -nn -oc -pa -pl -pt-BR -pt-PT -rm -ro -ru -sc -sco -si -sk -sl -son -sq -sr -sv -szl -ta -te -th -tl -tr -trs -uk -ur -uz -vi -xh -zh-CN -zh-TW" 19 KiB
|
edit:
Das FF-115 ebuild hat jumbo-build, im Gegensatz zum 102 auch im regulären Repo. |
|
Back to top |
|
|
lazydog n00b
Joined: 26 Feb 2007 Posts: 64
|
Posted: Sun Jul 30, 2023 7:39 am Post subject: |
|
|
Ui, deine CPU ist fast identisch zu meiner. Da sind meine fast 3 Stunden offensichtlich nicht normal
Was ist denn jumbo-build? Das USE-Flage gibts bei firefox-102.13.0:esr gar nicht |
|
Back to top |
|
|
firefly Watchman
Joined: 31 Oct 2002 Posts: 5317
|
Posted: Sun Jul 30, 2023 8:54 am Post subject: |
|
|
lazydog wrote: | Ui, deine CPU ist fast identisch zu meiner. Da sind meine fast 3 Stunden offensichtlich nicht normal
Was ist denn jumbo-build? Das USE-Flage gibts bei firefox-102.13.0:esr gar nicht |
jumbo build ist ein feature wo ein großteil des sourcecodes, z.b. bei C oder C++ (oder auch alles) in einem source file zusammengefasst wird und nur dieses riesige file dann dem compiler übergeben wird. Dadurch kann der compiler zusätzliche optimierungen vornehmen.
Nur geht dass dann meist auf kosten des benötigten RAMs den der compiler dann braucht.
Aber auch ohne jumbo-build sollte das ganze nicht 3h brauchen mit deiner CPU.
Bei meinem System, AMD Ryzen 9 3900X, 32GB Ram und /var/tmp/portage in einer "ramdisk", braucht firefox nur ca 12-13 minuten (www-client/firefox-102.12.0).
Im gegenzug braucht bei mir qtwebengine 1h30min (dev-qt/qtwebengine-5.15.10_p20230505)
Du hast deine "Ramdisk" auf 75% des verfügbaren RAMs eingestellt (size=48G) kann es eventuell sein, dass /var/tmp/portage relativ voll ist und dadurch das system beginnt zu swappen wenn du firefox übersetzt?
Meine "Ramdisk" ist nur 16GB groß und es reicht für alle Pakete, welche ich so im system installiert habe.
Und /var/tmp/portage sollte auch nicht gefüllt sein, wenn keine Pakete gerade installiert werden. _________________ Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
Back to top |
|
|
lazydog n00b
Joined: 26 Feb 2007 Posts: 64
|
Posted: Sun Jul 30, 2023 11:11 am Post subject: |
|
|
Ah verstehe, danke für die Info.
Die RAM-Disk habe ich immer mal abgefragt (mit df ), da waren nie mehr als 6 GB belegt (während firefox übersetzt).
Ich habe aber was anderes entdeckt: In meiner make.conf fehlt
Code: | COMMON_FLAGS="-O2 -march=znver3 -pipe" |
d.h. alles ab CXXFLAGS war gar nicht gesetzt Im Alter sieht man nicht nur schlechter, ich werd wohl auch ein bissel blöd... |
|
Back to top |
|
|
arfe Apprentice
Joined: 24 Aug 2005 Posts: 298 Location: Essen
|
Posted: Sun Jul 30, 2023 11:47 am Post subject: |
|
|
lazydog wrote: | Ah verstehe, danke für die Info.
Die RAM-Disk habe ich immer mal abgefragt (mit df ), da waren nie mehr als 6 GB belegt (während firefox übersetzt).
Ich habe aber was anderes entdeckt: In meiner make.conf fehlt
Code: | COMMON_FLAGS="-O2 -march=znver3 -pipe" |
d.h. alles ab CXXFLAGS war gar nicht gesetzt Im Alter sieht man nicht nur schlechter, ich werd wohl auch ein bissel blöd... |
Das ist aber nicht die Ursache. |
|
Back to top |
|
|
lazydog n00b
Joined: 26 Feb 2007 Posts: 64
|
Posted: Sun Jul 30, 2023 1:09 pm Post subject: |
|
|
Hm, hartnäckig. Momentan habe ich keine Idee.
emerge --info:
Code: | Portage 3.0.49 (python 3.11.4-final-0, default/linux/amd64/17.1/desktop/plasma/systemd, gcc-12, glibc-2.37-r3, 6.4.2-gentoo x86_64)
=================================================================
System uname: Linux-6.4.2-gentoo-x86_64-AMD_Ryzen_7_5800X3D_8-Core_Processor-with-glibc2.37
KiB Mem: 65786280 total, 52851264 free
KiB Swap: 4194300 total, 4194300 free
Timestamp of repository gentoo: Fri, 28 Jul 2023 11:30:01 +0000
Head commit of repository gentoo: 758daba95e6ddb62004d17199e3bed829fae1a4a
sh bash 5.1_p16-r6
ld GNU ld (Gentoo 2.40 p5) 2.40.0
app-misc/pax-utils: 1.3.5::gentoo
app-shells/bash: 5.1_p16-r6::gentoo
dev-lang/perl: 5.36.1-r3::gentoo
dev-lang/python: 3.11.4::gentoo
dev-lang/rust-bin: 1.69.0-r1::gentoo
dev-util/cmake: 3.26.4-r1::gentoo
dev-util/meson: 1.1.1::gentoo
sys-apps/baselayout: 2.13-r1::gentoo
sys-apps/sandbox: 2.37::gentoo
sys-apps/systemd: 253.3-r1::gentoo
sys-devel/autoconf: 2.13-r7::gentoo, 2.71-r6::gentoo
sys-devel/automake: 1.16.5-r1::gentoo
sys-devel/binutils: 2.40-r5::gentoo
sys-devel/binutils-config: 5.5::gentoo
sys-devel/clang: 15.0.7-r3::gentoo, 16.0.6::gentoo
sys-devel/gcc: 12.3.1_p20230526::gentoo
sys-devel/gcc-config: 2.11::gentoo
sys-devel/libtool: 2.4.7-r1::gentoo
sys-devel/lld: 15.0.7::gentoo
sys-devel/llvm: 15.0.7-r3::gentoo, 16.0.6::gentoo
sys-devel/make: 4.4.1-r1::gentoo
sys-kernel/linux-headers: 6.1::gentoo (virtual/os-headers)
sys-libs/glibc: 2.37-r3::gentoo
Repositories:
gentoo
location: /var/db/repos/gentoo
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000
volatile: False
sync-rsync-verify-max-age: 24
sync-rsync-verify-metamanifest: yes
sync-rsync-verify-jobs: 1
sync-rsync-extra-opts:
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="@FREE"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=znver3 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -march=znver3 -pipe"
DISTDIR="/var/cache/distfiles"
ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME"
FCFLAGS="-O2 -march=znver3 -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg-live config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -march=znver3 -pipe"
GENTOO_MIRRORS="rsync://ftp.agdsn.de/gentoo https://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/ https://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ rsync://linux.rz.ruhr-uni-bochum.de/gentoo https://ftp.fau.de/gentoo rsync://ftp.fau.de/gentoo"
LANG="C"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LEX="flex"
MAKEOPTS="-j14"
PKGDIR="/var/cache/binpkgs"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
SHELL="/bin/bash"
USE="X a52 aac acl acpi activities alsa amd64 bluetooth branding bzip2 cairo cdda cdr cli crypt cups dbus declarative dri dts dvd dvdr encode exif flac gdbm gif gtk gui iconv icu ipv6 jpeg kde kwallet lcms libnotify libtirpc mad mng mp3 mp4 mpeg multilib ncurses nls nptl ogg opengl openmp pam pango pcre pdf pipewire plasma png policykit ppds pulseaudio qml qt5 readline screencast sdl seccomp semantic-desktop sound spell split-usr ssl startup-notification svg systemd test-rust tiff truetype udev udisks unicode upower usb vorbis vulkan wayland widgets wxwidgets x264 xattr xcb xft xml xv xvid zlib" ABI_X86="64" ADA_TARGET="gnat_2021" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt rdrand sha sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php8-1" POSTGRES_TARGETS="postgres15" PYTHON_SINGLE_TARGET="python3_11" PYTHON_TARGETS="python3_11" RUBY_TARGETS="ruby31" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq proto steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EMERGE_DEFAULT_OPTS, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LC_ALL, LD, LFLAGS, LIBTOOL, LINGUAS, MAKE, MAKEFLAGS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, RANLIB, READELF, RUSTFLAGS, SIZE, STRINGS, STRIP, YACC, YFLAGS
|
Wo könnte es klemmen.. |
|
Back to top |
|
|
arfe Apprentice
Joined: 24 Aug 2005 Posts: 298 Location: Essen
|
Posted: Sun Jul 30, 2023 5:36 pm Post subject: |
|
|
@lazyfrog
Um meinen Hinweis etwas deutlicher zu machen. Ich habe eher den Verdacht, dass Du in der falschen Richtung schaust.
Was sagt eigentlich:
cpupower frequency-info
bei Dir?
Was für eine AMD Ryzen CPU hast Du?
Hab es schon gesehen, dass Du eine Ryzen 7 5800X hast.
Also Basistaktrate 3.8 GHz - max. 4.7 GHz.
Meine Compile Duration ist für Firefox mit einer AMD Ryzen 7 3700X CPU:
Code: | Tue Jul 4 09:13:44 2023 >>> www-client/firefox-102.12.0
merge time: 17 minutes and 41 seconds.
Fri Jul 7 14:15:01 2023 >>> www-client/firefox-102.13.0
merge time: 18 minutes and 21 seconds.
|
Du solltest also ähnliche Werte wie ich haben. |
|
Back to top |
|
|
lazydog n00b
Joined: 26 Feb 2007 Posts: 64
|
Posted: Sun Jul 30, 2023 6:09 pm Post subject: |
|
|
Code: | cpupower frequency-info
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 2.20 GHz - 4.55 GHz
available frequency steps: 3.40 GHz, 2.80 GHz, 2.20 GHz
available cpufreq governors: conservative ondemand userspace powersave performance schedutil
current policy: frequency should be within 2.20 GHz and 3.40 GHz.
The governor "schedutil" may decide which speed to use
within this range.
current CPU frequency: 2.20 GHz (asserted by call to hardware)
boost state support:
Supported: yes
Active: yes
Boost States: 0
Total States: 3
Pstate-P0: 3400MHz
Pstate-P1: 2800MHz
Pstate-P2: 2200MHz
|
Ist ein 5800X3D, also max turbo ist 4,5 GHz
Bedeutet "available frequency steps: 3.40 GHz, 2.80 GHz, 2.20 GHz" dass der gar nie auf 4,5 GHz hochtaktet? Das würde einiges erklären.. Wo liegt der Fehler? Kernel falsch konfiguriert? |
|
Back to top |
|
|
arfe Apprentice
Joined: 24 Aug 2005 Posts: 298 Location: Essen
|
Posted: Sun Jul 30, 2023 7:20 pm Post subject: |
|
|
lazydog wrote: | Ist ein 5800X3D, also max turbo ist 4,5 GHz
Bedeutet "available frequency steps: 3.40 GHz, 2.80 GHz, 2.20 GHz" dass der gar nie auf 4,5 GHz hochtaktet? Das würde einiges erklären.. Wo liegt der Fehler? Kernel falsch konfiguriert? |
Das ist meine Vermutung:
Schau Dir das Mal an:
https://wiki.gentoo.org/wiki/Ryzen
Übrigens würde ich in der make.conf folgendes setzen:
CFLAGS="-march=native -O2 -pipe"
Damit bist Du auf der sicheren Seite.
So sieht es übrigens bei mir aus:
Code: | cpupower frequency-info
analyzing CPU 0:
driver: amd-pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 20.0 us
hardware limits: 550 MHz - 4.43 GHz
available cpufreq governors: ondemand performance schedutil
current policy: frequency should be within 3.00 GHz and 4.40 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 3.88 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes
AMD PSTATE Highest Performance: 166. Maximum Frequency: 4.43 GHz.
AMD PSTATE Nominal Performance: 135. Nominal Frequency: 3.60 GHz.
AMD PSTATE Lowest Non-linear Performance: 66. Lowest Non-linear Frequency: 1.76 GHz.
AMD PSTATE Lowest Performance: 21. Lowest Frequency: 550 MHz.
|
|
|
Back to top |
|
|
firefly Watchman
Joined: 31 Oct 2002 Posts: 5317
|
Posted: Sun Jul 30, 2023 7:41 pm Post subject: |
|
|
@arfe: Das ist eventuell ein reines anzeige problem, denn lazydog nutzt acpi-cpufreq
Aber du arfe nutzt amd-pstate.
Wobei es natürlich auch sein könnte, dass acpi-cpufreq nicht die volle leistung der CPU ausschöpfen kann.
Aber wenn man den tests von phoronix glauben schenken darf, dann ist der amd-pstate nicht besser als acpu-cpufreq
https://www.phoronix.com/review/amd-pstate-linux517
https://www.phoronix.com/review/amd-pstate-epp-ryzen-mobile
daher sehe ich in der verwendung von acpi-cpufreq eher auch nicht die ursache für den massiven unterschied der compile zeiten von firefox.
Denn auch ich verwende acpi-cpufreq und habe nicht das Problem.
@lazydog Hast du eventuell vor langer zeit mal unterschiedliche MAKEOPTS gesetzt für spezifische Pakete und das dann vergessen?
Was ist die ausgabe von
Code: | grep MAKEO -R /etc/portage/ |
_________________ Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
Back to top |
|
|
firefly Watchman
Joined: 31 Oct 2002 Posts: 5317
|
Posted: Sun Jul 30, 2023 7:44 pm Post subject: |
|
|
lazydog wrote: | Ah verstehe, danke für die Info.
Die RAM-Disk habe ich immer mal abgefragt (mit df ), da waren nie mehr als 6 GB belegt (während firefox übersetzt). |
Hmm wie sah der RAM/Swap verwendung aus während der übersetzung von firefox?
Was ist der größte wert für Swap used in der ausgabe von ? _________________ Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
Back to top |
|
|
arfe Apprentice
Joined: 24 Aug 2005 Posts: 298 Location: Essen
|
Posted: Sun Jul 30, 2023 8:07 pm Post subject: |
|
|
firefly wrote: | @arfe: Das ist eventuell ein reines anzeige problem, denn lazydog nutzt acpi-cpufreq
Aber du arfe nutzt amd-pstate.
|
Du hast falsch gelesen. Das ist ein Problem in der Konfiguration des Kernels und von cpupower. Zu dem für AMD Ryzen 7 nicht acpi-cpufreq das Richtige ist.
Und ich bin mir ziemlich sicher, dass es die Ursache ist. Am Swap wird es nicht liegen, das würde nur minimal länger dauern, anstatt über zwei Stunden.
Und er nutzt nicht Mal alle Cores aus:
MAKEOPTS="-j14" |
|
Back to top |
|
|
kolibri n00b
Joined: 27 Jul 2023 Posts: 27 Location: Boizenburg, Germany
|
Posted: Sun Jul 30, 2023 9:12 pm Post subject: |
|
|
Mir würde da noch die Frage einfallen, ob du generell schlechtere CPU Performance hast als du haben solltest, also auch andere CPU-intensive Tasks nicht so flott laufen wie sie sollten. Vielleicht wird deine CPU auch zu heiß und taktet dann runter? Oder läuft dein RAM gedrosselt?
Mein Ryzen 9 5950X mit 64 GB DDR4-3200 RAM z.B. braucht für Firefox ~10 Minuten. Ebenfalls mit tmpfs, acpi-cpufreq (ondemand) und "-O3 -pipe -march=znver3".
Vielleicht mal "cryptsetup benchmark" als Vergleichsbasis heranziehen? Bei mir ist cryptsetup mit nettle gebaut, daher kein whirlpool support:
Code: | # Die Tests sind nur annähernd genau, da sie nicht auf den Datenträger zugreifen.
PBKDF2-sha1 5857966 Iterationen pro Sekunde für 256-Bit-Schlüssel
PBKDF2-sha256 9986438 Iterationen pro Sekunde für 256-Bit-Schlüssel
PBKDF2-sha512 2452809 Iterationen pro Sekunde für 256-Bit-Schlüssel
PBKDF2-ripemd160 1213629 Iterationen pro Sekunde für 256-Bit-Schlüssel
PBKDF2-whirlpool (nicht zutreffend)
argon2i 16 Iterationen, 1048576 Speicher, 4 parallele Threads (CPUs) für 256-Bit-Schlüssel (Zieldauer 2000 Millisekunden)
argon2id 16 Iterationen, 1048576 Speicher, 4 parallele Threads (CPUs) für 256-Bit-Schlüssel (Zieldauer 2000 Millisekunden)
# Algorithmus | Schlüssel | Verschlüsselung | Entschlüsselung
aes-cbc 128b 1514,4 MiB/s 6444,1 MiB/s
serpent-cbc 128b 144,8 MiB/s 1034,4 MiB/s
twofish-cbc 128b 283,8 MiB/s 528,9 MiB/s
aes-cbc 256b 1138,6 MiB/s 5500,4 MiB/s
serpent-cbc 256b 150,1 MiB/s 1072,1 MiB/s
twofish-cbc 256b 291,3 MiB/s 542,3 MiB/s
aes-xts 256b 5373,1 MiB/s 5381,9 MiB/s
serpent-xts 256b 963,1 MiB/s 952,1 MiB/s
twofish-xts 256b 519,6 MiB/s 525,6 MiB/s
aes-xts 512b 4513,4 MiB/s 4560,6 MiB/s
serpent-xts 512b 967,7 MiB/s 955,5 MiB/s
twofish-xts 512b 521,7 MiB/s 525,5 MiB/s
|
|
|
Back to top |
|
|
pietinger Moderator
Joined: 17 Oct 2006 Posts: 5095 Location: Bavaria
|
Posted: Sun Jul 30, 2023 10:14 pm Post subject: |
|
|
Ich möchte mal kurz einiges ausschließen:
WENN ein emerge von z.B. firefox mit einem AMD_Ryzen_7_5800X3D irgendwo zwischen 12 und 20 Minuten liegen SOLLTE, dann
1. würde der Verzicht von 2 Cores (-j14 statt -j16) dafür sorgen, dass der emerge ca. 10 bis 15 % länger dauert ... das wären also maximal nur 3 Minuten länger,
2. ist der Einsatz von acpi-cpufreq statt AMD P-State sicher nicht für eine Verzehnfachung der emerge-Zeiten verantworlich,
3. wird ein System mit 64 GB RAM sicherlich nicht swappen, solange nicht parallel irgendwas Krasses (*) läuft (auch nicht mit /var/tmp/portage als tmpfs).
* Dies sollte natürlich mit einem Systemmonitor (während des laufenden emerge) von @lazydog überprüft werden - mindestens also lfd. Prozesse, CPU-Last, CPU-Frequcy, RAM Verbrauch und Swap usage.
Was ich nicht auschließen kann:
1. Kernel Version 6.4.2 (da war doch was mit den ersten Minor-Versionen von 6.4 ? Momentan ist 6.4.7 aktuell) ... obwohl eher unwahrscheinlich.
2. Falls der gcc (damals) mit "schlechten" CFLAGS kompiliert wurde, kann das schon zu längeren emerges führen ... obwohl ich es in dieser Dimension auch für unwahrscheinlich halte. Vielleicht aber doch sicherheitshalber den gcc nochmal neu bauen ?
3. Irgendwas "Verrücktes" innerhalb von systemd ... Nein, ich wettere jetzt nicht gegen systemd, sondern will auf einen (engl.) Thread aufmerksam machen, wo das gleiche Problem besteht (und wir den Kernel schon als unschuldig überprüft haben):
https://forums.gentoo.org/viewtopic-t-1163800-highlight-luna80.html
Was man testen kann:
Genauso wie in o.g. Thread kann man mal mit unserer GentooLiveCD (oder auch MinimalInstCD) booten, in das System chrooten und dann einen emerge anwerfen ... (vielleicht vorher o.g. Thread lesen)
Nebenbei:
Antworten wie z.B. "Das ist aber nicht die Ursache" sind nicht hilfreich. Gut, wenn dann wenigstens 6 Stunden später das erklärt wird.
Aber Bemerkungen wie "Du hast falsch gelesen" (oder auch "Lesen kannst Du?" aus einem anderen Thread) sorgen bei mir als Moderator für eine erhöhte Aufmerksamkeit ... |
|
Back to top |
|
|
kolibri n00b
Joined: 27 Jul 2023 Posts: 27 Location: Boizenburg, Germany
|
Posted: Sun Jul 30, 2023 10:49 pm Post subject: |
|
|
GCC sollte auch nicht das Problem sein, da er clang für firefox aktiviert hat. Außerdem spielt doch rust auch schon stark rein bei Firefox und Thunderbird. PGO ist auch deaktiviert, was aktiviert ebenfalls die Kompilierzeit verlängern würde. LTO ebenfalls.
Was ja sonst wirklich sein kann ist der Hinweis von firefly, mal in /etc/portage gucken, ob für Firefox vielleicht noch extra Optionen gesetzt sind (MAKEOPTS auf -j1 oder so) . Code: | grep -ri firefox /etc/portage/ |
|
|
Back to top |
|
|
arfe Apprentice
Joined: 24 Aug 2005 Posts: 298 Location: Essen
|
Posted: Mon Jul 31, 2023 5:25 am Post subject: |
|
|
kolibri wrote: | GCC sollte auch nicht das Problem sein, da er clang für firefox aktiviert hat. Außerdem spielt doch rust auch schon stark rein bei Firefox und Thunderbird. PGO ist auch deaktiviert, was aktiviert ebenfalls die Kompilierzeit verlängern würde. LTO ebenfalls.
Was ja sonst wirklich sein kann ist der Hinweis von firefly, mal in /etc/portage gucken, ob für Firefox vielleicht noch extra Optionen gesetzt sind (MAKEOPTS auf -j1 oder so) . Code: | grep -ri firefox /etc/portage/ |
|
Ich hatte schon geschrieben, dass er
MAKEOPTS="-j14"
gesetzt hat. Also nur zwei Cores weniger, als er hat. Das dürfte auch nicht die Ursache sein. Die CFLAGS sind auch nicht die Ursache, obwohl ich dazu auch schon eine Empfehlung gegeben habe.
Auch sind die Flags bei Firefox bei ihm nicht verdächtig. |
|
Back to top |
|
|
arfe Apprentice
Joined: 24 Aug 2005 Posts: 298 Location: Essen
|
Posted: Mon Jul 31, 2023 6:25 am Post subject: |
|
|
pietinger wrote: | Aber Bemerkungen wie "Du hast falsch gelesen" (oder auch "Lesen kannst Du?" aus einem anderen Thread) sorgen bei mir als Moderator für eine erhöhte Aufmerksamkeit ... |
Lass es bleiben! Er hat falsch gelesen. Punkt! |
|
Back to top |
|
|
firefly Watchman
Joined: 31 Oct 2002 Posts: 5317
|
Posted: Mon Jul 31, 2023 6:59 am Post subject: |
|
|
pietinger wrote: | Ich möchte mal kurz einiges ausschließen:
WENN ein emerge von z.B. firefox mit einem AMD_Ryzen_7_5800X3D irgendwo zwischen 12 und 20 Minuten liegen SOLLTE, dann
1. würde der Verzicht von 2 Cores (-j14 statt -j16) dafür sorgen, dass der emerge ca. 10 bis 15 % länger dauert ... das wären also maximal nur 3 Minuten länger,
2. ist der Einsatz von acpi-cpufreq statt AMD P-State sicher nicht für eine Verzehnfachung der emerge-Zeiten verantworlich,
3. wird ein System mit 64 GB RAM sicherlich nicht swappen, solange nicht parallel irgendwas Krasses (*) läuft (auch nicht mit /var/tmp/portage als tmpfs).
* Dies sollte natürlich mit einem Systemmonitor (während des laufenden emerge) von @lazydog überprüft werden - mindestens also lfd. Prozesse, CPU-Last, CPU-Frequcy, RAM Verbrauch und Swap usage. |
Ein Allgemeines Problem mit "problematischen" Kernel oder systemd setup ist aus meiner sicht eher unwahrscheinlich, da das übersetzen von dev-qt/qtwebengine bei Ihm ca eine Stunde dauert. Aber komplett ausschließen kann man es natürlich auch nicht.
Und qtwebengine ist bekannt lange compile zeiten zu erzeugen wie man an einigen Threads hier in diesem Forum sehen kann wo viele Nutzer fragen stellten wie sie auf dieses Paket verzichten können
lazydog wrote: | mars ~ # genlop -t qtwebengine
* dev-qt/qtwebengine
Mon Jul 10 11:11:07 2023 >>> dev-qt/qtwebengine-5.15.10_p20230623
merge time: 55 minutes and 24 seconds. |
Was noch eine Ursache sein könnte, wäre eventuell ein thermisches Problem, und zwar dass die CPU zu heiß wird und dadurch herunter taktet um nicht beschädigt zu werden.
Wobei das auch nicht unbedingt erklärt wieso qtwebengine im vergleich so viel schneller gebaut wird.
Denn wenn es ein generelles Problem geben würde, dann müsste das bauen von qtwebenigne eher an die 10h dauern damit es im Verhältnis zu den 3h für firefox passen würde.
Da firefox rust verwendet, und lazydog AVX/AVX2 aktiviert hat, könnte es sein, dass der rust compiler AVX/AVX2 verwendet, welche zu einer höheren Last in der CPU führen könnte, wodurch die CPU nicht mehr ihren Turbotakt erreichen kann (wie es bei Intel schon nachgewiesen wurde).
Wie schon gesagt auf meinem System mit einem AMD Ryzen 9 3900X (welches 2 Generationen älter ist als die CPU von lazydog) mit 32GB Ram ist die dauer von qtwebengine und firefox wie folgt:
Quote: |
Sat Jun 17 20:03:44 2023 >>> dev-qt/qtwebengine-5.15.10_p20230505
merge time: 1 hour, 25 minutes and 13 seconds.
Sun Jun 18 02:08:55 2023 >>> dev-qt/qtwebengine-5.15.10_p20230505
merge time: 1 hour, 39 minutes and 26 seconds.
|
Quote: |
Fri May 19 13:59:45 2023 >>> www-client/firefox-102.11.0
merge time: 11 minutes and 29 seconds.
Sun Jun 18 02:31:22 2023 >>> www-client/firefox-102.12.0
merge time: 12 minutes and 9 seconds.
|
Bei qtwebengine verwende ich MAKEOPTS=-j12 da ich eine 16GB zram-disk für /var/tmp/portage habe + eine 12GB zram-disk für swap
Default ist bei mir MAKEOPTS=-j18 bei 12 echten Kernen und durch HT 24 Kerne.
@arfe Nur weil die AMD_Ryzen_7_5800X3D durch HT 16 Kerne hat ist es nicht unbedingt ratsam MAKEOPTS auf -j16 zu setzen.
Denn die 8 "virtuellen" CPU kerne sind keine vollständigen CPU kerne. Die CPU kann nur durch HT pro echten Kern zwei Threads parallel ausführen um, vom einen Thread, umgenutzte Teile des CPU kerns besser auslasten zu können.
Wenn jetzt aber beide Threads, welche auf dem selben echten CPU Kern laufen, die selben Teile des Kerns nutzen wollen, dann bricht eher die Performance ein statt das es diese verbessert.
HT ist keine magic bullet, welche einfach die Leistung pro CPU kern verdoppeln kann. Es führt nur zu einer verbesserten gesamtleistung wenn die beiden threads zum Zeitpunkt X unterschiedliche und voneinander unabhängige Teile Nutzen. (z.b. zum Zeitpunkt X macht Thread 1 eine Integer berechnung und der thread 2 macht eine floating point berechnung)
Oder wenn gerade Thread 1 auf IO wartet (z.b. Lesen von Daten aus dem RAM oder SSD/HDD) denn selbst der Zugriff auf den RAM ist im vergleich massiv langsamer zu einem Zugriff auf den L1/L2/L3 cache der CPU selbst.
Ich hab hier zahlen für Intel Kaby Lake i7–7660U CPU running at 2.5GHz. gefunden bezüglich latenzen für den Zugriff auf L1/l2/L3 Cache und RAM
https://forum.unity.com/threads/amd-5800x3d-cache-and-ecs-dots-performance.1221540/
L1 cache hit latency: 5 cycles / 2.5 GHz = 2 ns
L2 cache hit latency: 12 cycles / 2.5 GHz = 4.8 ns
L3 cache hit latency: 42 cycles / 2.5 GHz = 16.8 ns
Memory access latency: L3 cache latency + DRAM latency = ~60-100 ns _________________ Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn.
Last edited by firefly on Mon Jul 31, 2023 7:08 am; edited 1 time in total |
|
Back to top |
|
|
arfe Apprentice
Joined: 24 Aug 2005 Posts: 298 Location: Essen
|
Posted: Mon Jul 31, 2023 7:04 am Post subject: |
|
|
firefly wrote: |
@arfe Nur weil die AMD_Ryzen_7_5800X3D durch HT 16 Kerne hat ist es nicht unbedingt ratsam MAKEOPTS auf -j16 zu setzen.
Denn die 8 "virtuellen" CPU kerne sind keine vollständigen CPU kerne. Die CPU kann nur durch HT pro echten Kern zwei Threads parallel ausführen um, vom einen Thread, umgenutzte Teile des CPU kerns besser auslasten zu können.
Wenn jetzt aber beide Threads, welche auf dem selben echten CPU Kern laufen, die selben Teile des Kerns nutzen wollen, dann bricht eher die Performance ein statt das es diese verbessert.
HT ist keine magic bullet, welche einfach die Leistung pro CPU kern verdoppeln kann. Es führt nur zu einer verbesserten gesamtleistung wenn die beiden threads zum Zeitpunkt X unterschiedliche und voneinander unabhängige Teile Nutzen. (z.b. zum Zeitpunkt X macht Thread 1 eine Integer berechnung und der thread 2 macht eine floating point berechnung) |
Du hast leider wieder falsch gelesen. Das habe ich gar nicht behauptet, sondern nur gemeint, dass er nicht die ganzen Cores ausnutzt. Was Du da reininterpretierst, kann ich nicht nachvollziehen. |
|
Back to top |
|
|
ManfredB Veteran
Joined: 27 Dec 2007 Posts: 1734
|
Posted: Mon Jul 31, 2023 7:06 am Post subject: |
|
|
Sorry, wenn ich hier etwas frage:
Firefox, was ist der Unterschied zu firefox-bin?
Thunderbird, was ist der Unterschied zu thunderbird-bin?
Damit sind alle gefragt, die firefox und thunderbird nutzen.
Gruß
ManfredB |
|
Back to top |
|
|
arfe Apprentice
Joined: 24 Aug 2005 Posts: 298 Location: Essen
|
Posted: Mon Jul 31, 2023 7:13 am Post subject: |
|
|
ManfredB wrote: | Sorry, wenn ich hier etwas frage:
Firefox, was ist der Unterschied zu firefox-bin?
Thunderbird, was ist der Unterschied zu thunderbird-bin?
|
"bin" steht für binary. Damit sollte alles beantwortet sein. |
|
Back to top |
|
|
firefly Watchman
Joined: 31 Oct 2002 Posts: 5317
|
Posted: Mon Jul 31, 2023 7:14 am Post subject: |
|
|
arfe wrote: | firefly wrote: |
@arfe Nur weil die AMD_Ryzen_7_5800X3D durch HT 16 Kerne hat ist es nicht unbedingt ratsam MAKEOPTS auf -j16 zu setzen.
Denn die 8 "virtuellen" CPU kerne sind keine vollständigen CPU kerne. Die CPU kann nur durch HT pro echten Kern zwei Threads parallel ausführen um, vom einen Thread, umgenutzte Teile des CPU kerns besser auslasten zu können.
Wenn jetzt aber beide Threads, welche auf dem selben echten CPU Kern laufen, die selben Teile des Kerns nutzen wollen, dann bricht eher die Performance ein statt das es diese verbessert.
HT ist keine magic bullet, welche einfach die Leistung pro CPU kern verdoppeln kann. Es führt nur zu einer verbesserten gesamtleistung wenn die beiden threads zum Zeitpunkt X unterschiedliche und voneinander unabhängige Teile Nutzen. (z.b. zum Zeitpunkt X macht Thread 1 eine Integer berechnung und der thread 2 macht eine floating point berechnung) |
Du hast leider wieder falsch gelesen. Das habe ich gar nicht behauptet, sondern nur gemeint, dass er nicht die ganzen Cores ausnutzt. Was Du da reininterpretierst, kann ich nicht nachvollziehen. |
Öhm du verstehst nicht den Unterschied zwischen echten Cores und virtuellen Cores, welche durch HT dem System vorgespielt werden. Und wie schon pietinger gesagt hat. Nur weil man 2 Cores weniger nutzt als die durch HT verfügbaren erklärt das null dass die Zeiten fast das 10 fache sind für das bauen von firefox! (3h zu 12-20min)
Ansonsten verstehe ich nicht deine hartnäckigkeit dass die verwendung von -j14 statt -j16 so schlecht sein sollte (wenn man versteht was HT aka Hyperthreading überhaupt leisten kann) _________________ Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
Back to top |
|
|
ManfredB Veteran
Joined: 27 Dec 2007 Posts: 1734
|
Posted: Mon Jul 31, 2023 7:15 am Post subject: |
|
|
Hallo arfe!
Das weiß ich doch.
Aber gibt es irgendwelche Qualitätsunterschiede zwischen firefox unf firefox-bin?
Oder sind beide Pakete auf dem gleichen Level? |
|
Back to top |
|
|
firefly Watchman
Joined: 31 Oct 2002 Posts: 5317
|
Posted: Mon Jul 31, 2023 7:26 am Post subject: |
|
|
arfe wrote: | firefly wrote: | @arfe: Das ist eventuell ein reines anzeige problem, denn lazydog nutzt acpi-cpufreq
Aber du arfe nutzt amd-pstate.
|
Du hast falsch gelesen. Das ist ein Problem in der Konfiguration des Kernels und von cpupower. Zu dem für AMD Ryzen 7 nicht acpi-cpufreq das Richtige ist.
Und ich bin mir ziemlich sicher, dass es die Ursache ist. Am Swap wird es nicht liegen, das würde nur minimal länger dauern, anstatt über zwei Stunden. |
Falls acpi-cpufreq so viel schlechter sei als amd-pstate, wieso sind die zeiten bei @kolibri, welcher auch acpi-cpufreq nutzt, dann auch nur bei 10-20 minuten?
Du verrennst dich hier echt in etwas. Auch habe ich dir Tests von phoronix gezeigt, welche zeigen dass amd-pstate, zu mindesten in den von phoronix verwendeten benchmarks, keinen massiven vorteil bietet!
Und das ganze erklärt auch null wieso andere pakete wie z.b. qtwebengine nicht von dem Problem betroffen sind! _________________ Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|