Flaschenhals bei Laden von Software

[jusaca]

SSDs haben gegenüber HDDs einen enormen Schub bei der Ladegeschwindigkeit von Programmen gebracht, aber unterhalb der SSDs unterscheiden sich diese kaum. Selbst moderne SSDs mit modernen Schnittstellen sind nicht wirklich messbar schneller als schon relativ alte SATA-SSDs, obwohl sich die Datenrate deutlich erhöht hat. Dies wird stets damit erklärt, dass SSDs nun einfach nicht mehr den Flaschenhals beim Laden von Programmen darstellen.
Meine Frage lautet daher nun: Was ist denn dann mittlerweile der Flaschenhals beim Laden von Programmen? Die CPU ist jedenfalls beim Start von Photoshop nicht wirklich ausgelastet, die SSD scheint ja angeblich nciht zu limitieren und trotzdem muss man 6s warten. Sicherlich ist das keine lange Zeit und die Geduld hat sicherlich jeder - aber hier geht es ja um den technischen Aspekt. Woher kommt diese "lange" Ladezeit und wie ließe diese sich weiter reduzieren?

Viele Grüße

 

[rg88]

Es ist immer noch die SSD, voraussgesetzt die CPU ist schnell genug, dass nichts ausbremst. Ist natürlich immer ein Zusammenspiel, weil die Daten ja nicht einfach von der Platte in dem RAM kopiert werden und gut ists.

Die Leseraten mit 500MB/s aufwärts beziehen sich auf große Dateien. Du öffnest aber zusammen mit dem Programm eine Unmenge anderer kleiner Dateien mit, seien es exterene Bibliotheken, Konfigdateien, whatever. Hierbei bricht eine HDD enorm ein, dass teilweise nur noch Datenraten im KB/s Bereich zustande kommen. Aber auch eine SSD bricht bei solchen Daten entsprechend ein, nur weniger krass.

Wenn du sehen willst wie schnell der PC ohne SSD-Einschränkungen arbeitet, kannst du dir ein RAM-Drive einrichten und dort die Software (flüchtig) installieren. Dann begrenzt quasi nur noch CPU und RAM

Zusätzlich nimmt natürlich das Betriebssystem auch immer noch etwas Leistung weg, die Software läuft ja nicht nativ auf der CPU direkt, sondern mittels der OS-Schnittstellen. Die Resssourcen und Rechenzeit muss erstmal allokiert und zugewiesen werden. Auch das dauert in Summe eine messbare Zeit, obwohl es rasend schnell geht.
Ebenso bremsen Sachen wie Virenscanner das ganze nochmal enorm aus.

 

[r4yn3]

Entweder die immer noch "lahme" Zugriffszeit von SSDs von vielen kleinen Daten, siehe 4K Transferraten, oder aber eben zahlreiche kleine Packages die dann von der CPU nicht schnell genug entpackt werden können.

Meine These, um das zu beobachten wäre ja, wenn man ein Programm ein zweites mal startet, sollte es ja bereits im RAM gecached sein. Wenn es trotz Cache immer noch nicht schneller startet dann sollte es wohl an der CPU liegen. Korrigiert mich bitte wenn ich falsch liege.

 

[xxMuahdibxx]

Meine These, um das zu beobachten wäre ja, wenn man ein Programm ein zweites mal startet, sollte es ja bereits im RAM gecached sein. Wenn es trotz Cache immer noch nicht schneller startet dann sollte es wohl an der CPU liegen. Korrigiert mich bitte wenn ich falsch liege.

Jup falsch.

Einfach weil man die wenigsten Programme mehrmals öffnen kann.
Weiterhin wenn es 2 "Clients" sind dann arbeitet jeder mit seiner eigenen Speicherkonfiguration weil man dort ja auch Daten eingeben können muss die Unabhängig verarbeitet werden ( 2 Excel Fenster sind nicht das gleiche ).
Ansonsten ist die Frage der Datenintrigität wichtig.

@ TE ja es begrenzt immer noch die SSD ... maximale Datenbandbreite ist ja nicht das was wirklich genutzt wird.

Einfach Bücherreisystem ... bringe 10 Brockhausbände a 500 Seiten = schnell da sie einfach nebeneinander stehen.
oder bringe 500 Heftchen die alle 10 Seiten haben ... das Suchen dauert einfach länger auch wenn du alle 500 Positionen der Heftchen kennst. Da bringt es nichts wenn die Tür der Bibo 300 Meter breit ist.

 

[r4yn3]

Natürlich kann man. Programm schließen und nochmal öffnen. Oft wird beim zweiten mal nichts von der SSD gelesen, dennoch startet es nicht schneller.

 

