Mimir schrieb:
Was ist mit Games? Es wird ja in letzter Zeit sehr stark von SSD gesteamt mit teils hohen Spitzenwerten.
Kompilierte Shader müssen abgelegt und abgerufen werden. CPU Performance ist ebenfalls je nach Engine ein Problem. Gerade UE5 Games leiden unter Traversal stutter wo dann eben sehr kurzzeitig Last spikes auf CPU und I/O seite entstehen. Ja, das Problem ist die Engine, aber ich würde erwarten, dass ein optimierter NVME Storage Stack mit weniger Overhead einer von vielen Bausteinen sein kann, um diese Szenarien zu glätten.
[...]
Bist du dir also ganz sicher, dass ein verringerter CPU Overhead sowie ein etwas höherer Durchsatz hier keinerlei nutzen für Games hat?
Ich kanns nicht sicher beantworten, würde aber nicht ausschließen wollen, dass es was bringt.
Der geringere CPU-Overhead bringt etwas, im Vergleich zu allem was bei Spielen aber sonst auf der CPU abläuft ist es sehr wenig. Die Zugriffsmuster bei Spielen sind schlicht keine 4k RND mit massig Threads. Die Assets moderner Spiele sind heute nahezu durchweg größer als 4K und zufällige Zugriffe vermeidet man nach Möglichkeit. Denn auch mit Optimierung, 1MB Assets in 4kB Häppchen lädt langsamer als 1MB sequentiell. Entsprechend packt man Daten dann auch so, dass 1MB am Stück gelesen werden können.
Faust2011 schrieb:
Hat jemand den verlinkten Microsoft-Blogpost gelesen? Irgendwie wirkt das seltsam, was dort als "Neuerung" verkauft wird, denn dort ist die Rede davon, dass bisher NVMe-auf-SCSI im Treiber übersetzt wurde und damit technisch nur 1 Queue verwendet, während NVMe ein Vielfaches davon unterstüzt. Das zeigt sich dann vor allem in Benchmarks/Anwendungsfälle, die mit mehreren Threads auf die Platte zugreifen, in einem deutlichen Performancevorteil.
Jetzt das "Aber": In den Tests von NVMe-SSDs wurde doch die letzten Jahre schon gezeigt, dass man NVMe-SSDs (im Consumer-Markt!) am Limit betreiben kann mit normaler Benchmark-Software auf normalen Windows-Consumer Versionen. Wie ist das möglich? Die Benchmark-Software bringt ja keine eigenen NVMe-Storage Treiber mit, sondern setzt auf den Windows-Treibern auf.
Irgendwie seltsam... kann jemand das erlären?
Im Regelfall greifen Anwendungen ja nicht direkt auf die I/O-Treiber zu, sondern nutzt wie Windows Storage API bzw. noch weiter abstrahiert eine Bibliothek, die die Nutzung auf die Storage API implementiert. Entsprechend kann eine Anwendung fröhlich zig I/O Requests auslösen, die Storage API frisst sie, baut eigene Queues und stellt diese für die Hardwaretreiber bereit, die die Queues der Hardware füllen.
Wenn die Queues der Storage API immer voll sind, sind praktisch die SCSI Queues für jedes Laufwerk immer 32 Befehle lang. Das ist eine ganze Menge und reicht bei Consumerkram mit 1..8 Speicherkanälen an sich auch für eine gute Auslastung.
h00bi schrieb:
Entweder sind die Linux Treiber auch scheisse oder man müsste diesen angeblichen 10-15% Gap ja bereits 10 Jahre lang zwischen Linux und Windows gesehen haben.
Und KEIN EINZIGER Hardware-Redakteur oder Hardware-affine Mensch hat das jemals festgestellt und drüber berichtet? Kann ich mir beim besten Willen nicht vorstellen.
https://www.phoronix.com/review/windows-10-prescu/2
Phoronix ist Imho immer mit Vorsicht zu genießen, da da viele Benchmarks gemacht werden, aber oftmals ohne all zu viel Rücksicht welche Parameter alles abweichen und/oder Analysen für die Gründe massiver Ausreißer. Grundlegend hat Windows aber Schwächen bei I/O aller Art, dem Spawnen von Threads und das ist bekannt.
Es spielt aber in vielen Bereichen keine große Rolle. Desktopanwender schaffen nicht ansatzweise die Lastprofile der Benchmarks, bei Servern muss man sich da auch Mühe geben und Hyperscaler mit den passenden Lastprofilen nutzen kein WinServer, selbst wenn sie Microsoft heißen.
Und sind wir mal realistisch. Der Vorteil von NVMe Treiber und flottem I/O macht man sich in der Linux/BSD-Welt ganz fix kaputt, wenn man Dateisysteme wie ZFS, BTRFS, ... einsetzt. CoW, Checksumming, Kompression und was es nicht alles gibt, ist da oftmals wichtiger als File-I/O.
Es gibt halt je nach Anforderungen Wichtigeres als "Performance, Performance, Performance".
mibbio schrieb:
Es gab bisher schlicht keine zwingende Notwendigkeit. Microsoft ist bei Windows recht konservativ, was Neuerungen oder Änderungen am Unterbau und den APIs betrifft. Jede dortige, größere Änderung brigt immer das Risiko, dass irgendeine Kompatibilität bricht (besonders mit älterer Hardware/Software). [...]
Die API zum direkten Ansteuern für SCSI, ATA, NVMe, .. dürfen Anwendungen im Userspace nicht sehen. Konstante UserspaceAPI beibehalten und flottes Backend implementieren sollte eigentlich kein Problem sein.
Caramon2 schrieb:
Ist euch eigentlich bewusst, dass dadurch sämtliche eurer NVMe-SSD-Tests Makulatur sind, da sie quasi mit angezogener Handbremse durchgeführt wurden?
Jeder Benchmark ist sowieso immer ein "Dieses System, dieses Betriebssystem + sonstige Software, am Tag X" schaffte folgendes: "blabla over 9000!".
