Programfordításhoz hardver?

Offtopic

Sziasztok,

szóval az offtopicban kötött ki a téma, de több mindenhez is kapcsolódik, nyilván.
Gondolkozgatok egy kis upgrade-en, és kíváncsi vagyok, kinek milyen tapasztalatai, tanácsai lennének.
Jelenleg egy Q6600, 8GB RAM (sajnos i975x chipset, több nem fér...), meg néhány hdd (JBOD) a gépem lényegi része. Sw: Solaris, Sun cc/CC. Elég sokat forgatok programot (igazából egyet, de az ezen a gépen 8-10 óra), és kíváncsi vagyok merre felé induljak el, ha gyorsítani szeretnék. A kód nagyrészt "heavily templated C++", ha ez segít.

SSD beszerzése? - néha elfogy a 8 GB ram, és 4-5 GB-t swappel, ez érthető módon lassítja a folyamatot, de nem végig ez a helyzet - viszont nyilván segítség lenne.
Core i7 upgrade? Fordítás alkalmával a hyper-threading mennyire segít? Segít egyáltalán? (kb i920-ig lehet keret, feljebb nem nagyon)
AMD 6 core upgrade? Jobb a több fizikai mag?

Igazából az optimális megoldás nyilván az ssd + új(abb) cpu + sok RAM lenne, de tegyük fel, hogy vagy SSD, vagy mobo+cpu bővítésre van keret :)

Még valami: elsősorban nem flame topicot szeretnék, nyilván, de vélemények is érdekelnek, amik néha lehetnek szubjektívek is.
Per pillanat álláspontom nincs (tehát vitákba bonyolódni nem szeretnék), és rábeszélni sem szeretném hagyni magam :) - még csak tervezgetek.

köszönöm

  • 1715 megtekintés

( GCS v | 2010. 08. 09., h – 14:21 )

Nekem E6600-am van (csak kétmagos, nem négy mint a Tiéd). 6 Gb RAM, Debian GNU/Linux az OS. Szoktam nagy dolgokat fordítani, de eddig egyszer sem volt RAM problémám. Mi az amiből binárist csinálsz?

Ha ugyanazt a programot fordítgatod, akkor biztos hogy nem változik túl nagy léptékben a forrása (nagyságából itélve).
Ezért nem vennék hardvert, inkább a ccache vagy hasonló megoldást használnék. Lennie kell(ene) Solaris-ra is.

(E6600 itthon van, nattyon finom cpu :))

A www.slicer.org-on található a szoftver, a múlt héten lett kész a Solaris portja (én tákoltam); a 3.6.1 már van x64 bináris formájában. Csak még nem hivatalos :)
(A "trunk" most készül majd, de ez soksoksok hákolást, meg (újra-) fordítgatást, igényel.)

ccache és mtsai: _ha_ jól tudom (nem biztos!, de mintha úgy emlékeznék) nem nagyon támogatják a Sun^W Oracle compilerét. Létezik dmake (=distributed make) Solarisra (úhy értem a Studio-val jön, saját cuccuk), de ahhoz kéne több gép, ami nem nagyon van - meg a hálózatunk is 100mbit, ami nem tudom ebben az esetben nem lenne-e szűk keresztmetszet.

Ez ez a kis aranyos mindenféle OS mindenféle compilerét elég rendesen kihajtja - igazából azért, mert az ITK-t (itk.org) használja. Nem is nagyon tudok 4 szálon fordítani, mert a compiler alegységei (ube, iropt, ir2hf - ha Su^H^H Oracle-s technológiában jártas olvasná :)) szépen felzabálnak egy-két kód forgatásakor 4 GB ramot. Többet nem is tudnának, mert 32 bites binárisokról van szó, de így ugye X, firefox, minden más megy a swap-ba. Ugyanez (volt; ld. később) a helyzet gcc-vel is, ott a cc1plus evett sokat. Aztán a VTK-s (vtk.org) társaság kitaláta, hogy Solarison tessék Sun cc/CC-t használni, és azóta nincs gcc-s alternatíva - de mondom, a gcc is kajált rendesen!
A kód változik, ha azt mondom, hogy tavaly 3 óra alatt megvolt a Slicer 3.2 ugyanezen a gépen szőröstül-bőröstül, akkor látszik, hogy "foltozgatják" :))
A hw-fejlesztés azért is került szóba, mert használom is a programot, és széép a nagy ct/mr dataset-ek is szeretik a kraftot.

