Sammelthread Kaufberatung und Fragen zu SSDs (2)

[Eggcake]

Finde leider keine Präsentationen zur IDF 2011 in Peking, nur PDFs. Irgendwie muss man den direkten Link kennen - von der IDF-Seite aus komme ich nicht drauf...

 

[Holt]

@Holt
Es ging um das Testen bzw. die Aussagekraft von synthetischen Benchmarks bei SSDs, um nichts anderes.

Natürlich möchte Intel die Aussagekraft synth. Benchmarks herunterspielen, weil sie da im Verhältnis zur Praxis ehr schlechter abschneiden. Aber wie soll man die Performance einer SSD denn sonst beurteilen / vergleichen? Praxistests sind gerade bei aktuellen, schnellen SSD noch weniger geeignet, weil eben der Einfluss von SSD auf die Ausführungszeit bei den meißten Aufgaben so gering geworden ist. Das Thema habe ich ja gerade erst mit Moros durchgekaut.

Und das interessiert die Kunden sehr wohl bzw. sollte jeden hier interessieren, der sich auch nur ansatzweise mit SSDs beschäftigen will.

Wer sich mehr als nur ansatzweise mit SSDs beschäftigt, der weiß das sowieso.

Sie (Intel) zeigen deutlich, dass im Gegensatz zu HDDs die synthetischen Tests massiv an Aussagekraft verloren haben.

Das hängt sehr vom Benchmark und teils auch von dem Controller der SSD ab. Klar ist es total sinnfrei die Übertragunsraten einer SSD über die gesamte Kapazität zu messen. Was bei HDDs noch schön die Unterschiede zwischen den inneren und äußeren Zylindern aufgezeigt hat, bringt bei SSDs eine Schreiblast die niemals in der Realität erreicht wird (außer man spielt ein Disk-Image auf, aber wieoft passiert das). Das Intel sich gegen solche synth. Benchmarks ausspricht kann ich sehr gut nachvollziehen und unterstütze es auch.

Bei HDDs korrelieren die synthetischen Benchmarks mit diversen Traces fast 1:1 - ganz im Gegensatz zu SSDs.

Auch hier bringt es nicht pauschal von synth. Benchmarks zu reden ohne Ross und Reiter zu benennen. ASS spiegelt mit seinen Schreibzugriffen die Performance einer SSD durchaus gut wieder, da die Belastungen so auch wirklich passieren können, mit Ausnahme des 4k_64 tests vielleicht, bei dem eine QD von 4 vielleicht realisitischer und aussagekräftiger wäre. Auf einer HDD kann man da aber schon mal ganz anderen Ergebnisse bekommen, je nach Fragmentierung und Positionn der Testdaten auf der Platte (innere oder äußere Zylinder).

Das ist das eine. Das andere ist eben, dass eine SSD mehr macht als nur lesen, suchen und schreiben. Und doch, das sollte den Kunden interessieren, denn genau deshalb schwankt die Performance diverser SSDs so stark.

Wenn die Performance von SSDs sehr schwankend ist, dann ist das aber eben kein Kundenvorteil oder? Mit den richtigen Benchmarks kann man auch das erkenne, denn CrystalDiskMark zeigt z.B. die Spitzenwerte aus mehreren Messeungen und ASS den Durchschnittswert. Je stärker beide Angaben (bei gleichen Tests) abweichen, umso stärker schwankt offenbar die Leistung einer SSD.

Ebenso sollte es den Kunden interessieren, wie die SSD läuft, wenn sie x-Mal beschrieben wurde. Das sind alles Dinge, die halt mit SSDs neu hinzukommen.

Das stimmt, aber von den SF SSDs mal angesehen, verhalten sich die meißten in der Praxis solange wie im Neuzustand, wie sie getrimmt und nicht gefoltert werden. Eine HDD verliert ja in der Praxis alleine durch die Fragmentierung auch deutlich an Leistung, auch wenn das nicht wirklich ihre Schuld ist sondern vom Filesystem verursacht wird.

