# USE-flag jumbo-build

## LuxJux

Welche emerges können das denn schon ? Ausser qtweb-engine

Vorausetzung: 8+ Gig Ram und sonst ?

----------

## asturm

Nein, funktioniert auch mit 2GB wenn MAKEOPTS keine unrealistischen Forderungen an die Hardware stellt.

```
$ euse -i jumbo-build

global use flags (searching: jumbo-build)

************************************************************

no matching entries found

local use flags (searching: jumbo-build)

************************************************************

[-      ] jumbo-build

    dev-qt/qtwebengine: Combine source files to speed up build process.

[-      ] jumbo-build

    dev-util/edb-debugger: Experimental jumbo (also known as unity) build capability

              0.9.21 [gentoo]

              1.0.0-r2 [gentoo]

        [-  ] 9999 [gentoo]

[-      ] jumbo-build

    www-client/chromium: Combine source files to speed up build process.

        [-  ] 78.0.3904.97 [gentoo]

        [-  ] 79.0.3945.29 [gentoo]

              80.0.3962.2 [gentoo]
```

----------

## LuxJux

bei clang oder gcc w're es hilfreich

debugger ist schon mal gut. Chromium gibts hier nicht

----------

## demiurg

Schöne Anregung mit dem jumbo-build

```

genlop -t qtwebengine

 * dev-qt/qtwebengine

     Sun Nov  3 00:37:24 2019 >>> dev-qt/qtwebengine-5.12.5

       merge time: 1 hour, 2 minutes and 5 seconds.

     Sat Nov 16 12:23:32 2019 >>> dev-qt/qtwebengine-5.12.5

       merge time: 30 minutes and 1 second.
```

Mit dem use-Flag hat sich die Bearbeitungszeit glatt halbiert. 

Noch eine Anmerkung zum Arbeitsspeicher. Wenn das Arbeitsverzeichnis von Portage als /tmp in den RAM gemountet wird

https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs

ist mit MAKEOPTS="-j32" (Ryzen 7 3700X) und 32 GB Ram so nach 2/3 Compilezeit Ende im Gelände. Da läuft dann Swap voll ( bei mir 2 GB) und der Vorgang bricht ab. Damit ist es das Paket ein notwendiger Kandidat für das temporäre Portageverzeichnis auf der Festplatte. Das läuft dann ohne Probleme. Die RAM-Benutzung für den Fall habe ich nicht ständig beobachtet - dürfte aber immer unter 4 GB liegen. Alternativ geht sicher auch die -j32 entsprechend zu verringern oder mehr "Hubraum (RAM)" .

Gruß

demiurg

----------

## toralf

 *demiurg wrote:*   

> Die RAM-Benutzung für den Fall habe ich nicht ständig beobachtet - dürfte aber immer unter 4 GB liegen.[/code] 

 Das Paket 

```
app-admin/sysstat
```

empfinde ich dafür recht hilfreich. Ich tue per cron 

```
@reboot   /usr/lib/sa/sa1 --boot

* * * * * /usr/lib/sa/sa1 1 1 -S XALL

```

und schaue mir dann auf dem Client angelegentlich die wichtigsten Daten seit Mitternacht als SVG Grafik mittels 

```
host=<snip>    ; svg=/tmp/graph.svg; rsync -aLv $host:/var/log/sa ~/tmp/sa/$host && sadf -g -T ~/tmp/sa/$host/sa/sa`date +%d` -O skipempty,oneday -- -m ALL -n ALL -q -u ALL -w -P 1 > $svg && falkon $svg
```

an.

----------

## mike155

 *demiurg wrote:*   

> MAKEOPTS="-j32" (Ryzen 7 3700X) und 32 GB Ram"

 

Laut https://www.amd.com/de/products/cpu/amd-ryzen-7-3700x hat der Ryzen 7 3700X 8 richtige Kerne und nochmal 8 zusätzliche "Pseudo" "Marketing-Gag" SMT-Kerne. Da ist "-j32" aus Performance-Sicht vermutlich zu hoch und damit suboptimal. Wenn SMT aktiviert ist, ist vermutlich "-j16" optimal.

Ich persönlich schalte SMT auf allen Maschinen aus (u.a. weil ich maximale Performance möchte) - und dann wäre vermutlich "-j10" optimal. Das wäre dann vermutlich schneller als aktiviertes SMT und "-j16" (reine Vermutung - ich habe bisher noch keine Performance-Messungen auf Ryzen-Prozessoren durchgeführt).

Das Problem mit den vielen parallel laufenden Jobs (32) ist:

das System wird langsamer, weil die vielen Jobs sich die Daten gegenseitig aus den diversen Caches werfen.