[jusaca]

Aber es haben bei SSDs doch nicht nur die sequentiellen Übertragungsraten zugenommen, auch 4k-Zugriffe sind mit der Zeit bei den SSDs schneller geworden. Daher verwundert es mich etwas, dass sich dieser Zugewinn in den Tests nicht deutlicher abbildet.

 

[rg88]

@jusaca: Dennoch sind die sequentiellen Leseraten immer noch unterirdisch, wenn man diese mit einem wirklich schnellem Speicher wie dem RAM vergleicht. Kommt immer drauf an, was man als Maßstab nimmt. Im Vergleich zu einem mechanischen Speicher wie einer HDD oder einer CD/DVD ist eine SSD unglaublich schnell, im Vergleich zu RAM oder gar Cache innerhalb der CPU ist jede SSD arschlahm.

 

[Fragger911]

Aber es haben bei SSDs doch nicht nur die sequentiellen Übertragungsraten zugenommen, auch 4k-Zugriffe sind mit der Zeit bei den SSDs schneller geworden. ...

Was vergleichen wir hier, SSDs einer oder aufeinander folgender Generationen ODER die erste Consumer SSD vs eine aktuelle 960 PRO?
Je nach Programm sind die Zugriffsmuster auf den Speicher schon unterschiedlich, hinzu kommt welche Daten gelesen werden, wie stark diese gepackt sind (txt-File vs hochkomplexes Archiv), wie das Entpacken programmiert ist & läuft...

Und das Photoshop nicht gut mit den Kernen/Threads skaliert ist ja hinreichend getestet worden.

Die 4k-Leistung ist selbst bei aktueller Hardware, wie synthetische Tests ja zeigen, mehr als unterschiedlich, sagt aber wiederum nicht wirklich viel zur Alltagsleistung aus. Die Hersteller haben gelernt und die Firmware entsprechend darauf abgestimmt.

 

[xxMuahdibxx]

und was bringt einem die 4k Leistung wenn man noch kleinere Datein ziehen muss ?

oder das Programm aus einer 5 GB Datei einen Zeilencode von 20 Byte braucht ( überzogen ) Cabinet Datein halt. Und wieviel er deswegen lesen muss.

 

[PHuV]

Wenn du sehen willst wie schnell der PC ohne SSD-Einschränkungen arbeitet, kannst du dir ein RAM-Drive einrichten und dort die Software (flüchtig) installieren. Dann begrenzt quasi nur noch CPU und RAM

Nicht so ganz. Ich habe mal vor Jahren Tests mit einer Linux-VM in HDD, SSD und Ramdisk gemacht. Ergebnis: Zwischen SSD und Ramdisk trotz mehrfacher Performance kaum ein Unterschied.

Es werden intern so viele Prozesse gestartet, die alles mögliche prüfen und testen. Da liegt der Flaschenhals eher in der Architektur der Anwendungen.

und was bringt einem die 4k Leistung wenn man noch kleinere Datein ziehen muss ?

oder das Programm aus einer 5 GB Datei einen Zeilencode von 20 Byte braucht ( überzogen ) Cabinet Datein halt. Und wieviel er deswegen lesen muss.

Korrekt. Gerade kleine Dateien sind eine riesigen Bremse. Beispielsweise bricht ein 10Gbit-Netzwerk selbst von Ramdisk zu Ramdisk per Freigabe auf 10-15 MB/s ein, wenn viele kleine Dateien kopiert werden.

 

[xxMuahdibxx]

warum auch es wird bei jeder Datei ein CRC check gemacht ... ob sie auch korrekt angekommen ist ... ergo je kleiner desto mehr Overhead.

 

[rg88]

@PHuV: Bitte die Zitate nicht aus dem Kontext reissen. Du sagst nichts wirklich anderes als ich. Ich sage damit nur, dass man die SSD damit aus der Gleichung nimmt. Dass es noch andere Flaschenhälse gibt, habe ich ja, glaube ich, deutlich aufgeführt.

 

[jusaca]