Und der "Test" auf XS ist ja wohl das komplette Gegenteil eines synthetischen Tests (auch wenn das Tool "synthetisch" Daten schreibt)

Genau das ist der Punkt, es gibt viele Disk-Benchmarks und längst nicht alle sind für SSDs geeigent, werden aber trotzdem sehr von in Reviews eingesetzt und dann kommen die Schreiberlinge auch noch zu falschen Schlüssen. Nicht jeder Benchmark sagt eben das aus, was er auf dem Bildschirm anzeigt. Das beste Beispiel ist ATTO, der bei SF SSDs eben nicht dieGeschwindigkeit anzeigt, mit der die SSD Daten liest oder schreibt, denn Daten sind Informationen und ATTO schreibt eben gerade nicht die Menge an Informationen beim Test die es angibt.

Wenn die SSD während des (Nach-)Ladens von Spielen laut Intel sogar noch "underutilized" ist, hat jemand
ne Idee was dann der Flaschenhals in diesen Situationen sein könnte? Der Rest des Systems (24GB RAM etc.) wirkt ja auch nicht gerade schwachbrüstig

Da ist kein Flaschenhals, es gab ja keine Verzögerungen mehr mit der SSD. Mit "underutilized" wollten sie nur klarstellen, dass die SSD auch noch mehr Daten hätte liefern können. Die ganze Veranstaltung ist aber klug gemacht, da wird den Spieleentwicklern nicht nur gesagt, sie können bessere (besser aussehenden, flüssiger laufende) Spiele anbieten, wenn sie davon ausgehen, dass diese auf SSDs installiert sind. Nein man zeigt ihnen auch gleich die Vorteile wenn sie SSDs in ihren eigenen Entwicklungsrechner einsetzen und damit werden sie dann schon automatisch die Spiele in die Richtung entwicklen

 

[CBmurphy]

Da ist kein Flaschenhals, es gab ja keine Verzögerungen mehr mit der SSD.

Na klar gab es die noch, siehe StarCraft II Game Load Time Traces. Die Hitches während des Spiels,
die dank SSD ausbleiben, meinte ich nicht.

Mit "underutilized" wollten sie nur klarstellen, dass die SSD auch noch mehr Daten hätte liefern können.

Genau – und das hat sie eben nicht getan, weil es noch einen anderen Flaschenhals gibt
Es sei denn, wie oben als Möglichkeit angegeben, dass künstliche Timeouts eingebaut sind.

 

[Holt]

Die Hitches während des Spiels,
die dank SSD ausbleiben, meinte ich nicht.

Auf die hatte ich mich bezogen.

Genau – und das hat sie eben nicht getan, weil es noch einen anderen Flaschenhals gibt
Es sei denn, wie oben als Möglichkeit angegeben, dass künstliche Timeouts eingebaut sind.

Nein, weder Flaschenhals im I/O System noch Timeouts, das Spiel muß die Daten ja auch verarbeiten und kommt dann eben erst irgendwann an den Punkt, wo es mehr Daten laden will, deshalb werden auch die Ladezeiten nicht noch kürzer. Darum ging es ja im Vortrag, dass Entwickler genau diese Abläufe noch paralleler gestallten können, also nicht z.B. erst die Texturen einladen wenn die Musik geladen wurde sondern beiden parallel. Bei DVDs oder HDDs dauert das parallele Laden dann wegen der Kopfbewegungen viel länger, bei SSDs geht es i.d.R. schneller, zumindest wenn NCQ unterstützt wird.

 

[Eggcake]

Ich habe noch einige Tests durchgeführt. Getestet wurde die Ladezeit von Starcraft 2, jeweils mit einem Q9550@2GHz und 3.76GHz.

Restliche Hardware:

Intel G2 80GB
Gigabyte EP45 Extreme
4x2GB Mushkin EP8500@~1066MHz



Gemessen wurde, wie schnell diverse Teile des Spiels laden.

