nproc udává počet dostupných jader CPU/vlákna, např. 8 na čtyřjádrovém CPU s podporou obousměrného SMT.
Počet úloh, které můžete spustit paralelně s make pomocí -j možnost závisí na řadě faktorů:
- množství dostupné paměti
- množství paměti použité každým
makepráce - do jaké míry
makeúlohy jsou vázané na I/O nebo CPU
make -j$(nproc) je slušné místo, kde začít, ale obvykle můžete použít vyšší hodnoty, pokud nevyčerpáte dostupnou paměť a nezačnete mlátit.
Pro opravdu rychlé sestavení, pokud máte dostatek paměti, doporučuji použít tmpfs , tak bude většina úloh vázána na CPU a make -j$(nproc) bude fungovat co nejrychleji.
Nejjednodušší způsob je použít nproc takhle:
make -j`nproc`
Příkaz nproc vrátí počet jader na vašem počítači. Zabalením do klíšťat nproc příkaz se provede jako první, vrátí číslo a toto číslo bude předáno do make .
Možná máte nějaké neoficiální zkušenosti, kdy provedení počítání jader + 1 vede k rychlejší kompilaci. To souvisí spíše s faktory, jako jsou zpoždění I/O, zpoždění jiných zdrojů a další dostupnost omezení zdrojů.
Chcete-li to provést, použijte nproc+1 , zkuste toto:
make -j$((`nproc`+1))
Bohužel i různé části stejného sestavení mohou být optimální s konfliktními hodnotami faktoru j, v závislosti na tom, co se staví, jak, které ze systémových prostředků jsou v té době úzkým hrdlem, co se ještě děje na sestavení stroje, co se děje v síť (pokud používáte techniky distribuovaného sestavení), stav/umístění/výkon mnoha systémů ukládání do mezipaměti zapojených do sestavení atd.
Kompilace 100 malých souborů C může být rychlejší než kompilace jednoho velkého souboru nebo naopak. Vytváření malého vysoce spletitého kódu může být pomalejší než vytváření velkého množství přímočarého/lineárního kódu.
I na kontextu sestavení záleží – použití j faktoru optimalizovaného pro sestavení na dedikovaných serverech vyladěných pro exkluzivní, nepřekrývající se sestavení může přinést velmi neuspokojivé výsledky, pokud je používají vývojáři stavící paralelně na stejném sdíleném serveru (každé takové sestavení může trvat déle čas než všechny dohromady, pokud jsou serializovány) nebo na serverech s různými konfiguracemi hardwaru nebo virtualizované.
Je tu také aspekt správnosti specifikace sestavení. Velmi složité sestavení mohou mít závodní podmínky způsobující občasné selhání sestavení s četností výskytu, která se může výrazně lišit se zvýšením nebo snížením j faktoru.
Můžu pokračovat dál a dál. Jde o to, že musíte skutečně zhodnotit své stavět v samotném kontextu pro které chcete faktor j optimalizovat. Platí komentář @Jeffa Schallera:opakujte, dokud nenajdete, co vám nejlépe vyhovuje. Osobně bych začal od hodnoty nproc, zkoušet nejprve nahoru a dolů, pouze pokud pokusy nahoru ukazují okamžitou degradaci.
Možná by bylo dobré nejprve změřit několik identických sestavení v domněle identických kontextech, abyste získali představu o variabilitě vašich měření – pokud by byla příliš vysoká, mohla by ohrozit celé vaše úsilí o optimalizaci (20% variabilita by zcela zastínila 10% zlepšení/ čtení degradace při hledání j faktoru).
A konečně, IMHO je lepší používat (adaptivní) jobserver, pokud je podporován a dostupný, místo fixního j faktoru – konzistentně poskytuje lepší výkon při sestavování v širším rozsahu kontextů.