Egyébként compiler bugot is fogtam közben, és (a reportolás/fórumozás/levelezés közben) a compiler fejlesztőket is meglepte a nagy memória használat. Mondom, finom cucc :))

<-------
You can't grep on dead trees.

Az rendben van hogy változik a forrás, de biztosan nem az összes forrásállomány. Ergo a ccache -el gyorsíthatónak kell lennie.
Többszálon / több CPU-n való fordítást a forrásnak is támogatnia kell. Támogatják?

Anélkül hogy láttam volna a forrást, nekem úgy tünik vagy az nincs szétszedve megfelelő részekre vagy a build rendszere van helytelenül összeállítva.
Ad2, fordíts konzol módban, grafikus felület, Firefox és egyéb zavaró dolgoktól mentesen.

E6600-omon 6 Gb RAM-mal (swap nélkül) vígan fordítok Firefox 3.6-ot, Eclipse-t, OOo-t. Közben nekem is fut több alkalmazás, Xorg két monitorral és nyolc monitornyi virtuális képernyővel. Hálózat is pörög, de egyszer sem volt gondom belőle.

Offtopic: OK, a xulrunner / Firefox nem szereti ha chroot-ban fordítom és a /proc nincs felcsatolva. Akkor megeszi a RAM-ot, de amint van /proc , minden rendben van.

Nem, tényleg nem az összes állomány változik, de a teljes éjszakai rebuild üres alkönyvtárból indul(na...).
Persze, a töbszálú fordítás megy, eddig is ezt csináltam/csinálom most is :)

Másrészt a Slicer eleve nem egyszerű build szempontjából, eddig tcl scriptek vezérelték a folyamatot (cmake -> tcl, tk, itcl, blt, iwidgets -> python -> netlib, numpy, scipy -> VTK -> KWWidgets -> ITK -> teem -> OpenIGTLink -> Batchmake -> slicerlibcurl -> Slicer), most térnek át (ezt is össze kell majd hákolni) cmake-alapú build-scriptekre.
A ccache amellett, hogy nem tudom, fut-e Solarison, ismeri-e a cc/CC-t, egy plusz réteget ad, ami jó lehet (sebesség szempontjából), de a komplexitást megdobja, gondolom. Esetleg később, ha már minden működik úgy, ahogy kell, szóba jöhet.

A konzol mód nem jó, mert akkor csak bámulom a monitort, de azért néha kell a gép másra is :) - ez az asztali gépem. Cikkírás, cikk olvasgatás..., még ha próbálom is minimalizálni amit csinálok, kell a gui.

Ram: igen, mint említettem maguk a Sun-os compiler-fejlesztők is meglepődtek a memória-használaton, de aztán annyiban maradtunk, hogy "ez van".
Itt a thread A Sun fórumon.

A Slicer meg itt van:
Erről, a 3-6-ról beszélünk.

köszi a segítséget! :)

<-------
You can't grep on dead trees.

Amit a weboldalon írnak:
# Only works with GCC and compilers that behave similar enough.
Régen (~2000-ben) pörgettem nagyobb dolgokat Solaris-on, akkoriban nem teljesen hasonlított a sün CC és a GCC paraméterezése.
Neten találtam arra utalást, vannak akik Solaris-on használják a ccache-t a sünös CC-vel. Neked is mennie kell majd.

( imp | 2010. 08. 09., h – 14:46 )

A "heavily templated" -en kéne lájtosítani, ha az opció:)

:)
Igen, ez jó lenne... de sajnos több okból sem megy a dolog:

1.) hótthülye vagyok a C++-hoz :)
2.) dettó képfeldolgozás - na jó, ennek kicsit utánaolvastam, meg bejártam egy-két infós órára, már kicsit idősebb fejjel (biológus volnék eredetileg), de azért...
3.) céges kód (ITK - KitWare), ami ugyan nyílt, de megvannak a saját fejlesztőik, irányvonalaik, stratégiájuk, stb. Jó fejek, sokat ismerek közülük (úgy értem levelezésen keresztül), de ekkora változást amatőrként nehéz lenne végigverni rajtuk :)
<-------
You can't grep on dead trees.

Mert belemásztam könyékig. Bugokat reportolgatok, aztán jön a javítás (elég gyorsan!!), X feature új, próbáljuk ki, Y cuccot valamelyik kolléga hiányolta, szóltam, hopp, megcsinálták.
Fejlesztik, én meg mindig az újat használom.
A végleges/teljesen supportált Solaris porthoz kéne nightly buildet is csinálni/csinálnom nekik, ami ugye ideális esetben egy teljes újrafordítás.
Hát, nagyjából, nagyon röviden, ezért.
<-------
You can't grep on dead trees.