• Exe: Beschreibt wie lange es dauert, bis der Loginscreen erscheint nach dem Öffnen der exe
• Map: Beschreibt, wie lange es dauert, bis die Mapliste angezeigt wird, sobald ein SP-Spiel erstellt werden soll
• Game: Beschreibt, wie lange das Spiel schlussendlich lädt ("Ladescreen")

Beachtet werden sollte, dass bei der Exe auch von der SSD gelesen wird - in kleinerem Umfang. Die Mapliste wird ausschliesslich von der SSD gelesen - deshalb ist die HDD-Zeit ausgeblendet. Das "Game" wird fast ausschliesslich von der SSD respektive von der HDD geladen.
Das OS befand sich immer auf der SSD. Der Spieleordner entweder auf der HDD oder der SSD. Zusätzlich wurde nach der ersten Messung das Spiel nochmals gestartet um zu sehen, wie schnell es lädt wenn es bereits im RAM ist. Sobald das Game ein zweites Mal gestartet wird, wird nichts mehr von der SSD/HDD gelesen (ich bezeichne insgesamt 7MB Reads innerhalb der gesamten Zeitspanne als "nichts" - bei der HDD sind es nicht mal 1MB). Die Daten befinden sich also wirklich im RAM.






Resultate:

• Unschwer zu erkennen sind die Differenzen bei Exe und Game. Die SSD vermag die Ladezeiten gegenüber der HDD etwa zu halbieren.
• Wie erwartet sind die Ladezeiten unabhängig vom Speicherort der Daten praktisch gleich, sobald die Daten im RAM sind.
• Die SSD lädt die Daten fast gleich schnell, wie wenn sie bereits im RAM sind - die Differenz ist extrem klein.

Nun wollte ich auch noch vergleichen, wie stark der Einfluss der höheren Taktung ist. 100% bedeuten hier jeweils die Ladezeit bei 2GHz in der entsprechenden Kategorie. Das heisst die Balken zeigen, wie stark sich die Ladezeit mit der erhöhten Taktung verringert hat im Vergleich zu 2GHz. Die Daten für den RAM wurden hier gemittelt, da die Unterschiede zwischen HDD+RAM und SSD+RAM vernachlässigt werden können und nach Betrachtung der Traces klar wurde, dass nichts mehr von den Laufwerken geladen wird. Der rote Balken zeigt an, wie stark sich die Ladezeiten theoretisch durch die Taktung verringern könnten.



Eine andere, eventuell verständlichere Darstellung des gleichen Sachverhalts: der Takt wurde auf 188.6% des Ursprungswerts erhöht. 188.6% sind also 100% des erreichbaren Speedups der Ladezeiten. Die Grafik zeigt also, wie stark die einzelnen Ladephasen und Laufwerke von diesem Speedup profitieren können/wieviel davon in kürzere Ladezeiten umgesetzt werden kann.

• Bei Game, wo eindeutig nur von der HDD geladen wird, kann diese kaum von der erhöhten Taktung profitieren. RAM ist nahe am Optimum, die SSD nahe dran.
• Bei Map handelt sich um eine extrem stark CPU-limitierte Stelle. Die SSD ist hier nahe am Optimum. Wieso RAM nicht tiefer ist, kann ich mir nicht erklären - womöglich wären weitere Samples notwendig.

Sodele, dies nur wiedermal ein kleiner Test von mir, weil mir grad langweilig war Es soll einerseits zeigen, dass die SSDs, wie bereits im PDF von Intel beschrieben, nahe am Optimum sind - selbst wenn die Daten aus dem RAM geladen werden, werden die Ladezeiten kaum noch verkürzt. Zudem kann man mit einer SSD viel stärker von einer erhöhten Taktung profitieren, als mit einer HDD. Da die Ladezeiten beim RAM nicht perfekt mit der Taktung korrelieren, ist davon auszugehen, dass weitere Elemente einen starken Einfluss auf die Ladezeit haben.
Grundsätzlich gilt aber: eine schnellere SSD bringt nichts, da selbst RAM kaum schneller ist. ich konnte also die Resultate von Intel bei einem Spiel nachvollziehen und überprüfen und komme zum gleichen Schluss - gut gemacht Intel!