man benötigt viel mehr RAM. Sobald das System anfängt (massiv) zu swappen, ist die Performance endgültig ruiniert.

es wird schwierig, den Überblick zu behalten.Also, man kann qtwebengine als Testobjekt nehmen und das Paket mit 4,8,12,16,20,24 und 32 parallel laufenden Jobs emergen. Dann sieht man, wo das Optimum liegt. Ich vermute, dass die benötigte Zeit auf einem Ryzen 7 3700X System sich beim Übergang von 4 -> 8 halbieren wird, bis 16 noch etwas besser wird und danach wieder ansteigen wird.

----------

## l3u

Hieß doch damals mal für -j Anzahl der Kerne + 1, oder?

----------

## toralf

 *l3u wrote:*   

> Hieß doch damals mal für -j Anzahl der Kerne + 1, oder?

 Ich empfehle "-j <cpu -1>", also "-j 15" im obigen Fall bei genügend RAM, aber bei 8 GB wären m.E. "-j 8" schon sehr gewagt.

----------

## firefly

bezüglich jumbo build und qtwebengine ein hinweis aus einem anderen thread von mike155

 *mike155 wrote:*   

> Unglücklicherweise wurde das "Feature" "Jumbo/Unity-Builds" bei Chromium gerade entfernt. Siehe: https://forums.gentoo.org/viewtopic-p-8388710.html#8388710
> 
> Dann wird's das bei qtwebengine auch nicht mehr lange geben...

 

----------

## demiurg

 *mike155 wrote:*   

>  *demiurg wrote:*   MAKEOPTS="-j32" (Ryzen 7 3700X) und 32 GB Ram" 
> 
> Laut https://www.amd.com/de/products/cpu/amd-ryzen-7-3700x hat der Ryzen 7 3700X 8 richtige Kerne und nochmal 8 zusätzliche "Pseudo" "Marketing-Gag" SMT-Kerne. Da ist "-j32" aus Performance-Sicht vermutlich zu hoch und damit suboptimal. Wenn SMT aktiviert ist, ist vermutlich "-j16" optimal.
> 
> Ich persönlich schalte SMT auf allen Maschinen aus (u.a. weil ich maximale Performance möchte) - und dann wäre vermutlich "-j10" optimal. Das wäre dann vermutlich schneller als aktiviertes SMT und "-j16" (reine Vermutung - ich habe bisher noch keine Performance-Messungen auf Ryzen-Prozessoren durchgeführt).
> ...

 

Ich habe mal etwas Zeit investiert, um zu schauen was die Fakten liefern. SMT bleibt an - also 16 Threads bei 8 Kernen und /tmp/portage lag immer auf Platte, 32 GB RAM. Ccache und ähnliche Geschichten sind nicht aktiv. RAM max ist der Wert, der während des compilierens im Systemmonitor aufgetreten ist.

-j4      cpu 25%     Ram max 5,5 GB     genlop 1h:4min:43s

-j8      cpu 50%     RAM max 8,1 GB     genlop 36min:08s

-j12    cpu 75%     RAM max 12,6 GB   genlop 31min:09s

-j16    cpu 100%   RAM max 13 GB      genlop 27min:48s

-j32    cpu 100%   RAM max 29 GB      genlop 29min:29s

Damit ist  in der make.conf jetzt -j16 für mich die Einstellung der Wahl. Danke an mike155 für die Anregung.

Gruß

demiurg

----------

## mike155

 *demiurg wrote:*   

> -j4      cpu 25%     Ram max 5,5 GB     genlop 1h:4min:43s
> 
> -j8      cpu 50%     RAM max 8,1 GB     genlop 36min:08s
> 
> -j12    cpu 75%     RAM max 12,6 GB   genlop 31min:09s
> ...

 

Toll, dass Du diese Tests gemacht hast! Wenn man Performance will, ist das meiner Erfahrung nach auch die einzig funktionierende Methode: testen, testen, testen - bis man das Optimum hat!

Es wäre schön, wenn Du noch einen weiteren Test durchführen könntest. Das Ergebnis würde mich sehr interessieren:

Im BIOS/UEFI Setup SMT deaktivieren. Falls das nicht möglich sein sollte, kann man Linux auch mit dem Boot-Parameter "nosmt=force" starten.

Am System selbst muss nichts geändert werden.  :Smile: 

Nach dem Neustart bitte mit "lscpu" überprüfen, dass SMT wirklich deaktiviert ist

Einen Test mit "-j 10" durchführen und die Zeit messen

Falls Du Lust hast, auch noch einen Test mit "-j 8" und "-j 12" durchführen

