PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : SSD als Platte zum Kompilieren ( = sehr viele kleine Schreibzugriffe) ?


Simon
2010-11-25, 14:26:33
Hi,


hier sind ja auch einige Entwickler unterwegs. Lohnt sich eine SSD zum schnelleren Kompilieren von Software? Killen die vielen Schreibzugriffe nicht eine SSD wesentlich schneller oder ist das mittlerweile soweit entwickelt, dass eine SSD sowas problemlos eine Weile mitmacht?


Danke,
Enrico

Samtener Untergrund
2010-11-25, 14:47:23
Du kriegst eine SSD mit privater Nutzung nicht mehr klein, selbst bei bei sehr intensivem Gebrauch. Da ich jetzt zu faul bin, das dir selber vorzurechnen, bis wann man die theoretische Grenze erreicht, hier ein Link aus dem CB-Forum (http://www.computerbase.de/forum/showthread.php?p=8853482). Und gerade bei kleinen verteilten Daten ist die SSD Gold wert. Hier ein Test unter Linux (http://michael.stapelberg.de/Artikel/ssd), der zwar selten dämlich aufbereitet ist, aber mit der Kompilierung eines Debian genau deine Anwendung zeigt. Einfach das letzte Bild ansehen.

PatkIllA
2010-11-27, 11:56:51
Mit den paar Daten, die du tippen kannst (per Hand wohlgemerkt) und gelegentlichem Kompilieren kriegst du sie bestimmt nicht platt.

Morpog
2010-11-27, 12:41:39
Du kriegst eine SSD mit privater Nutzung nicht mehr klein, selbst bei bei sehr intensivem Gebrauch.

Ne Indilinx kriegt man in einem Jahr klein mit Vollverschlüsselung und veralteter FW.

Hier ein User aus dem Luxx:

http://www.abload.de/img/unbenanntzkgr2u0n.png

PatkIllA
2010-11-27, 12:56:00
Klar gehen die Dinger auch mal kaputt (wie jedes andere Teil auch), aber welche Aussagekraft hat jetzt ein einzelner User?

Morpog
2010-11-27, 13:01:04
Ich rede ja auch nicht von Controllerausfällen oder einzelnen Flashchips die wegbrechen.

Hier kann man sehen dass jeder einzelne Flash Nand Chip zu knapp 50% abgenutzt war nach einem Jahr. Soweit abgenutzt dass sich nicht mal mehr die Firmware flashen lies.

Ich wollte damit nur klarmachen, dass man wenn man es drauf anlegt, ne MLC mit Indilinx Controller locker totschreiben kann.

Mit ner Intel oder Sandforce wird das sicher nicht so einfach funktionieren.
Trotzdem ist die allgemeingültige Aussage von Samtener Untergrund wiederlegt.

PatkIllA
2010-11-27, 13:07:13
Die bad blocks verteilen sich aber schon fast verräterisch gleichmäßig auf die Bänke. Wenn man es darauf anlegt kriegt man alles kaputt und als der Indilinx Controller rauskam stand man ja gerade so am Anfang was Erfahrungen mit Consumer SSDs anging. Der ist ja auch regelmäßig gepflegt worden.

Eggcake
2010-11-27, 13:09:04
IMHO fehlen nach wie vor Erfahrungswerte. Bei meiner Indilinx bin ich mir aber ebenfalls etwas unsicher - war halt lange Zeit etwas "unfertig" und ich weiss nicht, ob aktuelle FWs wirklich bugfrei sind.
Zudem ist das Nutzungsverhalten halt auch sehr verschieden und es ist sehr schwer vom einen auf den anderen schliessen zu wollen.

Morpog
2010-11-27, 13:18:16
Die bad blocks verteilen sich aber schon fast verräterisch gleichmäßig auf die Bänke.

Das liegt daran, dass der User sein SSD mit Truecrypt vollverschlüsselt hatte. Es waren also alle Zellen belegt bis auf ein paar Reservezellen, was bei 32GB Kapazität aber auch nicht gerade üpig ist. Dazu kam das er FW 1571 einsetzte, welche einen wear-leveling Bug hatte. Beides zusammen und ohne jede Möglichkeit zu Trimmen ergibt obiges Bild.

Sandratte
2010-11-27, 13:27:48
denke auch, das du dann eine Größere SSD (128GB) kaufen solltest,
damit die vielen schreibaktionen besser verteilt werden können.

Nighthawk13
2010-11-27, 19:28:05
Bei meinem Arbeitsgeber gabs die Diskussion um die SSD-Lebensdauer auch - schlussendlich hat jeder Entwickler 8GB Ram gekriegt & Win7 64bit.
Und siehe da, die Festplattenlampe bleibt aus ab dem zweiten kompilieren;)

Unser Repository inkl. aller object files ist ~5GB gross, dadurch werden alle Lese/Schreibzugriffe vom Filecache bedient.

Das ganze lohnt sich natürlich nur bei wiederholtem Bauen von den gleichen Sourcen, aber das macht man ja als Entwickler typischerweise...

lumines
2010-11-27, 19:34:44
Wollte ich gerade schon schreiben. Solange man genug RAM hat, dürfte nicht allzu viel auf die SSD ausgelagert werden. Und wenn man dann noch bedenkt, dass aktuelle SSDs schon vergleichsweise ausgereift sind und ein vielfaches größer als 32 GB sind, sollte eigentlich nicht viel passieren dürfen.

Gast
2010-11-27, 19:37:15
Du kriegst eine SSD mit privater Nutzung nicht mehr klein, selbst bei bei sehr intensivem Gebrauch. Da ich jetzt zu faul bin, das dir selber vorzurechnen, bis wann man die theoretische Grenze erreicht, hier ein Link aus dem CB-Forum (http://www.computerbase.de/forum/showthread.php?p=8853482).

Milchmädchenrechnung. Irgendwas zusammenfantasieren kann jeder.

PatkIllA
2010-11-27, 19:39:49
Bei meinem Arbeitsgeber gabs die Diskussion um die SSD-Lebensdauer auch - schlussendlich hat jeder Entwickler 8GB Ram gekriegt & Win7 64bit.
Und siehe da, die Festplattenlampe bleibt aus ab dem zweiten kompilieren;)

Unser Repository inkl. aller object files ist ~5GB gross, dadurch werden alle Lese/Schreibzugriffe vom Filecache bedient.

Das ganze lohnt sich natürlich nur bei wiederholtem Bauen von den gleichen Sourcen, aber das macht man ja als Entwickler typischerweise...
Ich wechsle oft mehrfach am Tag und da nervt es, obwohl es nur ein paar hundert MB sind. Der Patchday nervt auch immer. Win7 mit ordentlich RAM hat bei mir aber auch einiges verbessert.

Spasstiger
2010-11-28, 12:24:46
Selbst wenn die SSD nach 2 Jahren ausfällt und getauscht werden muss, ist es doch kein Grund, auf SSDs zu verzichten. Gerade beim Kompilieren von großen Projekten bringen SSDs enorme Performancesteigerungen und somit auch Produktivitätssteigerungen. Die Kosten für den regelmäßigen Tausch der SSD und das Wiederaufspielen des Images hat man durch die Produktivitätssteigerung locker eingeholt. Beim Kumpel konnte durch Anschaffung neuer PCs mit SSDs die Compilezeit eines Projekts von 30 Minuten (Pentium 4 3 GHz, 2 GiB RAM, HDD) auf 1-2 Minuten (Core i7 2,8 GHz, 8 GiB RAM, SSD) verkürzt werden.

Shink
2010-11-28, 12:33:05
Hmm... also SSD zum Builden von großen Projekten bringt schon einiges. Gegen Dinge wie den FAT-bedingten Zeitaufwand für das Löschen von tausenden Dateien hilft auch kein noch so großer Speicher.

Meinereiner bekommt in der Arbeit auch keine SSD also builde ich auf einer RAM-Disk. Ich muss halt täglich meinen Workspace zippen und auf die Platte sichern aber das mache ich während dem Teekochen; fällt also nicht ins Gewicht. Außerdem hab ich dann einen Backup wenn mir Eclipse wieder mal meine Projektfiles schrottet. (Ja, das Entpacken des Workspace geht schneller als das neue Auschecken aller Projekte)

Simon
2011-01-26, 12:55:58
So, nochmal hochbringen das ganze...

Mit den paar Daten, die du tippen kannst (per Hand wohlgemerkt) und gelegentlichem Kompilieren kriegst du sie bestimmt nicht platt.
Naja, es geht hier um 20-70h Entwicklung pro Woche :freak:


Letztendlich gelöst ist das ganze durch Linux Kernel 2.6.38 mit cgroup aktiviert und eine Seagate Hybrid-Platte (Laptop!). Endlich im Hintergrund kompilieren und nebenbei problemlos weiterarbeiten. Compile geht schnell genug, nur das Linken der statischen Binaries ist :hammer:

SSDs sind dann für mich für den täglichen Gebrauch dann doch zu teuer, brauche min. 150GiB Platz...