Mit dem aktuellen Test zu Intels Customer-Version des 3D XPoint Speichers (https://www.computerbase.de/artikel/storage/intel-optane-ssd-900p-test.61536/) ist ja auch das Limits der Latenzen und Random-Zugriffe ein gutes Stück besser geworden - trotzdem bringt sie in der Praxis kaum Geschwindigkeitsvorteile beim Laden von Software...

 

[kevdotcom]

Also wenn ich meine 2012er SanDisk SSD mit dem SSD-Riegel in meinem 2014er MacBook Pro vergleiche ist das schon ein sehr krasser Sprung.

Weiß nicht, was du da vergleichst, aber der Unterschied zwischen SSDs ist krass, wenn du nicht gerade einen uralten Prozessor hast.

Vielleicht nicht unbedingt beim Starten von Programmen (wobei mir da auch genug einfallen würden *hust* DiRT Rally *hust*), aber alles was mit großen Dateien zu tun hat ist viel schneller als vor ein paar Jahren.

 

[Holt]

Der Flaschenhals ist die CPU und da vor allem die Singlethreadperformance, denn es ist eben längst nicht jede SW auch gut parallelisiert und dazu gehören auch viele Teile von Windows, auch dessen I/O Subsystem. Dort ist meines Wissens vieles gar nicht parallelisiert. Das die Singlethread Performance immer noch so wichtig ist, sieht man nur nicht so leicht beim Blick auf die CPU Auslastung im Task Manager, denn der Taskscheduler von Windows schiebt die SW Threads nämlich viele male pro Sekunde zwischen den Kernen der CPU hin und her und zeigt nur 100% an, wenn alle Kerne (reale und virtuelle bei SMT) voll ausgelastet sind. Wenn als nur ein SW Thread aktiv ist, dann kann der bei Deiner Dualcore CPU maximal 50% Auslastung erzeugen und auch die Ansicht der Auslastung der einzelnen Kerne wird dann nur so etwas über 50% anzeigen. Bei 4 Kernen, egal ob reale oder per SMT virtuelle, sind es nur noch 25%, bei 8 dann 13% und bei noch mehr Kernen fällt die Maximalauslastung durch einen SW Threads dann kaum noch im Grundrauschen der Auslastung durch die ganzen Windowssystemthreads auf.

Dies wissen aber viele Leute nicht und daher fällt ihnen auch gar nicht auf wenn nur ein Thread und damit die Singlethread Perfomance der CPU der Flaschenhals ist. Bei Linux ist dies viel leichter zu erkennen, hier zeigt top 100% Auslastung pro Kern an, wie hier beim 8 Xeon-D meines Heimservers, auf dem ich gerade eine Singlethreadlast laufen lasse:

%Cpu0 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu1 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu2 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu3 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu4 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu5 : 0,0 us, 14,5 sy, 0,0 ni, 85,5 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu6 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu7 : 86,9 us, 11,9 sy, 0,0 ni, 0,0 id, 0,0 wa, 0,0 hi, 1,2 si, 0,0 st
%Cpu8 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu9 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu10 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu11 : 0,0 us, 1,2 sy, 0,0 ni, 98,8 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu12 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu13 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu14 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu15 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem : 32675052 total, 254612 free, 3359220 used, 29061220 buff/cache
KiB Swap: 1409020 total, 1409020 free, 0 used. 28490408 avail Mem

Auch verschiebt der Task Scheduler von Linx die Thread sehr nach vielen Sekunden von einem Kern auf den nächsten, wie es hier gerade zu sehen ist:
%Cpu0 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu1 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu2 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu3 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu4 : 0,0 us, 3,0 sy, 0,0 ni, 96,0 id, 1,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu5 : 0,0 us, 10,3 sy, 0,0 ni, 89,7 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu6 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu7 : 47,2 us, 8,0 sy, 0,0 ni, 42,9 id, 1,0 wa, 0,0 hi, 1,0 si, 0,0 st
%Cpu8 : 35,0 us, 5,3 sy, 0,0 ni, 59,7 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu9 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu10 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu11 : 0,0 us, 0,3 sy, 0,0 ni, 99,7 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu12 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu13 : 0,0 us, 0,3 sy, 0,0 ni, 99,7 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu14 : 0,0 us, 0,3 sy, 0,0 ni, 99,7 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
%Cpu15 : 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st

Hier sieht man also schön wie ein Thread der SW einen Kern der CPU auslastet, während dies beim Windows Task Manager eben leider kaum erkennbar ist. Benchmarks erzeigen vielleicht voab noch die nicht komprimierbaren Testdaten, fahren dann aber nur I/O Zugriffe und interessieren sich nicht für die Daten die gelesen werden und müssen auch nicht weiter was machen um Daten schreiben zu können. Reale Anwendungen müssen die Daten die sie Lesen aber mehr oder weniger aufwendig verarbeiten, z.B. entpacken, darauf Berechnungen ausführen oder bei Programmcode diesen dann abarbeiten und das alles erfolgt oft nicht parallel. Daher hängt es auch so vom System und der Nutzung ab, wie sehr man von einer schnelleren SSD profitiert!