@Holt
Wie gesagt: bei HDDs konnte man die reale Leistung eigentlich perfekt mit einigen wenigen synthetischen Benchmarks beschreiben, bei SSDs ist dies nicht mehr so. Das ist ein Fakt, und genau das sagt die Folie aus, Bei HDDs kann man den Iometer nehmen, einige Tests durchziehen und diese korrelieren normalerweise perfekt mit echten Traces. Bei SSDs kann man das vergessen. Zudem habe ich sie, wie bereits gesagt, eher als Spass gepostet. Die interessanteren Folien sind die anderen beiden.

 

[CBmurphy]

Auf die hatte ich mich bezogen.

Das dachte ich mir schon, deshalb auch die Richtigstellung
Siehe "SSD underutilized – Game loads could be faster" @ 5'12''

Nein, weder Flaschenhals im I/O System noch Timeouts, das Spiel muß die Daten ja auch verarbeiten und kommt dann eben erst irgendwann an den Punkt, wo es mehr Daten laden will, deshalb werden auch die Ladezeiten nicht noch kürzer.

Verstehe ich nicht. "Verarbeiten" bedeutet doch nichts anderes, als dass die CPU beschäftigt ist. Würde die Verarbeitung schneller gehen, würden auch die als nächstes benötigten Daten früher geladen, da ja die SSD nicht der Flaschenhals ist ... sondern, wie es scheint, eben die CPU (wie auch Eggcake oben vermutete [EDIT: bzw. zwischenzeitlich bewiesen hat]), denn auch die I/O-Kanäle scheinen ja noch reichlich Luft zu haben, siehe Slide 21 @ 18'05''.

Darum ging es ja im Vortrag, dass Entwickler genau diese Abläufe noch paralleler gestallten können, also nicht z.B. erst die Texturen einladen wenn die Musik geladen wurde sondern beiden parallel.

Selbst wenn die Daten sequentiell geladen werden, ist immer irgendeine Komponente dafür verantwortlich,
wie schnell dies maximal geschehen kann – und das schwächste Glied in der Kette dieser Komponenten ist
der Flaschenhals. Mit der Parallelisierung der Ladevorgänge verteilt man die Last auf mehrere Threads,
so dass die Bandbreite der SSD und eine Multi Core CPU besser ausgenutzt werden – doch dasselbe
wäre auch single-threaded mit einem höheren Takt pro Kern erreichbar.

EDIT: q.e.d.

 

[stw500]

Ich habe noch einige Tests durchgeführt...

Sehr coole Tests Eggcake, vielen Dank!

 

[CBmurphy]

Wieso RAM nicht tiefer ist, kann ich mir nicht erklären - womöglich wären weitere Samples notwendig.

Da würde mich auch ein Nachtest interessieren, denn angesichts der schön gleichmäßigen Verteilung
bei Exe und Game und vor allem in Relation zum SSD-Wert und HDD-Wert bei Map schaut der RAM-Wert irgendwie schon verdächtig nach Messfehler (EDIT: oder Vertauschung der Werte/Referenzierung?) aus

EDIT: Kann es sein, dass bei Map der RAM-Wert der eigentliche HDD-Wert, der HDD-Wert der eigentliche SSD-Wert, und der SSD-Wert der eigentliche RAM-Wert ist? Dann würden die Relationen wieder stimmen

 

[Eggcake]

Also ich habe jede Messung 3x durchgeführt. Die Werte sind definitiv nicht vertauscht o.ä. Es gibt aber ziemliche Schwankungen, insbesondere bei den RAM Durchläufen. Um wirklich zuverlässige Aussagen zu machen wären wohl 5 oder mehr nötig."Game" war sehr konsistent. Da hätte im Prinzip ein einziger Durchgang gereicht (Unterschiede im Bereich von 1-2 Zehntelsekunden). Bei den anderen hatte ich fast immer mal einen etwas höheren Wert. Zum Beispiel 8s, 8.2s und 9.8s. Die sind kaum "falsch", nur schwanken die Zeiten halt tatsächlich ein wenig. Möglich ist auch, dass z.B. beim ersten Öffnen eine geringe Verzögerung entsteht weil zu Blizzard telefoniert wird (ich als User sehe nichts davon). Das sind halt alles Dinge, die die Messung beeinflussen. Ich würde mir ja 10 Durchläufe wünschen, nur würde ich dann die 50'000 Power cycles schneller erreichen als mir lieb ist