( Jason v | 2010. 08. 09., h – 16:01 )

hát ha swappel, akkor bovits memoriat :)

Az meg, hogy hány magon fordít, az a build rendszeredtől függ, meg a projekted felépítésétől.
Nézd meg, hogy build közben hány compiler fut egyszerre, s tiéd a válasz.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Sajnos a mem. bővítés jelenleg nem megy, mint írtam:
... 8GB RAM (sajnos i975x chipset, több nem fér...)
Az, hogy hány magon fordít rendben lenne (nyilván.. :)), de arra vagyok kíváncsi, hogy jobb-e a HT-s Core iX termékvonal, vagy inkább a fizikai magok száma számít. Nem tudom,a HT mennyit segít. Fordításnál - más teszteket találtam (rar, játék, office, video/audio tömörítés. stb), de ilyesmit nem.
<-------
You can't grep on dead trees.

Annyi szálon fordít, amennyin én szeretném. :)
Ebben a fileban lehet beállítani: 


set numCPUs [lindex [exec /usr/sbin/psrinfo | grep on-line | wc -l | tr -d ''] 0]

Szeretném, ha ez a szám minél nagyobb lenne, de per pillanat a 4 magból 2-t tudok kihasználni. :(
<-------
You can't grep on dead trees.

( tovis v | 2010. 08. 09., h – 17:01 )

Két gyors disk és strippelt RAID = RAID0 - ideális a SCSI 15000 fordulat/perc, de a SATA2 is jó eredményeket nyújt. Persze ez valami gyors PCI -on, gyors interfésszel.
És ne felejtsd két fordítás között a dolgokat menteni - a RAID0 gyors, de nem megbízható!
Ha mégis inkább az ésszerűség győz, akkor darabold a programot több részre úgy, hogy ne kelljen az egész szakramentumot újra fordítani egy ideig, csak azt amivel foglalkozol. (IPC?)

* Én egy indián vagyok. Minden indián hazudik.

( b | 2010. 08. 09., h – 17:14 )

Erről pont mostanában olvastam egy cikket, ahol felállítottak egy sorrendet a legkönnyebben (legolcsóbban) upgradelehető dologtól legnehezebbig (legdrágábbig).

1. a memória. Ez legolcsóbb.
2. a disk. Még ez is olcsó
3. CPU és alaplap csere. Ez a legmacerásabb és legdrágább.

Ahogy én gondolom ez minden nem desktop alkalmazást futtató gépre igaz. Desktopoknál bejön még a videókártya.

( Lacyc3 v | 2010. 08. 09., h – 17:30 )

Szerintem ha van rá lehetőséged akkor bővíts, cserébe tartós konfigurációt kapsz.

Intel: Core i7-920 http://ark.intel.com/Product.aspx?id=37147
AMD: Phenom II x6 1090T http://products.amd.com/en-us/DesktopCPUDetail.aspx?id=640&f1=&f2=&f3=&…

Az AMD nem túl közlékeny a processzoraival kapcsolatban, így nem igazán teljes a kép.

Cache:
Intel: 8MB "Smart Cache, ez azt jelenti hogy a magok között dinamikusan osztogatja a memóriát.
AMD: L1: 128K + L2: 512K +L3: 6144K

Max. ram:
Intel: 24GB
AMD: Legalább 16GB, pontos értéket nem találtam.

CPU magok + szálak kezelése:
Intel: 4 core -> 8 thread (HT)
AMD: 6 core -> 6 thread

Ha a teljesítményt nézzük, akkor a nagyobb és okosabb cache illetve a jobb szintetikus teljesítmény miatt az Intel a nyerő.

De ha nézzük az árakat is, akkor viszont AMD. Az 1090T kistesója az 1050T közel fele annyiba kerül (ipon) mint az i7-920 vagy a 1090T, de a bátyó magjára épül azzal a különbséggel hogy alacsonyabb az órajele, így jó esélyed van hogy egy kis tuninggal csinálsz belőle 1090T-t, az ár különbözetből pedig vásárolsz még memóriát.

Szerintem.

( aspirin v | 2010. 08. 09., h – 17:56 )

No, akkor most "egybeválasz" következik :)
@b @LZ
Nos, igen, hajlok az SSD felé, erre most lenne is elég $$, de... szóval az a bajom, hogy memóriát már nem tudok többet a gépbe gyömöszölni. 4 foglalat*2GB van per pillanat, és a chipset nem tud 8GB-nál többet, állítólag. Igazából elég lenne több ram, a gép teljesítménye elég (persze, mindig lehetne gyorsabb :)) - viszont ahhoz kell alaplapot, cpu-t, ÉS memóriát cserélnem... Ehhez meg el kéne eadni azt, ami van, _és_ hozzácsapni a jelenlegi pénzmagot.
Így nyilván nem maradna pénzem ssd-re - bááár ha jól megtömöm ram-mal, erre - talán - akkor szükség nem is lenne :)

