# multi merge

## Treborius

hallo,

ich erinnere mich dunkel, das es mal einen thread hab, wo ein tool

vorgestellt wurde, was mit portage bord-mitteln den emerge vorgang in

mehere teile zerlegte (sowas wie einen thread pro ast im dep-tree)

1. finde ich den thread nicht mehr

2. hat jemand damit erfahrungen (für mich klingt das super und einleuchtend)

weil ich sitze hier gerade an nem quadcore nach einem jahr ohne internet,

und 170 pakete updaten macht irgendwie nicht den grössten spass  :Smile: 

----------

## py-ro

In den neuen Portage Version gibt es das als Feature, ist aber leider noch nicht im stable drin  :Wink: 

Py

----------

## Max Steel

Eventuell meintest du dashier:

https://bugs.gentoo.org/show_bug.cgi?id=147516

Ob es in Portage-2.2:

```
# emerge --help -v

[...]

       --jobs [JOBS] (-j short option)

              Specifies the number of packages to build simultaneously. If

              this option is given without an argument, emerge will not

              limit the number of jobs that can run simultaneously. Also

              see the related --load-average option.

[...]
```

Eventuell meinst du ja diese Option?, leider verstehe ich im Moment nicht so was da wirklich steht  :Laughing: 

----------

## obrut<-

das kannte ich noch nicht.

ich machs mit MAKEOPTS="-j5" in der make.conf.  damit werden aber nicht mehrere pakete parallel kompiliert, sondern make startet mehrere prozesse bei der kompilierung. das führt dazu, dass z.b. mehrere gcc-instanzen parallel am selben paket arbeiten oder auch andere von make angestoßen prozesse aktiv werden. auf gleiche art und weise kann man auch die kompilierung eines kernels beschleunigen (make -j5 statt make). die anzahl der jobs sollte anzahl der kerne (inkl "emulierter" kerne, aka smt) +1 sein. wenn das system aber zu wenig ram hat, kanns in die hose gehen, da dadurch der ram-bedarf ansteigt. bei einigen pakete funzt dieser ansatz aber nicht, da das ebuild diese option filtert.

----------

## SvenFischer

... wenn make denn überhaupt mehrere Instanzen an gcc übergibt. Das ist nicht immer so und auch skaliert es weniger gut.

Ich glaube es geht hier hauptsächlich darum, das einige Pakete parallel kompiliert werden, ob sich dann das einzelne Paket wiederrum mitels -jX verteilt wird ist sekundär.

----------

## py-ro

Wobei man aufpassen muss,

--jobs x

und 

-jy

sind im schlimmstenfall x*y Prozesse.

Da lohnt sich dann distcc endlich mal wieder.

Allerdings bringt --jobs im Alltag relativ wenig, bei der Installation von mehreren Zweigen oder Empty World schon eher.

Py

----------

## obrut<-

das, was ich vorgeschlagen hab, funzt auch mit älteren portage-versionen und bei installationen einzelner pakete, daher hab ichs geschrieben. die skalierung ist natürlich nicht perfekt, da, wie schon erwähnt, make nicht immer mehrere jobs startet und auch z.b. configure als einzelner job läuft und so nicht beschleunigt werden kann. die restlichen kerne haben dann nichts zu tun.

die kombination aus -jx und -jobs kann in der tat arg in die hose gehen. da muss man schon aufpassen und mit einer art lastgrenze arbeiten (wie oben bereits in der ausgabe von emerge --help zu lesen).

----------

