Milyen pc konfigurációt javasoltok ha arra akarom összerakni, hogy minél gyorsabban fordítson forráskódot?

Na ami lehet?

> Processzor órajel?

igaz befolyásolja, de nincs tényleges lineáris kapcsolat a fordítási idő és az órajel között. Amúgy a mai piacon a CPU-k 90%-a 2.8-3.2 GHz között mozog ez a fizikai plafon. Esetleg a cache méret az mi inkább meghatározza, de ott sincs sok különbség.

Mondjuk az Intel fordítója egész jól kihasználja a saját processzorait.

> És a magok száma?

A fordítást nagyon kevés fordító párhuzamosítja. Egyedül a precompiler az amit lehet inkonzisztensen futtatni fájlokra. A fordítás kb 10% ha párhuzamosítható.

> Az SSD az alap tartozék, nem?

Az SSD alap, hiszen minden fordítás előtt ment az IDE, hiszen a fordító egy külön programként fut. Valójában azonban nem az IO a szűk keresztmetszet. A kimeneten létrejövő össze nem linkelt tárgykódok igénylenek némi IO kapacitást, de szinten elenyésző.

> Akkor mi?

Memória, memória és memória!

Egy jó fejlesztői gépben még 10 éve és volt 4 GB memória, ami akkor kuriózum volt. Manapság egy build szerver 16 GB dolgozik. Nagyobb fejlesztői gárdánál ez annyira centralizált, hogy a fejlesztői gépek olcsó munkaállomások, ahol unitteszteket írsz és csak komponenseket debuggolsz. A build szerver pedig minden nap végén lefordítja a teljes kódbázist és mindnen unittesztet elvégez.

Azért az én munkaállomásomban nagyon jó helyen van az 8GB memória. Tegyük hozzá, nem elég a memória mérete, a sebessége sem elhanyagolható tényező, de nagyon nem: Nem mindegy, hogy egy 3GHz körüli órajellel dolgozó processzornak egy 800MHz-en, vagy 1333MHz-en kereplő memóriára kell várnia.

A build szervereket azért ne keverjük ide, mert egészen más performanciával jár valami build toollal, continuous integration szoftverrel forgatni a kódot, mint Visual Studio alatt megnyomni a Ctrl+F5-öt, arról nem is beszélve, hogy a két dolog kontextusa is teljesen más. Nem igazán lehet összehasonlítani. Ha egy build szervernek 10 percébe kerül átrágnia magát a kódon és a unit teszteken, aztán jelenteni az esetleges problémákat, az egy teljesen elfogadható eredmény, míg ha az IDE-ben csapok rá a "Compile and run" -ra (ami amúgy lassabb), akkor nem szeretnék 10 percet malmozni, mire beforog - arról nem is beszélve, hogy ha így van, lőttek a TDD-nek.

Mellesleg azért az az IO sem olyan elhanyagolható kérdéskör. Amikor a fizikai memória elfogy, akkor az OS előveszi a lapozófájlt (oké, nem akkor, de ebbe most ne menjünk bele). A lapozófájlt pedig a lemezen találja, amire baromi sokat kell várni, még akkor is, ha SSD, ha meg nem az, akkor baj van. Ilyenkor jönne nagyon jól, ha szépen párhuzamosítva lenne a fordítás, mert amíg az egyik szál a lemezen nézelődik (DMA of course), valaki más rágcsálhatja az épp rábízott adatokat. Ez azonban a compilerekre nem igazán jellemző.

Ha ökölszabályt szeretne a kedves kérdező, akkor csak megerősíteni tudom az első válaszolót: Minél több, és minél gyorsabb memória, hozzá pedig 64 bites oprendszer (of course).