VAGY: tud-e valaki olyan asztali (jelen esetben socket 775-ös) alaplapot, amibe bele lehet tenni több, mint 8GB ramot. Izé... 4GB-s ddr2-es modulokat nem nagyon lehet kapni... :(, tehát az újabb alaplapok ezért esnek ki. (itthon p43-as chipsetes van, ami papíron tudja a 16GB-t, de...)

@Lacyc3:
köszönöm, hogy összeszedted, de... éppen ez a bajom, hogy melyik a jobb:
a 4 mag * 2 (HT) = 8 szál, vagy a 6 fizikai mag. Ld. fentebb, az előző bekezdésben, hogy miért alternatíva az alaplap+cpu+ram az ssd-vel szemben. Igaz, drágább alternatíva.
Nem vagyok "hívő"; volt AMD, meg Intel gépem is, több is, bár igaz, mostanában az Intel jobbnak tűnik, ha a teljesítményt nézzük. Ha az árat is, akkor már nem annyira... :)

@tovis:
hát, igen... a "gyors interfész"-en megbukik a dolog. Hah, ha lenne mondjuk 2db SAS 15K-s hdd-m, vezérlővel, persze, nem főne a fejem :)))
<-------
You can't grep on dead trees.

A HT hatékonysága nagyban függ a futtatott programoktól, valójában, ha 8 ugyanolyan utasításokat használó program terheli a CPU-t, akkor a HT értelmét veszti és nincs teljesítmény növekedés, sőt akár lassulás is várható, kicsit elnagyolva a dolgot olyan mintha HT nélküli, 4 magos CPU-t terhelnél 8 szállal.

Nem tudom, hogy a fordításkor pontosan hogyan alakul a processzor részegységeinek a használata, de itt ( http://stackoverflow.com/questions/2015134/impact-of-hyperthreading-on-… ) 33%-os sebesség növekedést ír HT-gel, ami nem rossz (az Intel referencia 30%-hoz viszonyítva sem), más kérdés hogy vehetjük-e a coreutils forgatását alapnak.

Idealizáljunk: Ha mind a négy mag képes a HT-gel 30%-ot hozni, akkor 120% -os a gyorsulást eredményez, ez pedig logikailag 5 és "1/5" szálat jelenthet neked fordításkor.

Ha az AMD megoldását nézzük, akkor van 6 fizikai, egymástól csak L3 cache miatt függő magok, így körülbelül egyenletes, kódtól független (nem áll fenn a HT féle opcionális probléma) fordítási sebességet kapsz. Mondjuk számoljunk csak 5 magot, mert az egyiket nekiadjuk az OS-nek, akkor is stabilabb és több teljesítményt kapsz mint HT-gel.

Most hogy kb. mondtam valami egyértelműt jól összezavarlak: A Gigabyte i-RAM mókával ki tudsz rakni 16GB-ot hagyományos ram modulokkal -> viszonylag olcsó SSD utánzat. Talán segíthetne ha azt a 4-5GB-nyi swapot iderakod, a maradék helyre pedig - ha elfér - a forrást, így a diszkeknek már nem kell annyit olvasgatniuk + nincs swap -> a szűk keresztmetszet vagy a CPU lenne, vagy még mindig a diszkek, de közel sem ekkora terheléssel.

A bővítés előtt kipróbálnám az i-RAM-ot, veszteni nem sokat veszthetsz.

hmm az i-Ram-mal kapcsolatban:
jól látom, hogy pci slotos (szerk: csak tápot szedi onnan, amúgy sata1) 4xddr1 -> max 4GB egy kártya kapacitása? Így kellene 4db i-ram (4 pci slotban) + 16db 1GB-os ddr1 modul, ami azért nem olyan olcsó (200eFt?)
Hmm valahol emlegetnek ddr2 változatot is 8GB ram fogadással :)
http://xtreview.com/addcomment-id-4683-view-Gigabyte-i--RAM-BOX.html