Hinterher SMT wieder einschalten - wenn Du es haben möchtest.

----------

## demiurg

Etwas Wasser in den Wein

SMT mit der Kerneloption ausgeschaltet und mit lscpu geprüft 

```

Architektur:                   x86_64

CPU Operationsmodus:           32-bit, 64-bit

Byte-Reihenfolge:              Little Endian

Adressgrößen:                  43 bits physical, 48 bits virtual

CPU(s):                        16

Liste der Online-CPU(s):       0-7

Liste der Offline-CPU(s):      8-15

Thread(s) pro Kern:            1

Kern(e) pro Socket:            8

Sockel:                        1

Anbieterkennung:               AuthenticAMD

Prozessorfamilie:              23

Modell:                        113

Modellname:                    AMD Ryzen 7 3700X 8-Core Processor

Stepping:                      0

CPU MHz:                       3622.644

Maximale Taktfrequenz der CPU: 3600,0000

Minimale Taktfrequenz der CPU: 2200,0000

BogoMIPS:                      7186.65

Virtualisierung:               AMD-V

L1d Cache:                     32K

L1i Cache:                     32K

L2 Cache:                      512K

L3 Cache:                      16384K

Markierungen:                  fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate sme ssbd mba sev ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif umip rdpid overflow_recov succor smca
```

Jetzt kommts

-j10 CPU 100%  RAMmax 11GB  genlop 35min59s

Damit ist Multithreading mit etwas mehr RAM-Inanspruchnahme erstmal im Vorteil. Für die beiden anderen Optionen muss ich mal schauen, ob nächstes WE dafür Zeit ist.

Gruß

demiurg

----------

## mike155

 *demiurg wrote:*   

> 
> 
> ```
> mit  SMT: -j16 CPU 100% RAM max 13 GB genlop 27min:48s 
> 
> ...

 

Danke für den Test! Das ist natürlich ein schönes Ergebnis! Beim Ryzen 7 3700X scheint SMT tatsächlich einen ordentlichen Leistungszuwachs zu bringen.  :Smile: 

----------

## demiurg

Zum Abrunden

SMT ausgeschaltet

-j12 CPU 100% RAMmax 12 GB  genlop 36min:34s

SMT eingeschaltet und Compiling komplett im RAM anstelle auf "Platte" NVMe PCIE3.0x4

-j16 CPU 100% RAMmax 15,9 GB genlop 27min:37s

zur Erinnerung mit Hilfe NVMe SSD

-j16 CPU 100% RAMmax 13 GB genlop 27min:48s

Also Zusammenfassung über alles

SMT mit -j16 ist beim Ryzen 7 3700x das Optimum

und wer eine SSD NVMe PCIe 3.0x4 als Puffer nimmt, wenn der RAM nicht reicht, hat keinen wirklichen Nachteil gegenüber einer kompletten /var/tmp/portage im RAM.

Mushkin Pilot-E 500 GB ist die M.2 SSD und Speicher ist Corsair DIMM 32GB DDR4-3000 Kit CL15 17-17-35 und ich habe in der fstab eingetragen

https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs

/var/tmp/portage	tmpfs	size=24G,uid=portage,gid=portage,mode=775,noatime	0 0

----------

## firefly

 *demiurg wrote:*   

> 
> 
> SMT mit -j16 ist beim Ryzen 7 3700x das Optimum
> 
> und wer eine SSD NVMe PCIe 3.0x4 als Puffer nimmt, wenn der RAM nicht reicht, hat keinen wirklichen Nachteil gegenüber einer kompletten /var/tmp/portage im RAM.
> ...

 

Wobei diese Aussage jetzt nur für den von dir verwendeten RAM Riegel gilt. Laut dieser Folie von AMD

https://www.cgdirector.com/wp-content/uploads/media/2019/08/AMD-3rd-gen-ryzen-memory-latency-768x432.jpg

(Quelle: https://www.cgdirector.com/best-memory-ram-amd-ryzen-cpus-3600-3700x-3900x/)

Sind DDR4-3600 am besten was die Performance per price sind.

Da könnte ich mir vorstellen, dass reines in RAM bauen dann noch schneller ist.

Denn die RAM "Zugriffperformance" der 3rd Gen Ryzens ist stark von der Taktfrequenz er RAM module abhängig.

----------

## demiurg

@firefly

Da habe ich jetzt leider keinen Sponsor das zu testen. 

Allerdings glaube ich nicht, dass der Einfluss gravierender ist, als die Skalierung mit einem guten -jxx Parameter. Auf die letzte Sekunde kommt es dann für den Hausgebrauch m.E. nicht an.

Gruß

demiurg

----------

