WSL 3 ist je nach Workload 5–60 % schneller als WSL 2
WSL3 Performance is about 5-60% faster than WSL2 depending on the workload
Microsoft hat mit dem WSL-3.x-Stack die Standard-Virtualisierungsumgebung aktualisiert und den Gast-Kernel von 6.6 LTS auf 6.18 angehoben. Benchmarks zeigen: Die Speicherbandbreite steigt um 61 %, die Kontextwechsel-Latenz sinkt um 11 %, und die Kernel-Zeit beim Kompilieren von GoReleaser fällt um 16 %. Die reine Kompilierdauer verbessert sich nur um 4 %, da rechenintensive Workloads weiterhin von der CPU-Frequenz begrenzt werden.
Der Grund, warum die Gesamtzeit nur um etwa 7,5 Sekunden zurückging, ist einfach: Kompilieren ist überwiegend eine User-Space-Rechenlast.
- jesse_dot_id
Ich bin vor ein paar Jahren von Windows abgesprungen, nachdem ich es seit den frühen 90ern benutzt hatte. Einer der Hauptgründe war, wie sehr ich mich in meiner täglichen Arbeit mit WSL2 herumschlagen musste. Aber jetzt wird immer deutlicher, dass Microsoft sein Betriebssystem nicht interessiert. Ich weiß nicht mal, was sie tun könnten, um mich zurückzuholen. Vertrauen bleibt im KI-Zeitalter von Microsoft ein riesiges Problem.
- 1718627440
WSL2 ist ein anderes Produkt als WSL1, keine andere Version. Ist WSL3 jetzt eine andere Version von WSL2 oder ein weiteres separates Produkt?
- armcat
Großartige Arbeit beim Benchmarking! Ich war mir gar nicht bewusst, dass WSLc (WSL3) veröffentlicht wurde. Für alle anderen: Die Release-Infos gibt es hier: https://github.com/microsoft/WSL/releases/tag/3.0.1
EDIT: bin auf den vorherigen HN-Post hier gestoßen: https://news.ycombinator.com/item?id=49970507
- ReDress
syscall/basic getppid() Durchsatz 1.474.691 ops/s 1.533.399 ops/s +3,98%
Entry/exit latency 0,6781 µs/op 0,6521 µs/op -3,83%
sched/pipe 100k process ping-pong 48.445 ops/s 54.589 ops/s +12,68%
Context switch latency 20,64 µs/op 18,32 µs/op -11,25%
sched/messaging Hackbench (20 Gruppen, 800 Tasks) 14,507 s 13,047 s -10,06%
mem/memcpy glibc default bandwidth (1GB) 7,84 GB/s 12,64 GB/s +61,35%
Das ist großartig, das ist gute Arbeit. Aber wie bei einem Problem, das ich schon früher beim Linux-Kernel io-uring[1] beschrieben habe, wird hier versäumt, die Performance unter einer gesunden Serverlast zu testen und zu demonstrieren.
Das zeigt offensichtlich keine gesunde Serverlast, weil es einfach viel zu spezifisch ist.
- binsquare
Ein Großteil der WSL2-Verzögerung liegt nicht an der VM selbst, sondern am 9P-Dateisharing und der Interop.
Ich habe festgestellt, dass anscheinend alles unter /mnt/c über 9P läuft