„Ha egy procis géped van, akkor csak a -j1 (vagy a -j elhagyása) a leggyorsabb, mert a több aktívan futó szál rendszeresen üríti a gyorstárat, ezért sokkal több a fő memóriából történő olvasás (10-100x lassabb mint a gyorstár).”
Ez akkor 100%-ig igaz, ha mást nem kalkulálsz bele. (Merevlemez milliárdx lassabb…)
Így aztán – egy gyorsabb cpu-nál – előfordul, hogy a cpu „pihen”.
Én észrevettem – nálam -, hogy 1 szál alkalmazásánál a cpu a legritkább esetben dolgozik 100%-kal. Nyílván – tökéletesen igazad van – 2 szál esetében a hatásfok rosszabb lesz, de a kihasználtság esetleg jobb. (Persze a franc tudja, hogy hogy osztja ki a feladatokat a make. Ha rosszul csinálja, akkor a visszájára is elsülhet…)

Egyébként a teoretikus sebesség így néz ki, ha valakit érdekel:
S = =1/(N_szál+(1-N_szál)/N_cpu)
(Amdahl’s tv. egyébként.)
Ez a teoretikus… ebben a fent említett problémák feloldásai nem szerepelnek.

Teszteltem egyet. A lassabb gyorsabb lett. Egy lefordított progin a ccache újrafordítás sebességét mértem (semmit sem fordított a gcc). Lassabb lett a feldolgozás 2 szálon 3 másodperccel (real), de összességében 25 másodpercet lehetett nyerni az átfedésekkel (real). Ez azért nem jellemző, a ccache-nek sokkal nagyobb a lemezforgalma, mint egy gcc fordításnak. Most nincs időm ccache nélküli fordítási időket összehasonlítani.

-j1:

-j2:

„Ez akkor 100%-ig igaz, ha mást nem kalkulálsz bele. (Merevlemez milliárdx lassabb…)”
Így igaz. De egy viszonylag egyszerű magyarázatba több nem fért bele. Amit írtam az mindíg érvényes, kivétel nélkül. Úgy tippelem, hogy a két hatás (gyorstár csökkenés+lemez olvasási átfedés) egy teljes C++ fordításnál (nincs ccache) nagyjából kiolthatja egymást.

„Persze a franc tudja, hogy hogy osztja ki a feladatokat a make. Ha rosszul csinálja, akkor a visszájára is elsülhet…”
Hát, az összes ‘make -C’ sopompóként működik, bevárja az összes szál végrehajtását. Azaz a sok alkönyvtár lassítja a párhuzamos fordítást.