Was aber beachtet werden sollte bei dem Graphen: er zeigt ja nicht, dass der RAM langsamer ist als die anderen. Er zeigt, dass er von der Taktung weniger profitiert hat. Wenn man die absoluten Werte betrachtet, hat er bei 2GHz einen grösseren Vorsprung zur SSD - dieser schrumpft bei 3GHz, wo die SSD fast gleich schnell ist. Womöglich bremst hier schlicht etwas anderes und hindert den RAM an einer zusätzlichen Reduktion der Geschwindigkeit.

Noch kurz was zur Charakteristik der Ladephasen - wie gesagt, OS ist immer auf der SSD, für was anderes fehlt mir die Zeit, deshalb ist insbesondere "Exe" im Vergleich zur HDD mit Vorsicht zu geniessen (bei Map und Game ist's klar (Map nur SSD, Game nur SSD/HDD), bei der Exe wird einiges auch von der SSD geladen:

Exe (HDD)
HDD: 3539 Reads (~200MB)
SSD: 2058 Reads (~32MB)

Exe (SSD)
Siehe oben (alles SSD)

Map (SSD/HDD)
SSD: 5227 Reads (~138MB)

Game (SSD/HDD)
SSD/HDD: 4052 Reads (~108MB)

 

[uNrEL2K]

Danke für alles Eggcake (Link zu den Intel-Vids & dein Test) Da bin ich erstma mit beschäftigt ^^

 

[CBmurphy]

Was aber beachtet werden sollte bei dem Graphen: er zeigt ja nicht, dass der RAM langsamer ist
als die anderen. Er zeigt, dass er von der Taktung weniger profitiert hat.

Ah ja, das habe ich dabei völlig übersehen ... und irritiert hat es dich selbst ja auch zunächst.

Die gleichmäßige Verteilung in den anderen beiden Wertegruppen war eben zu "verlockend"

 

[Merlin-.-]

Schöne Tests mal wieder!
"SSDs sind nahe dran am RAM"

Bestätigen meinen Eindruck von damals (2009), als ich Crysis fast ganz flüssig gespielt habe "ohne RAM", dank SSD.

https://www.computerbase.de/forum/threads/sammelthread-kaufberatung-ssds.602017/page-79#post-6537774

 

[Eggcake]

Ah ja, das habe ich dabei völlig übersehen ... und irritiert hat es dich selbst ja auch zunächst.

Die gleichmäßige Verteilung in den anderen beiden Wertegruppen war eben zu "verlockend"

In der Tat

 

[CBmurphy]

@Eggcake: Wo ich mich grad schon am dritten Graphen verbissen habe ...

Was hältst du von der Idee eine alternative Darstellung auszuprobieren,
die nicht die Messwerte @ 3,76 GHz / die Messwerte @ 2,00 GHz darstellt,
sondern die Messwerte @ 2,00 GHz / die Messwerte @ 3,76 GHz ?

Dann hätte man statt "Prozent der benötigten Zeit @ 3,76 GHz vs. 2,00 GHz"
quasi einen anschaulichen "Beschleunigungsfaktor @ 3,76 GHz vs. 2,00 GHz",
was dann rein optisch auch mehr dem dargestellten Effekt entspräche

 

[Holt]

Verstehe ich nicht. "Verarbeiten" bedeutet doch nichts anderes, als dass die CPU beschäftigt ist. Würde die Verarbeitung schneller gehen, würden auch die als nächstes benötigten Daten früher geladen, da ja die SSD nicht der Flaschenhals ist ... sondern, wie es scheint, eben die CPU (wie auch Eggcake oben vermutete [EDIT: bzw. zwischenzeitlich bewiesen hat]), denn auch die I/O-Kanäle scheinen ja noch reichlich Luft zu haben, siehe Slide 21 @ 18'05''.

Nur ist das dann letztlich kein Flaschenhals, denn der Begriff kommt ja aus dem Vergleich mit einer Flasche, die man umdreht und aus der der Inhalt dann eben langsamer ausläuft als aus einem Becher, eben weil die Flasche oben einen Hals hat, der den Durchfluss limitiert. Auch aus dem Becher störmt das Wasser nicht unendlich schnell heraus, aber es wird eben nicht irgendwo gebremst.

Wenn die CPU die Daten so schnell bekommt wie sie diese braucht um sie zu verarbeiten, dann ist das I/O System kein Flaschenhals und es gibt dann auch keinen Flaschenhals im System, denn die CPU ist dann keine Flaschhals sondern das Element, welches die Performance bestimmt.

Selbst wenn die Daten sequentiell geladen werden, ist immer irgendeine Komponente dafür verantwortlich,
wie schnell dies maximal geschehen kann – und das schwächste Glied in der Kette dieser Komponenten ist
der Flaschenhals.

Eben nicht, denn von einem Flaschenhals spricht man nur, wenn das performance bestimmende Bauteil ausgebremst wird. Irgendwas hat immer eine endliche Geschwindigkeit, in einem Rechner ist es die CPU und wenn die Leistung des Gesamtsystems nur noch von der Geschwindigkeit der CPU abhängt, dann wird es nirgens gebremst und hat keinen Flaschenhals.

Mit der Parallelisierung der Ladevorgänge verteilt man die Last auf mehrere Threads,
so dass die Bandbreite der SSD und eine Multi Core CPU besser ausgenutzt werden – doch dasselbe
wäre auch single-threaded mit einem höheren Takt pro Kern erreichbar.

Nur ist eben ein höhrerer Takt pro Kern immer schwerer erreichbar und man kann auch nicht jedes Problem beliebig oder auch nur überhaupt parallelisieren. Stell Dir vor ein Spieler öffnet im Spiel eine Waffenkiste und Du kannst eben nicht alle Daten im Speicher vorhalten. Dann mußt Du erstmal nachladen, was da drinne ist und danach die Geometrien und Texturen der Waffen laden. Geometrien und Texturen kannst du parallel laden, aber erst wenn Du weißt für welche Waffen, sonst dauert es ggf. zu lange oder braucht zu viel Speicher, wenn Du das für 100 verschieden Waffen machst von denen nur 3 in der Kiste liegen.

 

[Eggcake]

@Holt

Natürlich ist die CPU der Flaschenhals, wenn einzig diese die Geschwindigkeit des Systems bestimmt. Das ist ja quasi die Definition eines Flaschenhalses. Von einem Flaschenhals spricht man, wenn ein System von einer Komponente (oder mehreren) ausgebremst wird bzw. diese Komponente(n) die Performance des Systems limitieren. Wenn die CPU das "performance bestimmende Bauteil" ist, dann heisst das nichts anderes, als dass das System von der CPU ausgebremst wird - denn dies impliziert, dass die restlichen Komponenten schneller arbeiten könnten. Wäre dies nicht der Fall, dann wäre die CPU auch nicht das "performance bestimmende Bauteil".

 

[uNrEL2K]

Ihr meint ja beide/edit: alle drei eigentlich das selbe. die Frage ist nur, ob Flaschenhals der passenden Ausdruck ist.
Meiner Meinung nach schon, denn die SSD könnte z.B. noch mehr Daten pro Sekunden transferieren, wenn die CPU schneller wäre. Es könnte mehr Wasser auf einmal entweichen, hätte der Hals der Flasche einen größeren Durchmesser.

Die SSD ist ja erstmal unlimitiert von der CPU, denn bencht man sie, kann man alles aus der SSD rausholen, nur ist die Leistung praktisch nicht abrufbar, da die CPU "bremst". Wäre es so, dass bei Laden eines Level 500 MB/s abgerufen würden, und die CPU genau diese Datenmenge die Sekunde verarbeiten könnte, dann wäre das System ausgeglichen, also gebe es keinen Flaschenhals mehr, jedenfalls, was diese spezielle Praxismessung angeht.

 

[Eggcake]

Ich vergleich's halt immer mit z.B. GPU oder CPU Benches in Spielen. Man erlebt ja alljährlich dass die besten Grafikkarten oft sehr ähnliche FPS-Werte erreichen bzw. sogar ein "Hard Limit" ausmachbar ist. Dann spricht man jeweils auch von einem CPU Bottleneck oder einem CPU Limit. Das ist hier ja im Prinzip genau dasselbe...und ob man's Limit oder Flaschenhals nennt ist nun wirklich Nebensache.

@CBMurphy
Ich hatte eine bessere Idee (oben eingefügt) - das war eigentlich auch mein ursprünglicher Gedanke. Ich hoffe man versteht, was ich damit ausdrücken will

 

[CBmurphy]

Nur ist das dann letztlich kein Flaschenhals

Natürlich ist es letztlich kein Flaschenhals, da wir hier über Computer sprechen, und nicht über Leergut!

"Flaschenhals" ist Synonym von "Engpass" und im systemtechnischen Sinne die Bezeichnung für die leistungsbestimmende Komponente bzw. (wie oben schon beschrieben) das schwächste Glied in der Kette und das ist hier eindeutig die CPU. Alles andere ist, mit Verlaub, reine Wortklauberei, und du müsstest – weil dies
nun mal der allgemein gängige Begriff dafür ist – dasselbe auf tausende anderer Posts allein in diesem Forum antworten, was du aber ja auch nicht tust, weil du dort vielleicht nicht von etwas anderem ablenken willst (?).

Eben nicht, denn von einem Flaschenhals spricht man nur, wenn das performance bestimmende Bauteil ausgebremst wird.

Nicht ganz: Das Performance-bestimmende Bauteil ist das, welches den gesamten Rest ausbremst, nicht das, was ausgebremst wird.

Irgendwas hat immer eine endliche Geschwindigkeit, in einem Rechner ist es die CPU

Nicht nur die, sondern alle anderen Komponenten genauso. Es gibt kein Bauteil mit unendlicher Geschwindigkeit, höchstens in der Theorie.

und wenn die Leistung des Gesamtsystems nur noch von der Geschwindigkeit der CPU abhängt, dann wird es nirgens gebremst und hat keinen Flaschenhals.

Das ist ein Widerspruch in sich

Ein "nirgends gebremstes Gesamtsystem" wäre unendlich schnell, was es in der Praxis ja wie gesagt nicht gibt.

Nur ist eben ein höhrerer Takt pro Kern immer schwerer erreichbar

... weshalb ich den Konjunktiv verwendete:

"... doch dasselbe wäre auch single-threaded mit einem höheren Takt pro Kern erreichbar."

... und genau so, wie der Satz da steht, stimmt er auch.

und man kann auch nicht jedes Problem beliebig oder auch nur überhaupt parallelisieren.

Das war nun auch überhaupt nicht mein Thema Ich habe an der Stelle nur auf deinen Hinweis geantwortet, wie die Entwickler die Abläufe optimieren können indem sie parallelisieren, und wiederum meinerseits darauf hingewiesen, dass dies allein dem Zweck dient, die Limitierung durch einzelne Cores zu umgehen – und diese Limitierung ist genau der Knackpunkt bzw. der leistungsbestimmende Faktor bzw. der Flaschenhals bzw. das Nadelöhr bzw. Joe Dalton bzw. whatever

 

[meckswell]

Wahrscheinlich ist der Einbruch der Schreibrate bereits nach der Windowsinstallation ausgelöst, da werden ja 10 oder mehr GB geschrieben. Als ich danach gemessen habe, war die Schreibrate bei 65 MB/s.