[gelöst]dev-qt/qtwebengine benötigt 64GB RAM?

Message

ManfredB · Post by **ManfredB** » Sat May 21, 2022 3:58 pm

Hallo zusammen,
ich wollte heute einmal den Versuch wagen, kde-apps-meta zu installieren.

Darin enthalten ist auch qtwebengine, doch da unterbrach das System sofort, weil 64GB RAM nicht zur Verfügung stehen.

Erst in der chroot-Umgebung habe ich das noch verstanden, aber im normal gebooteten System ist das schon üppig.

Ich frage mich dabei; wer hat schon soviel RAM zur Verfügung, um das Programm installieren zu lassen.

Bisher habe ich immer nur eine Auswahl installiert, der Gedanke ist mir kurz gekommen, das gesamte kde-apps-meta zu installieren,
was aber scheitert.

Kann ich etwas daran ändern oder muss ich ganz verzichten darauf?

Nur zur Info: ich habe https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs habe ich eingerichtet.

Gruß
Manfred

ManfredB · Post by **ManfredB** » Sat May 21, 2022 4:00 pm

Code: Select all

>>> Running pre-merge checks for dev-qt/qtwebengine-5.15.4_p20220505
 * Checking for at least 64 GiB RAM ...                                                                                                                                               [ !! ]
 * There is NOT at least 64 GiB RAM
 * Checking for at least 7 GiB disk space at "/var/tmp/portage/dev-qt/qtwebengine-5.15.4_p20220505/temp" ...                                                                          [ ok ]
 * Checking for at least 150 MiB disk space at "/usr" ...                                                                                                                             [ ok ]
 * 
 * Space constraints set in the ebuild were not met!
 * The build will most probably fail, you should enhance the space
 * as per failed tests.
 * 
 * ERROR: dev-qt/qtwebengine-5.15.4_p20220505::gentoo failed (pretend phase):
 *   Build requirements not met!
 * 
 * Call stack:
 *                             ebuild.sh, line 127:  Called pkg_pretend
 *   qtwebengine-5.15.4_p20220505.ebuild, line 153:  Called qtwebengine_check-reqs
 *   qtwebengine-5.15.4_p20220505.ebuild, line 149:  Called check-reqs_pkg_pretend
 *                     check-reqs.eclass, line 104:  Called check-reqs_pkg_setup
 *                     check-reqs.eclass, line  95:  Called _check-reqs_output
 *                     check-reqs.eclass, line 302:  Called die
 * The specific snippet of code:
 *              [[ ${EBUILD_PHASE} == "pretend" && -z ${CHECKREQS_DONOTHING} ]] && \
 *                      die "Build requirements not met!"
 * 
 * If you need support, post the output of `emerge --info '=dev-qt/qtwebengine-5.15.4_p20220505::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=dev-qt/qtwebengine-5.15.4_p20220505::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/dev-qt/qtwebengine-5.15.4_p20220505/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-qt/qtwebengine-5.15.4_p20220505/temp/die.env'.
 * Working directory: '/var/tmp/portage/dev-qt/qtwebengine-5.15.4_p20220505/empty'
 * S: '/var/tmp/portage/dev-qt/qtwebengine-5.15.4_p20220505/work/qtwebengine-5.15.3_p20220505'
>>> Failed to emerge dev-qt/qtwebengine-5.15.4_p20220505, Log file:
>>>  '/var/tmp/portage/dev-qt/qtwebengine-5.15.4_p20220505/temp/build.log'
 * Package:    dev-qt/qtwebengine-5.15.4_p20220505
 * Repository: gentoo
 * Maintainer: qt@gentoo.org gyakovlev@gentoo.org
 * Upstream:   https://bugreports.qt.io/
 * USE:        abi_x86_64 alsa amd64 elibc_glibc jumbo-build kernel_linux system-ffmpeg system-icu userland_GNU widgets
 * FEATURES:   network-sandbox preserve-libs sandbox userpriv usersandbox
 * Checking for at least 64 GiB RAM ...                                                                                                                                               [ !! ]
 * There is NOT at least 64 GiB RAM
 * Checking for at least 7 GiB disk space at "/var/tmp/portage/dev-qt/qtwebengine-5.15.4_p20220505/temp" ...                                                                          [ ok ]
 * Checking for at least 150 MiB disk space at "/usr" ...                                                                                                                             [ ok ]
 * 
 * Space constraints set in the ebuild were not met!
 * The build will most probably fail, you should enhance the space
 * as per failed tests.
 * 
 * ERROR: dev-qt/qtwebengine-5.15.4_p20220505::gentoo failed (pretend phase):
 *   Build requirements not met!
 * 
 * Call stack:
 *                             ebuild.sh, line 127:  Called pkg_pretend
 *   qtwebengine-5.15.4_p20220505.ebuild, line 153:  Called qtwebengine_check-reqs
 *   qtwebengine-5.15.4_p20220505.ebuild, line 149:  Called check-reqs_pkg_pretend
 *                     check-reqs.eclass, line 104:  Called check-reqs_pkg_setup
 *                     check-reqs.eclass, line  95:  Called _check-reqs_output
 *                     check-reqs.eclass, line 302:  Called die
 * The specific snippet of code:
 *              [[ ${EBUILD_PHASE} == "pretend" && -z ${CHECKREQS_DONOTHING} ]] && \
 *                      die "Build requirements not met!"
 * 
 * If you need support, post the output of `emerge --info '=dev-qt/qtwebengine-5.15.4_p20220505::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=dev-qt/qtwebengine-5.15.4_p20220505::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/dev-qt/qtwebengine-5.15.4_p20220505/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-qt/qtwebengine-5.15.4_p20220505/temp/die.env'.
 * Working directory: '/var/tmp/portage/dev-qt/qtwebengine-5.15.4_p20220505/empty'
 * S: '/var/tmp/portage/dev-qt/qtwebengine-5.15.4_p20220505/work/qtwebengine-5.15.3_p20220505'

 * Messages for package dev-qt/qtwebengine-5.15.4_p20220505:

 * There is NOT at least 64 GiB RAM
 * 
 * Space constraints set in the ebuild were not met!
 * The build will most probably fail, you should enhance the space
 * as per failed tests.
 * 
 * ERROR: dev-qt/qtwebengine-5.15.4_p20220505::gentoo failed (pretend phase):
 *   Build requirements not met!
 * 
 * Call stack:
 *                             ebuild.sh, line 127:  Called pkg_pretend
 *   qtwebengine-5.15.4_p20220505.ebuild, line 153:  Called qtwebengine_check-reqs
 *   qtwebengine-5.15.4_p20220505.ebuild, line 149:  Called check-reqs_pkg_pretend
 *                     check-reqs.eclass, line 104:  Called check-reqs_pkg_setup
 *                     check-reqs.eclass, line  95:  Called _check-reqs_output
 *                     check-reqs.eclass, line 302:  Called die
 * The specific snippet of code:
 *              [[ ${EBUILD_PHASE} == "pretend" && -z ${CHECKREQS_DONOTHING} ]] && \
 *                      die "Build requirements not met!"
 * 
 * If you need support, post the output of `emerge --info '=dev-qt/qtwebengine-5.15.4_p20220505::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=dev-qt/qtwebengine-5.15.4_p20220505::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/dev-qt/qtwebengine-5.15.4_p20220505/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-qt/qtwebengine-5.15.4_p20220505/temp/die.env'.
 * Working directory: '/var/tmp/portage/dev-qt/qtwebengine-5.15.4_p20220505/empty'
 * S: '/var/tmp/portage/dev-qt/qtwebengine-5.15.4_p20220505/work/qtwebengine-5.15.3_p20220505'

Post by **fedeliallalinea** » Sat May 21, 2022 4:11 pm

Code: Select all

        # (check-reqs added for bug #570534)
        #
        # Estimate the amount of RAM required
        # Multiplier is *10 because Bash doesn't do floating point maths.
        # Let's crudely assume ~2GB per compiler job for GCC.
        local multiplier=20

        # And call it ~1.5GB for Clang.
        if tc-is-clang ; then
                multiplier=15
        fi

        local CHECKREQS_DISK_BUILD="7G"
        local CHECKREQS_DISK_USR="150M"
        if ! has "distcc" ${FEATURES} ; then
                # bug #830661
                # Not super realistic to come up with good estimates for distcc right now
                local CHECKREQS_MEMORY=$(($(makeopts_jobs)*multiplier/10))G
        fi

Reduzieren Sie den Wert von MAKEOPTS.

ManfredB · Post by **ManfredB** » Sat May 21, 2022 4:16 pm

MAKEOPTS ist ausgeschaltet.

Das wurde mir so empfohlen, weil damit die Prozesse deutlich schneller vonstatten gehen.

Aber ich habe nur 32 GB RAM.

Code: Select all

System:
  Host: unstableKn18 Kernel: 5.17.9-gentoo-dist x86_64 bits: 64
    Desktop: KDE Plasma 5.24.5 Distro: Gentoo Base System release 2.8
Machine:
  Type: Desktop Mobo: Micro-Star model: MPG X570 GAMING PLUS (MS-7C37) v: 2.0
    serial: 07C3722_L41D060312 UEFI: American Megatrends LLC. v: A.F0
    date: 12/16/2021
CPU:
  Info: 16-core model: AMD Ryzen 9 5950X bits: 64 type: MT MCP cache:
    L2: 8 MiB
  Speed (MHz): avg: 2275 min/max: 2200/5083 cores: 1: 2200 2: 2200 3: 2200
    4: 2200 5: 2200 6: 2200 7: 3400 8: 2200 9: 2200 10: 2200 11: 2200 12: 2200
    13: 2200 14: 2200 15: 2200 16: 2200 17: 2200 18: 2200 19: 2200 20: 2200
    21: 2200 22: 2200 23: 2200 24: 2200 25: 2200 26: 2200 27: 2200 28: 2200
    29: 2200 30: 2200 31: 2200 32: 3400
Graphics:
  Device-1: NVIDIA GP106 [GeForce GTX 1060 6GB] driver: nouveau v: kernel
  Display: x11 server: X.org v: 1.21.1.3 driver: X: loaded: nouveau
    unloaded: modesetting gpu: nouveau resolution: <missing: xdpyinfo/xrandr>
    resolution: 1920x1080
  OpenGL: renderer: NV136 v: 4.3 Mesa 22.1.0
Audio:
  Device-1: NVIDIA GP106 High Definition Audio driver: snd_hda_intel
  Device-2: AMD Starship/Matisse HD Audio driver: snd_hda_intel
  Sound Server-1: ALSA v: k5.17.9-gentoo-dist running: yes
  Sound Server-2: PulseAudio v: 15.99.1 running: yes
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
    driver: r8169
  IF: enp39s0 state: up speed: 1000 Mbps duplex: full
    mac: d8:bb:c1:53:f3:ff
Drives:
  Local Storage: total: 2.27 TiB used: 226.51 GiB (9.7%)
  ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 980 PRO 1TB
    size: 931.51 GiB
  ID-2: /dev/nvme1n1 vendor: Samsung model: SSD 980 1TB size: 931.51 GiB
  ID-3: /dev/sda type: USB model: TO Exter nal USB 3.0 size: 465.76 GiB
Partition:
  ID-1: / size: 29.36 GiB used: 10.88 GiB (37.1%) fs: ext4
    dev: /dev/nvme0n1p18
Swap:
  ID-1: swap-1 type: partition size: 8.56 GiB used: 0 KiB (0.0%)
    dev: /dev/nvme0n1p3
Sensors:
  System Temperatures: cpu: N/A mobo: N/A gpu: nouveau temp: 34.0 C
  Fan Speeds (RPM): N/A gpu: nouveau fan: 1440
Info:
  Processes: 369 Uptime: 33m Memory: 31.34 GiB used: 1.44 GiB (4.6%)
  Shell: Bash inxi: 3.3.13

ManfredB · Post by **ManfredB** » Sat May 21, 2022 4:29 pm

Ich habe nun einen Test gestartet:

MAKEOPTS aktiviert: "-j8"

Dann emerge --ask dev-qt/qtwebengine
8 Pakete werden zusätzlich installiert.
Nun bin ich gespannt, wie lange qtwebengine braucht, net-libs/nodejs braucht schon sehr lange.

Daraus schließe ich, daß MAKEOPTS eine kleine Bremse einlegt, die bisher nicht vorhanden war.

Vielen Dank für den Vorschlag mit MAKEOPTS.

Gruß
Manfred

Christian99 · Post by **Christian99** » Mon May 23, 2022 9:50 am

mit MAKEOPTS werden zusätzliche parameter an den "make" aufruf übergeben.
der Parameter "-j8" sagt "make", dass er 8 compilerprozesse gleichzeitig laufen lassen soll.
Wenn du keine MAKEOPTS setzt, wählt portage automatisch eine anzahl an Prozessen, die der anzahl deiner (logischen) CPU kerne entspricht.

Und für qtwebengine wird überprüft, steht im ebuild, dass du pro compileprozess 2GB RAM hast.
Wenn du explizit "-j8" angibst, werden also weniger Compilerprozesse gleichzeitig laufen, was dann auch weniger RAM benötigt, aber länger dauert.

Tja, ich fürchte, da musst du dich dann in normale Gefilde herablassen, und mit den paar Stunden mehr Compilezeit leben, wie die meisten von uns

Josef.95 · Post by **Josef.95** » Tue May 24, 2022 8:25 am

Jo, mit der fetten

Code: Select all

CPU:
  Info: 16-core model: AMD Ryzen 9 5950X

CPU mit 16 Kernen plus 16 threads hat man dann 32 logische Prozessoren,
damit sind 32GB RAM (1 GB pro CPU) nicht viel.

Wenn keine MAKEOPTS gesetzt werden, dann nimmt portage den Wert, den

Code: Select all

nproc

ausgibt.

ManfredB · Post by **ManfredB** » Tue May 24, 2022 2:09 pm

Vielen Dank für die Aufklärungen.

Nach diesen Berechnungen werde ich mit meinem Sohn sprechen, ob wir den RAM-Speicher von 32 auf 64 erhöhen.

Nur dann können wahrscheinlich solche Probleme wie mit qtwebengine nicht mehr auftreten.

Aber dieser Plan wird etwas Zeit brauchen, denn mein Sohn hat im Moment sehr viel zu tun in seinem Beruf,
da will ich ihn nicht noch zusätzlich belasten.
Wenn er mal wieder ein paar Stunden oder einen Tag frei hat, lässt sich das besprechen und möglicherweise auch realisieren.

Noch einmal herzlichen Dank.

Gruß
Manfred

PS: nproc hat eben 32 ausgegeben.

Post by **asturm** » Tue May 24, 2022 2:15 pm

ManfredB wrote:Nur dann können wahrscheinlich solche Proble wie mit qtwebengine nicht mehr auftreten.

Wer LibreOffice, Firefox und qtwebengine gleichzeitig in einem tmpfs kompiliert wird bei -j24 auch mit 64GB nicht genug haben.

Nicht dass das von Haus aus eine gute Idee ist, aber es kann vorkommen wenn man sich nicht überlegt welche Einstellungen man mit den vorhandenen Ressourcen vornehmen kann.

Christian99 · Post by **Christian99** » Tue May 24, 2022 2:25 pm

Josef.95 wrote:Wenn keine MAKEOPTS gesetzt werden, dann nimmt portage den Wert, den
Code: Select all
nproc
ausgibt.

danke, man lernt nie aus. ich hab wenn benötigt immer den output von lscpu geparsed, aber nproc sieht doch irgendwie einfacher aus

mike155 · Post by **mike155** » Tue May 24, 2022 2:56 pm

Josef.95 wrote:Jo, mit der fetten
Code: Select all
CPU: 16-core model: AMD Ryzen 9 5950X
CPU mit 16 Kernen plus 16 threads hat man dann 32 logische Prozessoren,

Wer schlau ist, macht ein paar Tests - und misst die emerge-Zeiten für Pakete wie Glibc oder GCC o.ä. mit 4, 8, 12, 16, 20, 24 und 32 CPUs.

Man wird vermutlich feststellen, dass die Emerge-Zeiten deutlich sinken, wenn man von 4 auf 8 oder auf 16 CPUs geht. Wenn man dann weiter erhöht, wird es aber nicht mehr viel schneller. Vielleicht wird es noch etwas schneller, wenn man von 16 auf 20 CPUs geht. Aber ich wage zu bezweifeln, dass man noch eine Geschwindigkeitssteigerung sieht, wenn man man von 24 auf 32 CPUs geht. Also kann man es auch sein lassen.

Nach diesen Berechnungen werde ich mit meinem Sohn sprechen, ob wir den RAM-Speicher von 32 auf 64 erhöhen.

Die richtige Lösung ist, nicht mehr Jobs laufen zu lassen, als man Kerne hat - im Falle einer einer AMD Ryzen 9 5950X CPU also 16. Dann braucht man auch keine 64GB RAM. Wenn man Lust und Zeit hat, kann man ein paar Tests machen und die Jobs noch etwas erhöhen. Aber nur, wenn man auch wirklich eine nennenswerte Geschwindigkeitssteigerung sieht.

Anmerkung: ich verwende für Sockets (Sockel), Cores (Kerne), CPUs und Threads die Nomenklatur von Intel, also: # CPUs = # sockets * # cores per socket * # threads per core

ManfredB · Post by **ManfredB** » Tue May 24, 2022 3:23 pm

Ich bin sehr froh, daß über diese Angelegenheit diskutiert wird,
denn auch ich lerne immer wieder etwas dazu.

Bisher hatte ich MAKEOPTS auf -j8 eingestellt. Macht es Sinn, auf -j16 zu gehen ohne Erhöhung des RAM-Speichers?

Nur noch eine kleine Anmerkung dazu: qtwebengine habe ich nur einmal versucht, bisher aber nie.

Libreoffice ist auch so ein dickes Programm, aber ich nutze dieses nur unter stable: Libreoffice-bin.
Das ist dann längst nicht so dick.

Testen werde ich nun einmal das, was ich hier alles gelesen habe.

Vielen Dank euch allen, die ihr hier geantwortet habt.

Gruß
Manfred

mike155 · Post by **mike155** » Tue May 24, 2022 3:58 pm

Macht es Sinn, auf -j16 zu gehen ohne Erhöhung des RAM-Speichers?

Ja. Wenn der pre-merge Check ausfehlert, gehe auf -j15 oder -j14.

Und auch mit mehr Speicher macht es keinen Sinn, deutlich mehr als 16 Jobs laufen zu lassen, weil Du nur 16 Kerne hast.

Ich persönlich würde übrigens Hyperthreading/SMT im BIOS ausschalten. Dann hat das System 16 Kerne und 16 CPUs - und gut ist.

Marlo · Post by **Marlo** » Tue May 24, 2022 8:12 pm

ManfredB wrote: MAKEOPTS aktiviert: "-j8"

AAAhhhh, da wird über diese Einstellung in make.conf dauerhaft ein € 573,27 Teil zu einem
€ 99,98 Teil runtergestuft. Das tut weh.

Also ich bin ja eher ein Fan vom Gentoo Wiki https://wiki.gentoo.org/wiki/MAKEOPTS .
Und ein noch größerer Fan vom weiterblättern. https://wiki.gentoo.org/wiki/Knowledge_ ... er_package
Und weiterblättern https://wiki.gentoo.org/wiki//etc/porta ... t_location

Ich übersetze mal den Inhalt der vielen Links für diesen konkreten Fall:

Code: Select all

mkdir -p /etc/portage/env
echo 'MAKEOPTS="-j16 -l15"' >> /etc/portage/env/makeopt-j16
echo 'dev-qt/qtwebengine  makeopt-j16' >> /etc/portage/package.env

Und schon wird die Leistungsfähigkeit der CPU nur für diesen einen Fall mit qtwebengine herabgesetzt. Ansonsten bleibt alles beim alten.

Natürlich kann man das auch mit anderen Programmen machen. Oben hatten wir noch clang mit Faktor 1,5.
D.h. 32 ./. 1,5 = 21,333~ gerundet 21.
daraus wird dann:

Code: Select all

echo 'MAKEOPTS="-j21 -l20"' >> /etc/portage/env/makeopt-j21
echo 'sys-devel/clang makeopt-j21'  >> /etc/portage/package.env

Aber das ist ja nur eine von mir geäußerte Einzelmeinung ohne Anspruch auf irgendwas. Man kann natürlich zur Problemlösung auch Zaubern, oder seine Daten auf USB-Sticks hin und her kopieren bis es "läuft". Oder alles neu installieren. Ja ich glaube das ist eine gute Idee.
Neuinstallation!

mike155 · Post by **mike155** » Tue May 24, 2022 8:19 pm

Marlo wrote:Oder alles neu installieren. Ja ich glaube das ist eine gute Idee. Neuinstallation!

Windows: Reboot tut immer gut!
Gentoo: Neuinstallation! Dann wird das schon!

Marlo · Post by **Marlo** » Tue May 24, 2022 8:23 pm

mike155 wrote:
Windows: Reboot tut immer gut!

Gentoo: Neuinstallation! Dann wird das schon!

Wow. Ich wusste gar nicht dass du dichten kannst.
Toll

Josef.95 · Post by **Josef.95** » Tue May 24, 2022 9:10 pm

@Marlo @mike155
Puh, könnt ihr hier im Support-Forum nicht bitte mal mit diesen von oben herablassenden Bullshit aufhören …
sowas hilft doch niemanden weiter.

Danke.

mike155 · Post by **mike155** » Tue May 24, 2022 9:43 pm

Josef.95 wrote:Puh, könnt ihr hier im Support-Forum nicht bitte mal mit diesen von oben herablassenden Bullshit aufhören …

Ich weiß nicht, was Du willst: hier und hier habe ich zwei sehr ordentliche Antworten gegeben.

Post by **pietinger** » Tue May 24, 2022 10:00 pm

Marlo wrote:AAAhhhh, da wird über diese Einstellung in make.conf dauerhaft ein [...] zu einem [...] runtergestuft. Das tut weh.

Ja, mir auch. Ebenso kann ich die Empfehlung Hyperthreading/SMT auszuschalten nicht nachvollziehen.

Marlo wrote:Also ich bin ja eher ein Fan vom Gentoo Wiki [...]

Ja, ich auch ! ...

... und habe deshalb das halbe (ich übertreibe natürlich) Gentoo-Wiki in meinem dt. Guide verlinkt:

viewtopic-p-8595924.html#8595924

(Ich weiß, dass einige User lieber deutsch als englisch lesen, deswegen dieser Link)

Natürlich bin ich der vollkommenen Überzeugung, dass meine Erläuterung am einfachsten ist

@Josef.95

Danke für Deine stoppenden Worte !

@alle:

Die Grenze zwischen Witzigkeit und Sarkasmus ist fließend ... und manchmal nicht genau auszumachen. Worüber ich noch lachen würde, könnten andere bereits anders einordnen ... Ich habe als Mod hier nicht reagiert, weil mein Humor (vielleicht zu) weitreichend ist und ich es deshalb als nicht böse eingestuft habe. Vielleicht liegt es auch daran, dass ich bei Euch "alten Gentoo-Hasen" immer erstmal vom Besten ausgehe.

Leute ... wir sind doch eine tolle und freundliche deutsche Community mit hochkompetenten Koryphäen ... und ich mag Witzigkeit ...

Liebe Grüße an alle,
Peter (in meiner privat-Eigenschaft und nicht als Mod)

mike155 · Post by **mike155** » Tue May 24, 2022 10:07 pm

An dieser Stelle darf ich noch auf diesen Thread verlinken: viewtopic-p-8605491.html

Das hatten wir nämlich alles schon mal diskutiert!

Josef.95 wrote:Manfred, (bez. Notebook)
so als Faustformel braucht man etwa 2GB RAM pro CPU-Kern/Thread zum Pakete bauen.
Sprich, mit deiner i5-7200U CPU, mit 2 Kernen plus zwei Threads (=4 Threads insgesamt) mal 2GB sollten die 8GB RAM idR gut ausreichen,
sprich MAKEOPTS="-j4" sollte mit den 8GB RAM gut funktionieren.

Aber auch hier würde ich EMERGE_DEFAULT_OPTS="--jobs=2" eher rausnehmen. Beachte, für zwei emerge Jobs, die beide gleichzeitig mit MAKEOPTS="-j4" bauen können,
kommt man dann auf insgesamt -j8
(für 8 Jobs mit je 2GB RAM bräuchte es also dann schon 16 GB RAM - und die hast du nicht)
Vorschlag: Lasse auf dem Notebook die
MAKEOPTS="-j4"
und tausche im EMERGE_DEFAULT_OPTS=--jobs=2 gegen --quiet-build=y
Ich denke das sollte gut funktionieren

Post by **pietinger** » Tue May 24, 2022 10:15 pm

mike155 wrote:An dieser Stelle darf ich noch auf diesen Thread verlinken: viewtopic-p-8605491.htm

Das hatten wir nämlich alles schon mal diskutiert!

Ja, Mike, das war letztes Jahr ... wir beide - zusammen mit allen anderen alten Gentoo-Hasen - wissen doch, dass manchmal User (nach eigenen Aussagen) noch älter sind als wir ... und auch ein bischen vergesslich ... deshalb: Verlinken - tut niemals stinken

Bei Deinem Link, fehlt auch noch das letzte "L" ...

mike155 · Post by **mike155** » Tue May 24, 2022 10:37 pm

pietinger wrote:Ebenso kann ich die Empfehlung Hyperthreading/SMT auszuschalten nicht nachvollziehen.

Es war nicht unbedingt eine Empfehlung, sondern ich habe geschrieben, dass ich das so mache.

mike155 wrote:Ich persönlich würde übrigens Hyperthreading/SMT im BIOS ausschalten. Dann hat das System 16 Kerne und 16 CPUs - und gut ist.

Ich mache das tatsächlich auf den meisten meiner Rechner so.

Wenn man das verstehen will: schnappt Euch ein Paket wie GCC und messt die Kompilierzeiten für unterschiedliche Anzahl von Jobs. Auf vielen (den meisten?) Systeme ist es so, dass die Kompilierzeiten nicht mehr schneller werden, wenn man Hyperthreading/SMT eingeschaltet hat und die Anzahl der Kerne (nicht: CPUs) deutlich überschreitet. Ich habe auch bei einigen Systemen festgestellt, dass Turbo Boost weniger gut funktioniert, wenn Hyperthreading/SMT eingeschaltet ist.

Abgesehen davon, dass Hyperthreading/SMT keine wirklich neuen CPUs bringt, ist es auch so, dass die Leistungsfähigkeit der Chips durch den Energieverbrauch beschränkt ist. Wenn 16 Kerne bereits das Wärmebudget ausschöpfen, dann kann das System nicht mehr schneller werden, wenn man Hyperthreading/SMT einschaltet.

Es gibt noch weitere Gründe, Hyperthreading/SMT nicht einzuschalten - aber das würde an dieser Stelle zu weit führen.

Post by **pietinger** » Tue May 24, 2022 11:08 pm

Vorab: Ich bin sicher, alles was ich jetzt ausführe ist den meisten bekannt. Ich habe es für alle anderen geschrieben.

mike155 wrote:Es gibt noch weitere Gründe, Hyperthreading/SMT nicht einzuschalten - aber das würde an dieser Stelle zu weit führen.

Ich kenne mindestens einen weiteren: Es ist sicherer. Dies wird m.M. aber eher an Servern benötigt die virtuelle Maschinen untrusted Leuten zur Verfügung stellen (außerdem haben die letzten Kernel-Versionen einen Teil davon wieder eingefangen).

mike155 wrote:Wenn man das verstehen will: schnappt Euch ein Paket wie GCC und messt die Kompilierzeiten für unterschiedliche Anzahl von Jobs. Auf vielen (den meisten?) Systeme ist es so, dass die Kompilierzeiten nicht mehr schneller werden, wenn man Hyperthreading/SMT eingeschaltet hat und die Anzahl der Kerne (nicht: CPUs) deutlich überschreitet. Ich habe auch bei einigen Systemen festgestellt, dass Turbo Boost weniger gut funktioniert, wenn Hyperthreading/SMT eingeschaltet ist.

Wenn man die Anzahl der gleichzeitig ablaufenden Compilier-Jobs um die der logischen Kerne auch nur um einen überschreitet, wird alles wieder langsamer - völlig korrekt (getestet mit verschiedenen CPUs; steht auch in meiner Anleitung).

Dass der Turbo Boost auf Max zurückgeht wenn alle logischen Kerne ausgelastet sind ist auch völlig normal. Ja, es sind keine echten Kerne, sondern ein physikalischer Kern bearbeitet mal die eine Seite, dann die andere ... und zwar genau dann, WENN er auf etwas warten muß und deshalb eh' nichts machen kann: Warten auf einen Speicher-Zugriff (natürlich wechselt er auch nach einer best. Zeit automatisch). Weil die heutigen CPUs um soviel schneller sind, als man die Daten vom Hauptspeicher zur CPU kopieren kann, warten heutige CPUs einen Großteil darauf, daß endliche wieder neue Daten zur ihr gelangen (trotz Level-1 und -2 und -3-Cache; die das ganze abmildern aber nicht verhindern können). Deswegen hatte man die Idee, daß ein physikalischer Kern doch eigentlich zwei Programme quasi-gleichzeitig abarbeiten kann ... und das stimmt auch und erhöht die Leistung. Zwar nicht um 100 % aber immerhin um irgendetwas zwischen 40 und 70 %.

mike155 wrote:[...] ist es auch so, dass die Leistungsfähigkeit der Chips durch den Energieverbrauch beschränkt ist. Wenn 16 Kerne bereits das Wärmebudget ausschöpfen, dann kann das System nicht mehr schneller werden, wenn man Hyperthreading/SMT einschaltet

Was den Energieverbrauch betrifft, gilt dies nur für Notebooks ... wir alle kennen doch "Marketing" ... bei Desktops gilt dies nicht. Was die Abwärme betrifft: Hier ist natürlich entscheidend, genügend Wärme abzuführen (nein, ich will jetzt nicht über Wasser-Kühlung contra konventioneller Luft-Kühlung sprechen). WENN die CPU wegen ungenügender Kühlung throtteln muß, dann bringt SMT natürlich weniger (bis hin zu Null) ... dies sollte aber bei einem Desktop (oder Server) nicht der Fall sein.

P.S.: Ich habe an meinem Intel 8-Kerner den Wert "-j4" eingestellt (trotz 16 GB) ... weil ... ich meine Updates in der Nacht laufen lasse, wo es mich nicht interessiert, wie lange die laufen. Wenn man aber auf einen emerge wartet, kann ich schon verstehen, daß man da mit Höchst-Geschwindigkeit fahren will ...

SMT ist bei mir aber eingeschaltet ... weil ... meine Schach-Engine (Stockfish) dann halt schneller analysiert (getestet).

mike155 · Post by **mike155** » Wed May 25, 2022 1:51 am

pietinger wrote: Zwar nicht um 100 % aber immerhin um irgendetwas zwischen 40 und 70 %.

Solche Beschleunigungen habe ich noch nicht gemessen.

Hier sind die Messwerte von meinem Desktop Rechner mit einer AMD Ryzen 7 5700G CPU mit 8 Kernen:

Code: Select all

+-----------------------------------------+----------+----------+----------+
| MAKEOPTS="-jN"                          |     8    |    12    |    16    |
+-----------------------------------------+----------+----------+----------+
| SMT aus (8 Kerne, 8 CPUs), emerge glibc |   120 s  |   119 s  |          |
| SMT aus (8 Kerne, 8 CPUs), emerge gcc   |  1241 s  |  1247 s  |          |
+-----------------------------------------+----------+----------+----------+
| SMT an (8 Kerne, 16 CPUs), emerge glibc |   119 s  |   112 s  |   108 s  |
| SMT an (8 Kerne, 16 CPUs), emerge gcc   |  1223 s  |  1175 s  |  1121 s  |
+-----------------------------------------+----------+----------+----------+

Hyperthreading bringt hier eine Beschleunigung von 10%. Also, das lohnt sich nicht wirklich - und wenn man dann auch noch die doppelte Menge RAM dafür braucht...

Auf XEON- und EPYC-Servern habe ich bei emerge-Jobs etwas mehr Beschleunigung gemessen - aber keine 40-70%.

Falls jemand auf seinem Rechner andere Werte misst: bitte posten - das interessiert mich.

SMT ist bei mir aber eingeschaltet ... weil ... meine Schach-Engine (Stockfish) dann halt schneller analysiert (getestet).

Das glaube ich. Bei mathematischen Berechnungen mit Multithreading habe ich auch schon größere Effekte gesehen. Da gibt es wenig I/O, die Kerne führen denselben Code aus, Caches müssen nicht dauernd neu geladen werden, usw. Mit den Ergebnissen solcher Benchmarks werben auch die Prozessor-Hersteller... Aber das ist ein ganz spezielles Anwendungszenario.

P.S.: Ich habe an meinem Intel 8-Kerner den Wert "-j4" eingestellt (trotz 16 GB) ... weil ... ich meine Updates in der Nacht laufen lasse, wo es mich nicht interessiert, wie lange die laufen. Wenn man aber auf einen emerge wartet, kann ich schon verstehen, daß man da mit Höchst-Geschwindigkeit fahren will ...

Ich glaube, da hatten wir schon mal drüber gesprochen. Bei meinen Notebooks reduziere ich auch die Performance, damit der Lüfter leise bzw. aus bleibt und das Gerät nicht zu heiß wird. Das kann man über die Anzahl der Jobs machen. Noch besser geht es über die Maximalfrequenz - weil die Frequenz fast quadratisch in den Energieverbrauch der CPU eingeht (zum einen über die Anzahl der Schaltvorgänge pro Sekunde, zum anderen über die CPU-Spannung).

firefly · Post by **firefly** » Wed May 25, 2022 4:21 am

Kommt immer auf den Anwendungsfall an ob HT was bringt oder nicht. Deshalb ist eine allgemeine Aussage, dass HT nichts bringen immer falsch.
Denn nicht jeder Process/Thread lastet alle Elemente eines CPU Kerns komplett aus. z.b. Wenn ein Prozess nur Integer Berechnungen macht, dann ist die FPU des CPU Kerns nicht in Verwendung und kann dann von einem HT Thread verwendet werden.
Das ist das prinzipielle konzept, so wie ich es verstehe, hinter HT. Dass ein anderer Thread/Process die Teile eines CPU-Kerns nutzen kann wenn der aktuelle Thread/Process auf dem selben CPU-Kern diese Elemente des Kerns verwendet/auslastet.

Selbst beim Kompilieren von Software kann HT was bringen und zwar auch mehr als deine 10% @mike155.
Du selbst hast nur 2 Beispiele gebracht hast, wo es zu mindestens auf deinem System maximal 10% gebracht hat.
Und Daten von 2 Messungen haben keine signifikante Aussagekraft. Ganz besonders, da es nur auf einem System gemessen wurde.

mike155 wrote:Hyperthreading bringt hier eine Beschleunigung von 10%. Also, das lohnt sich nicht wirklich - und wenn man dann auch noch die doppelte Menge RAM dafür braucht...

Und hier wieder wird eine Messung für eine allgemeine Aussage verwendet. Der mehr am RAM verbrauch beim übersetzen von qtwebengine hat aber null mit HT zu tun!
Die Übersetzung würde auch mehr RAM brauchen wenn die Übersetzung statt auf einem 8 Kerner auf einem 16 Kerner (echte Kerne) laufen würde und dadurch statt 8 16 parallele jobs laufen würden.
Der mögliche RAM Verbrauch ist nur an die Anzahl der gleichzeitigen jobs gebunden!

mike155 wrote:
SMT ist bei mir aber eingeschaltet ... weil ... meine Schach-Engine (Stockfish) dann halt schneller analysiert (getestet).
Das glaube ich. Bei mathematischen Berechnungen mit Multithreading habe ich auch schon größere Effekte gesehen. Da gibt es wenig I/O, die Kerne führen denselben Code aus, Caches müssen nicht dauernd neu geladen werden, usw. Mit den Ergebnissen solcher Benchmarks werben auch die Prozessor-Hersteller... Aber das ist ein ganz spezielles Anwendungszenario.

Es ist kein spezielles Anwendungszenario das ist halt ein anderes Szenario. Das Problem ist, so kommt es mir zu mindestens so vor, dass du gerne mit allgemeinen Aussagen daher kommst welche sich aber auf Daten von wenigen Anwendungsfällen stützen.

PS: Aber selbst 10% Beschleunigung kann je nach Anwendungsfall schon massiv sein. z.b. Wenn eine Berechnung 20h braucht. Dann bedeutet eine 10% Beschleunigung (durch Verwendung von HT), dass die Berechnung 2h früher fertig ist! Und das ist dann eine signifikante Verbesserung.
Und diese Beschleunigung kommt dann quasi for free ohne das in neue Hardware investiert werden muss.