Vagy egy ilyet dobott az ebay, 48GB-ig 6 ddr2 slottal:
http://cgi.ebay.com/ACARD-9010B-RAMDisk-Falsh-HDD-DDR2-RAM-Memory-SSD-/…

Régebben olvastam valami eszközről, amivel bővíteni lehet bizonyos esetekben a memóriát, sok kisebb modulból... de nem ugrik be :S

ha 8 ugyanolyan utasításokat használó program terheli a CPU-t, akkor a HT értelmét veszti
Elképesztően jól optimalizált number crunching alkalmazás kell hozzá, hogy a végrehajtóegységek legyenek a szűk keresztmetszet.

Gyakorlatban egy fordítónál a CPU idejét két dolog tudja nagyon elvinni: a sok elágazás miatt a branch misprediction, valamint sok indirekciót tartalmazó adatszerkezetben kotorászás közben cache miss és emiatt memóriára várás. Az SMT (simulatenous multithreading) megoldások, mint pl a Hyperthreading, lényege pont az, hogy az ilyen szerencsétlen helyzetekben, amikor az aktuális szálon elakadás van, akkor legyen egy másik szál, amihez hozzányúlhat a processzor és addig valami hasznosat csinál ahelyett, hogy várakozna.

A fordítóprogramok közel vannak a legjobb terheléshez az SMT számára. Még a Pentium4-es időkben (pedig azok elég trágya SMT implementációk voltak) is sikerült 50% feletti javulást elérnem többszálú fordítással. Az i7-es Hyperthreading megvalósítása lényegesen jobb a P4-esekénél.

Linuxon van a (roppant kreatív módon) perf nevezetű tool, amivel lehet a CPU alacsony-szintű metrikáit lekérdezni és akkor szépen látszik, hogy a különböző programok futásakor mi is történik.
---
Internet Memetikai Tanszék

Igen, és is köszönöm mindkettőtöknek, pontosan erre, vagy hasonló információkra szomjaztam! :)
Kerekedik a dolog, lehet, hogy a mostani gépem belét megpróbálom elboltolni :).

Az i-ram jónak tűnik, de eléggé horror ára van (valaki írta is it lejjebb/feljebb), mindenesetre ha durva teljesítmény kell, jól jöhet. Elég sokat olvasgatok IT-ről, de ez valahogy kimaradt (vagy régen olvastam, és mint "elérhetetlen árú cucc" kihullott a szürkeállományból :))

<-------
You can't grep on dead trees.

( XMI | 2010. 08. 09., h – 23:16 )

A build folyamat szétdobható-e több gépre? Sima make-kel megy? Ha igen, akkor distcc-t meg lehet próbálni beüzemelni, akkor szépen tud skálázódni. UPDATE: látom már eszedbe jutott. 100mbit-es háló szerintem nem sokat árt neki, a forrásfájl gondolom kicsi, csak sokat szöszöl vele a fordító.

Másik trükk lehet az időszakos memóriakifogyás esetére ramzswap használata (sajnos tudtommal csak Linux alatt van). Be- és kitömöríteni a memória tartalmát még mindig gyorsabb, mint diszkre írni. Én korábban kísérleteztem erősen memóriazabáló számítási feladatoknál ramzswappal, fizikai 8GB-ba lehetett kb 11-12GB-os java heap size-ot belepréselni. 13GB már nagyon nyögvenyelős volt.

Core i7 upgrade: nagyon erősen mellette szól, hogy a 920-asnak 3 csatornás memóriavezérlője van -> 6 foglalat -> 12GB ram.

2GB-osnál nagyobb modulokkal nem érdemes kalkulálni, még mindig aránytalanul drágák (értsd: kijön belőle az i7-es ára) és nagyon nehéz beszerezni őket. Ez pedig azt jelenti, hogy bármi ami nem LGA1366-os, annál 8GB a maximum.

Esetleg lehet még próbálkozni ebay-ről vadászni valami használt szervervasat, azzal lehet 8 magod és bőven sok memóriád, de akkor CPU-ban biztosan nem a legújabbat kapod.

Én az ilyen i-RAM megoldásokkal biztosan nem pöcsölnék, rengeteg pénzt el lehet verni vele és egyáltalán nem garantált, hogy meghozza a várt eredményt neked. Főleg azzal van bajom, hogy SATA porton keresztül kapcsolódnak a host géphez.

Inkább több pénzt gyűjtenék az i7-esre 'azt hadd szóljon.
---
Internet Memetikai Tanszék

