Halfedge Skrevet 2. desember 2009 Del Skrevet 2. desember 2009 Vi skal sette sammen en PC med det eneste formål å kompilere mye kildekode så raskt som mulig hver natt. Det innebærer veldig mye skriving og lesing til disk og vi tror derfor en SSD-disk vil gi stor effekt. CPU har også veldig stor betydning. Vi tror hovedkort og minne har noe mindre betydning. Er det noen som har erfaring fra slike PCer eller som har forslag til forbedringer? Handleliste hos Komplett: - Crucial SSD M225 series 2,5" 128GB SATA2, read/write speed of up to 250MB/190MB sec, 64MB Cache - Intel Core i7 Quad Processor i7-950 1366, 3.066GHz, QuickPath 4.8GTs, 4x 256KB, Boxed - ASUS P6T SE, X58, Socket-1366 DDR3, ATX, Firewire, GbLAN, 3xPCI-Ex(2.0)x16 - Corsair Dominator DHX+ DDR3 1600MHz 6GB Kit w/3x 2GB XMS3 modules, CL8-8-8-24, for Core i7 - Chieftec Super Series 650W PSU ATX 12V V2.3, 80 Plus, Modular, 1x 6pin+1x 6+2pin PCIe, 6x SATA, 140mm Vifte - MSI GeForce 210 512MB PhysX CUDA PCI-Express 2.0, DDR2, DVI, native-HDMI, HDCP, Graphics Plus - Cooler Master Elite 310 Sort/Sølv Vifte: 1x 120mm Bak, ATX, mATX, 2x USB, 1x Audio, 17 dBA Lenke til kommentar
bjovas Skrevet 2. desember 2009 Del Skrevet 2. desember 2009 Kompilering stiller vel store krav til alt utenom gpu egentlig. Tror nok den boksen der skal klare å ta unna det meste. Men dere har ikke tenkt på å gå for en mer rendyrket servermaskin da? Lenke til kommentar
genstian Skrevet 2. desember 2009 Del Skrevet 2. desember 2009 Ha kildekoden i minne og drop SSD. Sats heller på kjappere minne og CPU og gjerne sett opp ccache (kan ligge i minne den også) dersom det er same koden. Lenke til kommentar
Halfedge Skrevet 2. desember 2009 Forfatter Del Skrevet 2. desember 2009 Takk for svar! Ha kildekoden i minne og drop SSD. Sats heller på kjappere minne og CPU og gjerne sett opp ccache (kan ligge i minne den også) dersom det er same koden. Kildekode og genererte filer er mer enn 25GB, fordelt på 40000-50000 filer, og vi må foreløpig kjøre Windows XP, så vi kan ikke ha alt i minnet Men dere har ikke tenkt på å gå for en mer rendyrket servermaskin da? Hva tenker du på da? Har du et eksempel? Lenke til kommentar
Stigma Skrevet 2. desember 2009 Del Skrevet 2. desember 2009 (endret) Bør være unødvendig å kjøre ting i minnet uansett med en SSD. Selv om det evt. skulle være relativt mye random skriving så skriver en god SSD 25GB innen noen minutter anyway, så det er ikke harddisken det kommer til å stå på (med en SSD anyway). Det er vel ren CPUkraft som kreves mest av i kompilering. Håper at compileren deres støtter multithreading Jeg må nesten spørre for min egne nysgjerrighet, hva er dette for noe dere lager? 25GB ferdigkompilert kode à 50.000 filer høres passelig sinsykt ut. Eller kanskje det er snakk om en felles maskin for kompilering av kode for mange forskjellige prosjekter for et programmeringsfirma? -Stigma Endret 2. desember 2009 av Stigma Lenke til kommentar
bjovas Skrevet 2. desember 2009 Del Skrevet 2. desember 2009 Men dere har ikke tenkt på å gå for en mer rendyrket servermaskin da? Hva tenker du på da? Har du et eksempel? Det er litt synsing fra min side, men ville komme med et innspill. F.eks HP Proliant DL360 er jo en sikker arbeidshest: http://h10010.www1.hp.com/wwpc/us/en/sm/WF...644-241475.html Ble også litt nysgjerrig på hva slags systemer dere jobber med, om du har anledning til å fortelle om det. Jobber med programmering, men våre antall kodelinjer er veldig små i forhold til det du legger frem. Lenke til kommentar
Stigma Skrevet 2. desember 2009 Del Skrevet 2. desember 2009 Men dere har ikke tenkt på å gå for en mer rendyrket servermaskin da? Hva tenker du på da? Har du et eksempel? Det er litt synsing fra min side, men ville komme med et innspill. F.eks HP Proliant DL360 er jo en sikker arbeidshest: http://h10010.www1.hp.com/wwpc/us/en/sm/WF...644-241475.html Ble også litt nysgjerrig på hva slags systemer dere jobber med, om du har anledning til å fortelle om det. Jobber med programmering, men våre antall kodelinjer er veldig små i forhold til det du legger frem. Det er veldig dyre systemer da... Personlig så har jeg vanskeig for å to at selv et mid-range system med en eldre quadcore ikke vill knuse enhver kompileringsoppgave relativt raskt, selv om det er snakk om såpass store mengder. Kompilering er tross alt ikke engentlig så fryktelig tungt, i forhold til mye annet slik som encoding osv. Så lenge du har en quadcore, en compiler osm støtter multithrading, og (evt.) en halvveis grei SSD som talker mange små filer bra, så tror jeg selv slike store prosjekter vil kompileres rimeig raskt. Når det er snakk om over-natten kompilering så bør det være mer enn nok tid til det. Jeg tror om noe at specsene på masinforlaget over er noe overkill, men om det er en større bedrift det er snakk om så er det sikkert budsjett for sånt uansett. Jeg ville satset på godt med RAM for systemet dog. Det sagt så skal jeg ikke utrope meg som å være ekspert på dette. Jeg har aldri kompilert noe i nærheten av 25GB med ferdigkompilert kode, men jeg vil tro at det skalerer rimelig linjært. -Stigma Lenke til kommentar
bjovas Skrevet 2. desember 2009 Del Skrevet 2. desember 2009 Seff, specsene han nevner burde funke som bare det. Lenke til kommentar
Halfedge Skrevet 2. desember 2009 Forfatter Del Skrevet 2. desember 2009 (endret) Jeg må nesten spørre for min egne nysgjerrighet, hva er dette for noe dere lager? 25GB ferdigkompilert kode à 50.000 filer høres passelig sinsykt ut. Eller kanskje det er snakk om en felles maskin for kompilering av kode for mange forskjellige prosjekter for et programmeringsfirma? Ja, det er en felles maskin med mange biblioteker og applikasjoner innen teknisk programvare utviklet over tiår, hovedsaklig C++, C# og Fortran. Alt kompileres ikke hver natt. De ca 25GB/50000 filene inkluderer all kildekode, eksterne biblioteker og alle temporærfiler som genereres underveis, med og uten debug info, men det skal tross alt leses fra og skrives til disken. Hele prosessen fra henting i kildekodedatabasene, kompilering, unit testing, til installasjoner for utviklere og kunder er klare tar ca 6 timer med en 2 år gammel Core2 Duo PC. Det hender vi må kompilere på dagtid og derfor har vi har behov for å kutte ned betydelig på tiden. Så lenge du har en quadcore, en compiler osm støtter multithrading, og (evt.) en halvveis grei SSD som talker mange små filer bra, så tror jeg selv slike store prosjekter vil Vet du om SSD-disker som takler mange små filer bedre eller dårligere enn andre? Endret 2. desember 2009 av Halfedge Lenke til kommentar
Stigma Skrevet 3. desember 2009 Del Skrevet 3. desember 2009 (endret) Jeg må nesten spørre for min egne nysgjerrighet, hva er dette for noe dere lager? 25GB ferdigkompilert kode à 50.000 filer høres passelig sinsykt ut. Eller kanskje det er snakk om en felles maskin for kompilering av kode for mange forskjellige prosjekter for et programmeringsfirma? Ja, det er en felles maskin med mange biblioteker og applikasjoner innen teknisk programvare utviklet over tiår, hovedsaklig C++, C# og Fortran. Alt kompileres ikke hver natt. De ca 25GB/50000 filene inkluderer all kildekode, eksterne biblioteker og alle temporærfiler som genereres underveis, med og uten debug info, men det skal tross alt leses fra og skrives til disken. Hele prosessen fra henting i kildekodedatabasene, kompilering, unit testing, til installasjoner for utviklere og kunder er klare tar ca 6 timer med en 2 år gammel Core2 Duo PC. Det hender vi må kompilere på dagtid og derfor har vi har behov for å kutte ned betydelig på tiden. Så lenge du har en quadcore, en compiler osm støtter multithrading, og (evt.) en halvveis grei SSD som talker mange små filer bra, så tror jeg selv slike store prosjekter vil Vet du om SSD-disker som takler mange små filer bedre eller dårligere enn andre? Takk for innsikten, det hjelper med å kunne gi forslag. For SSDer så er det mye annet enn ren sekvensiell read/write du må se på for faktisk ytelse. Spesiellt er det random write som ofte er flaskehalsen når det er snakk om behandling av mange små filer. Jeg kjenner som sagt ikke spesilelt godt til den modellen som du selv har foreslåttt, men jeg forstår det slik at Intel's modeller fremdeles ligger et godt stykke forran når det gjelder nettop dette, og når du skal generere opp til 50K mindre filer på harddisken så tror jeg denne spesifikke egenskapen vil komme til å spille en stor rolle - større enn bare hvor fort den kan sekvensiellt skrive store filer. Men for virkelig ekspertutsagt bør du gjerne spørre Simen1 sansynligvis er forumets mest oppdaterte bruker når det gjelder SSD teknologi: https://www.diskusjon.no/index.php?showuser=3851 Utover det så tror jeg fremdels at den største faktoren sansynligvis er ren CPUkraft i de fleste tilfellene. Vet du om kompilatoren(e) dere bruker støtter multithreading? Forskjellen på en quadcore vil jo da være så mye som 4x. Det er verdt å sjekke opp i dette. Du kan potensiellt da tjene mye mer på å bruke en oppdatert/modifisert/optimisert kopilator på en flerkjerne CPU enn du kan ved å bare lasse på raskere hardware. Hvis jeg hadde hatt fysisk tilgang til det allered eksisterende systemet dere bruker så hadde jeg først av alt kjørt noen tester for å se nettop hva flaskehalsen er i det nåværende systemet. Da vil du jo få vite nettop hva det er systemet har som nåværende flaskehals, og det er en bedre strategi enn å bare oppgradere systemet vilkårlig med det beste du finner på markedet. Det er litt vanskelig å komme med konkrete forslag ellers, siden jeg (og sikkert de fleste andre på forumet) altså har vært borti kompilering på såpass massiv skala før - så det er en litt ny problemstilling for oss. All kode jeg noengang har skrevet har blitt kompilert innen et par minutter, så jeg er faktisk litt usikker på hva som kreves mest av systemet under en slik prosess (men jeg holder en knapp på CPU som sagt). -Stigma Endret 3. desember 2009 av Stigma Lenke til kommentar
Jann - Ove Skrevet 3. desember 2009 Del Skrevet 3. desember 2009 CPU og minne er viktig, men med nok kode så utgjør også ssd enormt med dagens prosessorer. Hvilket OS kjører den nåværende serveren? I linux viser io waith %-andelen hvor mye av prosessorbruken som skyldes unødvendig venting på disk-lesing, og process explorer skal klare å få fram noe tilsvarende på windows. Men du har valgt feil sort ssd. Velg en 160GB gen2 inteldisk istedet, da den yter mye bedre under hard belastning og støtter TRIM som gir mindre ytelsesnedgradering av at disken blir brukt. TRIM er viktig i den forstand at når filer slettes så fører ikke det til ytelsesnedgradering. En ssd som ikke støtter TRIM vil få dårligere ytelse over tid, spesielt ved hard bruk - og må dermed slettes helt en gang iblandt for å få tilbake ytelsen. Støtter disk og os trim så tar disken seg av det selv, og ytelsen opprettholdes på samme nivå som når disken er ny. Lenke til kommentar
Halfedge Skrevet 3. desember 2009 Forfatter Del Skrevet 3. desember 2009 CPU og minne er viktig, men med nok kode så utgjør også ssd enormt med dagens prosessorer. Hvilket OS kjører den nåværende serveren? I linux viser io waith %-andelen hvor mye av prosessorbruken som skyldes unødvendig venting på disk-lesing, og process explorer skal klare å få fram noe tilsvarende på windows. Vi kjører Windows XP, regner med å kunne gå over til Windows 7 etterhvert. Men du har valgt feil sort ssd. Velg en 160GB gen2 inteldisk istedet, da den yter mye bedre under hard belastning og støtter TRIM som gir mindre ytelsesnedgradering av at disken blir brukt. Takk for tips! Er det denne du mener? Intel® X25-M SSD 160GB 2,5" Ser på den utmerkede SSD-guiden at Intel gjør det best. Komplett skriver at den har mye lavere write-speed enn de andre diskene, men da er vel det feil eller uten betydning. Lenke til kommentar
obergeru Skrevet 3. desember 2009 Del Skrevet 3. desember 2009 Er dere sikker på at hardware er den rette løsningen. Hva med å sette inn flere maskiner i et cluster? http://en.wikipedia.org/wiki/Distcc Lenke til kommentar
Halfedge Skrevet 3. desember 2009 Forfatter Del Skrevet 3. desember 2009 Utover det så tror jeg fremdels at den største faktoren sansynligvis er ren CPUkraft i de fleste tilfellene. Vet du om kompilatoren(e) dere bruker støtter multithreading? Forskjellen på en quadcore vil jo da være så mye som 4x. Det er verdt å sjekke opp i dette. Du kan potensiellt da tjene mye mer på å bruke en oppdatert/modifisert/optimisert kopilator på en flerkjerne CPU enn du kan ved å bare lasse på raskere hardware. For C++ bruker vi VS2005. Den har liten eller ingen støtte for multithreading builds, men jeg fikk tips om et verktøy fra Xoreax som vi skal undersøke nærmere. VS2008 og nyere støtter multithreading builds, men det er et større prosjekt hver gang vi skal oppgradere kompilatoren. Det passer som regel aldri Det raskeste og billigste er å oppgradere til den råeste SSD-disken og CPUen, og så skal vi jobbe med multithreading på litt sikt. Jeg skjønner at det er der potensialet er størst. Lenke til kommentar
Jann - Ove Skrevet 3. desember 2009 Del Skrevet 3. desember 2009 Det er helt korrekt at den har lavere skrivehastighet; men i praksis så er den mye bedre på den formen for skriving som din bruk har, den er god på mye skriving samtidig - også med små filer. Sekvensiell skriveytelse er ikke det som betyr mest for ditt bruksmønster, IOPS betyr vesentlig mer, og der er intel-diskene helt suveren alt annet til den prisen. Lenke til kommentar
Halfedge Skrevet 3. desember 2009 Forfatter Del Skrevet 3. desember 2009 Er dere sikker på at hardware er den rette løsningen.Hva med å sette inn flere maskiner i et cluster? http://en.wikipedia.org/wiki/Distcc Vi har sikkert mest å hente på multithreaded kompilering, distribuert kompilering og forbedring av selve byggesystemet (CruiseControl). Men alt dette er ting vi må jobbe med langsiktig. Hardware kan vi bytte i morgen og det er nesten gratis Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå