Umstieg auf SSD sinnvoll?



  • @Swordfish sagte in Umstieg auf SSD sinnvoll?:

    @john-0 sagte in Umstieg auf SSD sinnvoll?:

    Die PCIe AHCI Blades [...] hatten einen SATA Controller auf dem Blade und kommunizierten mit bis zu 4×PCIe Lanes mit dem Host,

    Ja, so habe ich mir das vorgestellt. Aber was da (wenn es sie nicht mehr gibt) jemals der Vorteil gegenüber einer SSD an SATA gewesen sein soll erschließt sich mir nicht.

    Gibt sie anscheinend doch noch: https://geizhals.eu/?cat=hdssd&xf=4832_6~5940_AHCI
    Sind aber nicht ganz billig.

    Der Vorteil gegenüber SATA ist die deutlich höhere Übertragungsrate, sowohl IOPS als auch MB/s. Der Grund warum es die nicht mehr gibt ist vermutlich einfach dass NVMe nochmal deutlich besser ist. Und da aktuelle BIOSe alle von NVMe booten können, besteht halt kaum mehr Nachfrage. Die Nische zwischen dem wofür SATA allemal reicht und dem wo man auch NVMe verwenden kann ist halt nicht sehr gross.



  • Oh, ok, mir war nicht klar wie groß da der Unterschied im Datendurchsatz ist.



  • Lohnt sich eigentlich der Umstieg auf eine NVME fürs Kompilieren?



  • @Mechanics sagte in Umstieg auf SSD sinnvoll?:

    Lohnt sich eigentlich der Umstieg auf eine NVME fürs Kompilieren?

    Da lohnt sich der Vergleich der IOPS Werte für die SSD, und eine Abschätzung, ob durch die Übersetzung überhaupt soviel IOPS generiert werden.



  • Und hat das hier schon mal jemand evaluiert/ausprobiert?
    Schätzen würde ich, dass die CPU der Flaschenhals ist.



  • Ich glaub das kommt auf die Sprache und die genauen Umstände drauf an. Wenn du grosse Java Frameworks kompilierst ist ne schnelle SSD vermutlich gut.

    Bei C++ mit viel Includes und vielen Tempate-Instanzierungen ist eher die CPU der Flaschenhals. Es sei denn du machst inkrementelle Builds ohne Link-Time-Code-Generation in denen fast nur gelinkt wird.

    Unsere "clean" Builds skalieren auf jeden Fall fast perfekt mit der CPU Leistung (#Cores * Core-Takt). SATA vs. NVMe SSD hat da keinen grossen Unterschied gemacht. Was man allerdings schon merkt ist: wenn die Object-Files und Output-Files auf der selben (SATA) SSD wie das OS liegen, dann hat das während des Linken eine merkbare Auswirkung auf die Responsiveness des OS.

    Unsere dicken PCs haben daher 2 SSDs, 1x SATA für das OS und 1x NVMe für die Projekte (Code, Intermediate und Output Files).



  • Hab da mal ein bisschen rumgetestet und praktisch keine Unterschiede feststellen können. Natürlich kein repräsentativer umfassender Test, aber zumindest bei paar unserer Projekte und typischen Änderungen habe ich keine Vorteile feststellen können.



  • @Mechanics

    Moin, ich weiß nicht, ob sich das noch auf mein Eingangspost bezieht, war die letzten Tage nicht online.

    Ich kann nur berichten, dass meine CPU kein Flaschenhals zu sein scheint, mir wird lediglich die Festplatte angezeigt.
    Es ist ein Vier-Kerner (Athlon mit 3,9Ghz).

    Ich werde den unmittelbaren Vergleich mit dem Umtausch der Festplatte erfahren.



  • @patrik-kuehl sagte in Umstieg auf SSD sinnvoll?:

    Moin, ich weiß nicht, ob sich das noch auf mein Eingangspost bezieht

    Nein, das bezog sich auf meine eigene Frage, ob sich eine NVME SSD im Vergleich zu einer SATA SSD fürs Kompilieren lohnt.
    Ich hab 24 virtuelle Kerne, und schaffe es, sie beim Kompilieren komplett auszulasten.



  • Ich habe nun den Umstieg auf eine SSD vollzogen und kann berichten, dass der Umgang mit allen JetBrains-IDEs deutlich angenehmer geworden ist (auf beiden Betriebssystemen).

    Der Bootvorgang dauert keine halbe Minute (vorher teils mehr als 5min!).

    Ich habe bei Liebhabereiprojekten auf Basis von C++17 beim Kompilieren weniger Änderungen feststellen können, wobei ich denke, dass der Spielkram weniger komplex ist, als das bei @Mechanics hinterliegende Projekt der jüngsten Nachricht.

    Falls Interesse besteht, kann ich genaue Vergleichswerte anfertigen. Ansonsten kann ich jedem Suchmaschinenbesucher hier sagen, dass vor der Verwendung von JetBrains-IDEs eine SSD angeschafft werden sollte.


Log in to reply