Igen, a build megy parallel-ben. A baj az, hogy ugyan van még Solaris itt a klinikán, de azok gyengébb gépek, _összességében_ nem tudom, gyorsabb lenne-e a folyamat.
Egyébként van dmake-ünk Solarison, az IDE/compiler tools része, ami pontosan ezt csinálja: szétdobja gépekre a fordítást. Ehhez azt hiszem picit reszelni kell a Makefilekat(*), de erről csak régebben olvasgattam. (*: cmake nemtom ismeri-e, de gyanús, hogy nem.)
Szóval a Core i7 felé húzok én is, de azért egy ssd is sokat dobna a folyamaton, valószínű. forrás + swap + tmp oda, aztán hadd szóljon! - csak az a fránya memória ne fogyna el... :(

zsolti10 (bocs ha nem pontos, most fejből írom) szokott itt a fórumon jó gépeket hirdetni, volt is egy 4 magos, 16GB-s munkaállomás a tavasszal, de akkor nem jött össze annyi zseton, sajnos. Ráadásul Quadro-val, amit Solarisunk nagyon szeret, meg az OpenGL miatt a VTK, azaz így a Slicer is :)

ramswap: nem ismerem, de erős a gyanúm, hogy nem-solaris... :(
<-------
You can't grep on dead trees.

( kisg v | 2010. 08. 09., h – 22:52 )

Ha nem ragaszkodsz ahhoz, hogy nálad forduljon újra az egész, akkor esetleg fordíthatnál Amazon EC2-n.

Ha másra nem, arra is jó lehet, hogy pár $-ból kiderül a CPU esetleg a diszk vagy a RAM a fontosabb, és akkor annak megfelelően tudod bővíteni a helyi gépparkot. (Vannak különböző típusú terhelésre tervezett VM-eik).

Úgy láttam, hogy OpenSolaris-os VM-eket támogatnak, de lehet, hogy van "rendes" Solaris is.

Desktop alaplapot még nem nagyon láttam, amibe több mint 16GB RAM belement volna. Ha találnál ilyet, az engem is érdekel. Szerk: közben látom, hogy socket 1366-osból van ilyen tehát az is lehet alternatíva.
Esetleg egy brand workstationt lehetne nézni (pl. Dell-t talán láttam). Másik lehetőség, hogy egy előző generációs Opteron vagy Xeon alapú szervert olcsón, használtan megszerezni, pl. Sun X2200-as sorozatot, vagy egy G5-ös HP-t.

Előbbinek az is az előnye, hogy a Solaris biztos jól megy rajta...:)

Üdv,
Gergely

Amazon jó ötlet, megnézem, köszi!
(Solaris 10 nem jó sajnos, mert új python-nak új libcrypto kell, ami S10-ben nincs, azaz per pillanat Opensolarisra van csak Slicer.)
Ha találok lapot, szólok, megígérem! :)

Használt ws-ek: igen, itt a hup-on is szoktak lenni finom dolgok, írtam is, ld. picit fentebb. Ráadásul az, miről írtam, rajta van a HCL-en is...
<-------
You can't grep on dead trees.

( kikuchiyo | 2010. 08. 09., h – 22:56 )

Az SSD nem csak abból a szempontból előnyös, hogy azzal gyorsabb lenne a swap, hanem a forráskódot is gyorsabban olvasná be róla, és az elkészült tárgykódot/binárist gyorsabban tudná kiírni rá.

(Vagy ez a lépés kevésbé számít? Sosem profilíroztam még ilyen méretű fordítást.)

Valószínű nem jönne rosszul, mert:
mikor a fentebb linkelt Sun fórumos thread-be készítettem a bugreportot, megnézegettem, hogy mi történik.
Nos, mielőtt lenne .o fájlunk, készül asszem 7 db (!!!) átmeneti fájl a /tmp-be (most hirtelen nem emlékszek pontosan, de preprocesszor, átmeneti kód optimalizáló, ennek különböző stációi, assembler, stb...). Ezek a problémás fájlok esetében GB-s nagyságú fájlok, amit felírni, visszaolvasni eléggé húzós lehet.
Vegyük bele, hogy először az összes include-ot benyalja (sok pici olvasás), majd (gondolom) részenként irkál a különböző átmeneti fájlokhoz. Ha több szálon fordítok, akkor többszörözzük azt is.
Mégráadásul, a "problémás" fájlok nagyjából egyszerre fordítódnak. De csak nagyjából... :)

<-------
You can't grep on dead trees.