Wo findet der Linux-Scheduler die Mehrleistung? [Archiv]

HPVD

2020-02-20, 13:13:32

u.a. auf Phoronix wird regelmäßig gezeigt das viele Anwendungen mit zunehmender Corezahl auf Linux schneller laufen. Besonders aber nicht nur auf AMD CPUs.

Beispiel: https://www.phoronix.com/scan.php?page=article&item=3970x-win10-enterprise&num=7

Die Frage ist:
"wo findet" denn der Linux Scheduler die Mehr-Leistung im Vergleich zum Windows-Scheduler?

Werden weniger unnötige Dinge gemacht?

Kann er die Boost-Raten besser "hochhalten" /höhere erreichen da er nichts unnötig hinundher schiebt?

Kann er die einzelnen Leistungen der Kerne besser nutzen?

Trägt er zu einer besseren Auslastung bei, da er jedem Kern genau das zuteilen kann was er optimal (effizient) verarbeiten kann und es so nicht punktuell zu Temperatur/Core-TPD Hotspots kommt die für runtertakten sorgen?

aufkrawall

2020-02-20, 13:16:59

Muss nicht zwingend am OS liegen, kann auch durch die Build-Umgebung kommen. Linux ist auch ein HPC-OS und entsprechend gibts dort für den ganzen Stack Optimierungen.

Brillus

2020-02-20, 13:42:15

Was man so liest bessere Verteilung der Prozesse insbesondere weniger Task zwischen Kernen rumwerfen Stichwort Cacheline killen.

Da mal vor kurzen einen schönen Post von Linus wo er erklärt warum die eine Sache mit den Spinlocks Benxhmarks für Spiele ziemlich das falsche gemesssen hat.

Berniyh

2020-02-20, 13:56:10

Werden weniger unnötige Dinge gemacht?
Schwierig zu beurteilen, aber meiner Erfahrung nach dürfte das keine so große Rolle spielen.
Die Multithreading Leistung unterscheidet sich bei angeblichen "Lightweight" Systemen nicht so massiv von "normalen" Distributionen.
Kann er die Boost-Raten besser "hochhalten" /höhere erreichen da er nichts unnötig hinundher schiebt?
Unwahrscheinlich, ggf. ist sogar eher das Gegenteil der Fall, da hier seitens AMD für Windows mehr optimiert wird, bzw. die spezifischen Optimierungen schneller beim User ankommen (da die beim Linux Kernel erst durch den Review Prozess müssen).
Kann er die einzelnen Leistungen der Kerne besser nutzen?
Bezogen auf Singlethread auch eher unwahrscheinlich.
Speziell die Änderungen den besten Core für Singlethread zu nutzen sind glaube ich auch noch nicht im Kernel enthalten.
Trägt er zu einer besseren Auslastung bei, da er jedem Kern genau das zuteilen kann was er optimal (effizient) verarbeiten kann und es so nicht punktuell zu Temperatur/Core-TPD Hotspots kommt die für runtertakten sorgen?
Auch unwahrscheinlich.

Generell ist der CPU Scheduler unter Linux einfach besser auf Vielkernsysteme optimiert, man hat da auch wesentlich mehr Erfahrung als Microsoft mit Windows, da viele Numa Systeme ja schon seit Jahrzehnten auf Linux laufen.
Spezifisch geht es wohl eher darum die Prozesse nicht unnötig durch die Gegen zu schieben.

Dazu kommt, dass manche Anwendungen wie Blender generell auf Linux schlicht schneller laufen, d.h. wohl besser dafür optimiert sind.

Und zu guter Letzt hat man unter Linux für viele Anwendungen – dank Open Source – die Möglichkeit diese mit architektur-spezifischen Compileroptionen zu übersetzen und damit noch etwas an Performance rauszuholen.
Der Vorteil von Clear Linux basiert z.B. zu einem Anteil genau darauf.

Zossel

2020-02-20, 20:05:47

Die Frage ist:
"wo findet" denn der Linux Scheduler die Mehr-Leistung im Vergleich zum Windows-Scheduler?

Einfach mal andersrum fragen: Wieso findet MS keinen Businesscase welcher eine besseren Scheduler rechtfertigt.

Ganon

2020-02-20, 20:34:30

Es ist schwer zu beurteilen, da auf beiden Systemen nicht der gleiche Code läuft. Dazu müsste man sämtliche Fälle einzeln untersuchen. Neben dem reinen Scheduling gibt es noch wesentlich mehr Faktoren:

- der Software-Stand der einzelnen Distributionen und Windows ist nicht identisch, z.B. ist es bei python ein Mix zwischen Python 3.6, 3.7 und 3.8, bei Java sagt er unter Winows zu den Details "operable program or batch file" :ugly:

- die Compiler Flags (und vermutlich auch der Compiler) bei den einzelnen Distributionen sind nicht identisch, zu Windows gar keine Angabe (?)

- die Dateisysteme sind jeweils andere, bei Windows sowieso

Es scheint auch die Info zu fehlen, ob Dinge wie der Windows Defender im Hintergrund liefen oder nicht.

Unabhängig vom diesem Test hat Linux schon seine Vorteile im Vergleich zu Windows. Selbst wenn man z.B. CUDA in Blender einsetzt ist die Performance hier wesentlich besser. Beim Vergleich über die CPU stellt sich hier die Frage wie viel Einfluss der Compiler hat. Eigentlich setzt der Renderer auf sehr viel handoptimierten Code, bzw. AVX-Libraries wie Embree. Hier kann Scheduling schon ein Faktor sein. Bei Spielen zeigt sich z.B. auch, dass Linux im CPU Limit die bessere Framerate im Vergleich zu Windows hat. Auf der anderen Seite mag der Linux Scheduler keine Spinlocks. Da gab es ja zuletzt das Thema...

Auch wenn der Test zeigt, wie etwaige Software in der Standard-Konfig auf dem entsprechenden System läuft, ist er für diese Frage unbrauchbar.

aufkrawall

2020-02-20, 21:00:08

Unabhängig vom diesem Test hat Linux schon seine Vorteile im Vergleich zu Windows. Selbst wenn man z.B. CUDA in Blender einsetzt ist die Performance hier wesentlich besser.
Habe hier in einem kleinen Projekt 7,9s vs. 8,4s, wobei aber auch ein CPU-Kern voll ausgelastet ist.
Ich spar mir jetzt die Randbemerkung zur AMD-Performance via OpenCL vs. CUDA. :freak:

Ganon

2020-02-20, 21:14:39

Habe hier in einem kleinen Projekt 7,9s vs. 8,4s, wobei aber auch ein CPU-Kern voll ausgelastet ist.
Ich spar mir jetzt die Randbemerkung zur AMD-Performance via OpenCL vs. CUDA. :freak:

https://youtu.be/cpE2B2QSsa0?t=415

Hier sind's z.B. 3:28 für Linux und 4:56 für Windows. Hängt natürlich auch von der Hardware und der Treiberversion ab. Blender rendert aber afaik in den neusten Versionen auch mittels CUDA ebenfalls über die CPU parallel mit.

Pirx

2020-02-20, 21:28:37

aufkrawall

2020-02-20, 22:01:10

https://youtu.be/cpE2B2QSsa0?t=415

Hier sind's z.B. 3:28 für Linux und 4:56 für Windows. Hängt natürlich auch von der Hardware und der Treiberversion ab. Blender rendert aber afaik in den neusten Versionen auch mittels CUDA ebenfalls über die CPU parallel mit.
Sind hier mit The Junk Shop tatsächlich 1:12:29min vs. 1:04:71min auf der 1070. Nicht die Welt, aber für GPU Computing auch nicht zu verachten.

Ganon

2020-02-20, 23:59:20

Nicht die Welt

Kommt darauf an. Eine 5 Minuten lange Animation bei den üblichen 24fps besteht aus 7200 Bildern. Selbst wenn der Rendervorgang nur eine Sekunde schneller läuft, spart das hinten raus 2 Stunden Renderzeit insgesamt. Spart man "nur" eine Minute, sind das schon 5 Tage weniger Renderzeit.

Das kann man natürlich auch noch auf viele andere Bereiche anwenden, bei der man au das Ergebnis einer Rechnung wartet. Aber hier wird in vielen Bereichen auch schon Linux eingesetzt... von daher. Hier ist dann wieder "normales Linux" vs. "Clear Linux" interessanter.

aufkrawall

2020-02-21, 00:20:38

Bei x264 ist das bei mir auf Skylake allerdings nicht so, Windows war immer 1-2s schneller. Wobei ich es nochmal ohne intel-ucode überprüfen müsste, das hatte mir auch schon JavaScript ausgebremst.

iuno

2020-02-21, 02:17:25

Dazu kommt, dass manche Anwendungen wie Blender generell auf Linux schlicht schneller laufen, d.h. wohl besser dafür optimiert sind.
Wobei hier wohl eher msvc Schuld ist.
Der Blender buildbot hatte vor einiger Zeit noch "experimentelle" Windows builds mit gcc, oder man hat's halt selbst gebaut. Die waren auch deutlich schneller als die offiziellen Builds. Ob's genauso schnell war wie unter Linux, kann ich nicht mehr genau sagen, aber immerhin gab es nicht mehr so einen deutlichen Unterschied.

gravitationsfeld

2020-02-21, 05:38:36

Linux optimiert mehr auf Cache-Lokalitaet statt Scheduling-Latenz.

Zossel

2020-02-21, 11:34:04

Die Mehrleistung findet sich möglw. automatisch durch konsequente, rein sachliche (und nicht/kaum auch politische, künstlich beschränkende), sehr strukturiert vorangetriebene Arbeit, die Hardware bestmöglich auszunutzen über Jahrzehnte. Linux konnte schon zu Pentium-Zeiten Dinge bei Parallelisierung/Multithreading, von denen Windows nur träumen konnte.

Aktuelles Beispiel von vorgestern: https://lore.kernel.org/lkml/20200219135442.18107-1-mgorman@techsingularity.net/

A variety of other workloads were evaluated and appear to be mostly
neutral or improved. netperf running on localhost shows gains between 1-8%
depending on the machine. hackbench is a mixed bag -- small regressions
on one machine around 1-2% depending on the group count but up to 15%
gain on another machine. dbench looks generally ok, very small performance
gains. pgbench looks ok, small gains and losses, much of which is within
the noise. schbench (Facebook workload that is sensitive to wakeup
latencies) is mostly good. The autonuma benchmark also generally looks
good, most differences are within the noise but with higher locality
success rates and fewer page migrations. Other long lived workloads are
still running but I'm not expecting many surprises.

aufkrawall

2020-02-21, 13:20:38

Gerade mal ausprobiert: Der SotTR Linux-Port läuft mit Nvidia unter Linux (Standard Arch-Kernel 5.5) Vulkan im CPU-Limit etwas schneller als D3D12 Windows 10 1909, ~94fps vs. ~100fps.
Bei AMD ist D3D12 am schnellsten mit 103fps, sollte also nicht am Port liegen.

Badesalz

2020-02-22, 10:14:09

Die Frage ist:
"wo findet" denn der Linux Scheduler die Mehr-Leistung im Vergleich zum Windows-Scheduler?

Werden weniger unnötige Dinge gemacht?Zum einen, vielleicht. Zum anderen werden die nötigen Dinge vielleicht auch bisschen klüger erledigt.

Benutzername

2020-02-22, 12:25:47

Zum einen, vielleicht. Zum anderen werden die nötigen Dinge vielleicht auch bisschen klüger erledigt.

Als ob es was neues wäre, daß der Windows Scheduler und die Prozessverwaltung im Allgemeinen nicht so doll sind, und die ganzen Dienste Mist sind und wegen Abgabeterminen schnell zusammengepappt und ineffizient programmiert sind. Haufenweise Legacyzeugs mitschleppen zu müssen ist auch nciht hilfreich. Man gucke sich nur die netten Kommentare im Windows2000 Quellcode an, wo die Kernelprogrammierer von Windows schreiben, daß es mist ist, aber Access sonst nicht läuft. Gibt bestimmt noch mehr so Macken, die sie einbauen müssen für Microsoft eigene Programme. Wäre ja schön blöd, falls Office nicht gut auf Windows läuft zB.

Der Linux-Kernel wird andererseits heutzutage für eigentlich alles eingesetzt vom winzigen Microcontroller in der Waschmaschine (oder Internet of Shit mit der ganz heißen Nadel gestrickten Fischfütterungsanlage fürs Aquarium) bis zum Superrechner. Wegen letzterem konnte Linux auch sofort was mit den vielen Kernen mit denen uns AMD seit ein paar Jahren für wenig Geld überschüttet sofort etwas anfangen. Die Entwicklungszyklen sind auch erheblich kürzer bei Linux. Gibt ja dauernd neue Versionen mit neuen Features. Und die Leute die am Linux-kernel arbeiten haben auch einfach Spaß an einer schnellen, performanten und eleganten Lösung. Und falls es mal wirklich klemmt in der Entwicklung wird eine Veröffentlichung auch mal verschoben.

Natürlich kann man, wenn man das will, auch eine träge, überfrachtete Distribution zusammenstellen, welche als Standard alles an daemons startet was geht und dann auch nicht mehr besonders schnell ist. Den Kernel kann man auch schneller machen wie zB der Liquorix-Kernel, der für Daddeln optimiert ist. Der Ubuntu KErnel ist hingegen mehr für "soll überall laufen" ausgelegt.

lumines

2020-02-22, 12:40:55

Die Entwicklungszyklen sind auch erheblich kürzer bei Linux.

Sind sie das? Gibt es zum aktuellen Entwicklungsmodell des Windows-Kernels irgendwelche öffentlichen Infos?

Gibt ja dauernd neue Versionen mit neuen Features. Und die Leute die am Linux-kernel arbeiten haben auch einfach Spaß an einer schnellen, performanten und eleganten Lösung.

Realitätscheck: Die meisten der Kernel-Entwickler arbeiten für Unternehmen wie Red Hat, Intel, Samsung, Google oder Organisationen wie Linaro: https://www.linuxfoundation.org/blog/2016/08/the-top-10-developers-and-companies-contributing-to-the-linux-kernel-in-2015-2016/

Und falls es mal wirklich klemmt in der Entwicklung wird eine Veröffentlichung auch mal verschoben.

Das dürfte auf so ziemlich jedes größere Softwareprojekt zutreffen, wenn nicht nur Bugs gefixt werden.

aufkrawall

2020-02-22, 13:01:34

Den Kernel kann man auch schneller machen wie zB der Liquorix-Kernel, der für Daddeln optimiert ist. Der Ubuntu KErnel ist hingegen mehr für "soll überall laufen" ausgelegt.
Da fällt nicht magisch Performance vom Himmel. Hab diverse Scheduler und Tweaks mit SotTR durchprobiert, bringt vs. Arch-Standard CFS quasi alles gar nichts bis negativ.
Es sind alles nur Trade-Offs.

Tesseract

2020-02-22, 13:18:01

Gibt es zum aktuellen Entwicklungsmodell des Windows-Kernels irgendwelche öffentlichen Infos?

wahrscheinlich nicht, aber was man so hört greift microsoft einmal geschriebenen code generell kaum mehr an so lange sie die änderungen nicht direkt vermarkten können wodurch in vielen ihrer produkte optimierungsmöglichkeiten brach liegen. beim scheduler spielt die strategie natürlich auch eine entscheidene rolle und unterschiedliche stategien können in unterschiedlichen szenarien vorteile haben aber unabhängig davon kann code auch einfach unnötig langsam sein und hier ein paar prozent im netzwerk-stack, da ein paar prozent im SATA-protokoll, dort ein paar prozent im USB-stack usw. summieren sich unterm strich dann doch auf.

Badesalz

2020-02-22, 14:12:20

Hat MS nicht trotzdem mal irgendwas an Win10 geändert, damit AMDs Chiplets besser performen?
Ich meine da was gelesen zu haben.

Den blitzschnellen Scheduling auf 4 Kernen, wie ein frischer XPsp3, den werden sie aber wohl nie mehr hinbekommen (dürfen) :rolleyes:

aufkrawall

2020-02-22, 15:52:12

Den blitzschnellen Scheduling auf 4 Kernen, wie ein frischer XPsp3, den werden sie aber wohl nie mehr hinbekommen (dürfen) :rolleyes:
Wat?

Badesalz

2020-02-22, 17:35:49

Wie, wat? Scheduling
https://en.wikipedia.org/wiki/Scheduling_%28production_processes%29

Darkman.X

2020-02-22, 17:55:50

Ich vermute, dass seine Aussage sich auf "XPsp3" bezog. Inwiefern war das bei XP schneller als beim heutigen Win10? Woran machst du deine Aussage fest?

Badesalz

2020-02-22, 18:57:21

Kein Windows davor wie danach hat sich je so lebendig angefühlt - und das noch zum Teil zu C: auf HDDs - als frisches XPsp3 :wink:

Zossel

2020-02-22, 22:34:49

Kein Windows davor wie danach hat sich je so lebendig angefühlt - und das noch zum Teil zu C: auf HDDs - als frisches XPsp3 :wink:

Wenn es schnell ist kann es nur der Scheduler sein?

Steile These.

aufkrawall

2020-02-22, 23:12:35

Liegt wohl eher an fehlendem Fenster-Compositor (kein Vsync) + weniger Bloat.

RaumKraehe

2020-02-22, 23:50:25

Kein Windows davor wie danach hat sich je so lebendig angefühlt - und das noch zum Teil zu C: auf HDDs - als frisches XPsp3 :wink:

Also mein Win10 installiert auf einer NVME SSD direkt am PCI-X Bus fühlt sich extrem lebendig an. Ehrlich gesagt war die Erfahrung, Aktion zu Reaktion, noch nie so krass direkt.

iuno

2020-02-22, 23:58:21

Gefuehlte Werte sind eh die besten Werte.
Damals hat das OS halt einfach noch viel weniger gemacht, das hat mit dem scheduler natuerlich sehr wenig zu tun.

Realitätscheck: Die meisten der Kernel-Entwickler arbeiten für Unternehmen wie Red Hat, Intel, Samsung, Google oder Organisationen wie Linaro
Das ist ja kein Widerspruch. Die wollen alle, dass ihre Produkte optimal performen.

Zossel

2020-02-23, 07:45:51

Den Kernel kann man auch schneller machen wie zB der Liquorix-Kernel, der für Daddeln optimiert ist.
Hier wird es denn wieder ziemlich grenzwertig:
TCP BBR Congestion Control: Fast congestion control, maximizes throughput, guaranteeing higher speeds than Cubic. (https://liquorix.net/)

BBR is efficient and fast, but its fairness to non-BBR streams is disputed. While Google's presentation shows BBR co-existing well with CUBIC,[24] researchers like Geoff Huston and Hock, Bless and Zitterbart finds it unfair to other streams and not scalable.[29] Hock et al also found "some severe inherent issues such as increased queuing delays, unfairness, and massive packet loss" in the BBR implementation of Linux 4.9.[30]

Soheil Abbasloo et al. (authors of C2TCP) show that BBR doesn't perform well in dynamic environments such as cellular networks.[9][10] They have also shown that BBR has an unfairness issue. For instance, when a CUBIC flow (which is the default TCP implementation in Linux, Android, and MacOS) coexists with a BBR flow in the network, the BBR flow can dominate the CUBIC flow and get the whole link bandwidth from it (see figure 18 in [9]).
(https://en.wikipedia.org/wiki/TCP_congestion_control#TCP_BBR)

Aber ansonsten sind solche Projekte eine gute Spielwiese um neue Sachen zu testen, wenn irgendwann mehr auf Linux gezockt werden sollte wird das den Linux Kernel weiter verbessern.

Und "increased queuing delays, unfairness, and massive packet loss" ist zum zocken eher weniger geeignet.

aufkrawall

2020-02-23, 11:51:45

Gefuehlte Werte sind eh die besten Werte.

Das muss man ja auch nur mal etwas durchdenken: Ab wann sind Verzögerungen zu bemerken? 50ms? Und der OS CPU Scheduler soll auf dem Desktop ohne große Hintergrundlast dafür verantwortlich sein? Wat? :freak:

PatkIllA

2020-02-23, 12:11:08

Gerade auf dem Desktop ist aber gefühlte Schwuppdizität nicht unbedingt Mehrleistung.
Es wäre am schnellsten die Aufgaben im Batch ohne Kontextwechsel und geteilte Resources nacheineinander abzuarbeiten.
Rein praktisch muss man Kompromisse machen, die je nach Szenario unterschiedlich gut sind. Die optimale Strategie kann man gar nur im Nachhinein bestimmen.

Also mein Win10 installiert auf einer NVME SSD direkt am PCI-X Bus fühlt sich extrem lebendig an. Ehrlich gesagt war die Erfahrung, Aktion zu Reaktion, noch nie so krass direkt.Und das auf einem so alten System, dass es noch PCI-X hat. :)

lumines

2020-02-23, 12:13:18

Das ist ja kein Widerspruch. Die wollen alle, dass ihre Produkte optimal performen.

Natürlich, dafür werden die Leute dahinter bezahlt. Das gilt aber eben nur für die Produkte und Interessen ihres Arbeitgebers. Gerade bei Hardwareunterstützung und der jeweiligen Optimierung sitzen in den allermeisten Fällen die Hersteller direkt an der Entwicklung der Treiber und wenn nicht, dann ist das für die Community alleine oft unmöglich zu stemmen, einfach weil viel Know How erst selbst aufgebaut werden muss, was eben viele Mannjahre benötigt.

Wer einmal die Entwicklung eines Treibers ohne die Unterstützung des Herstellers miterlebt hat, weiß, wie lange so etwas dauern kann, bis das in einem benutzbaren Zustand ist.

Kommt natürlich auch immer auf die Hardware an. Bei simplen Komponenten kann das auch deutlich schneller gehen, aber was ist heute schon simpel?

aufkrawall

2020-02-23, 12:35:00

Gerade auf dem Desktop ist aber gefühlte Schwuppdizität nicht unbedingt Mehrleistung.
Es wäre am schnellsten die Aufgaben im Batch ohne Kontextwechsel und geteilte Resources nacheineinander abzuarbeiten.
Rein praktisch muss man Kompromisse machen, die je nach Szenario unterschiedlich gut sind. Die optimale Strategie kann man gar nur im Nachhinein bestimmen.

Wobei man sehen muss, dass bei Linux CFS schon lange an bestimmten Grundsätzen festgehalten wird, weil sich in der Breite der Anwendungen einfach nichts besseres abzeichnet.
Der Scheduler von Windows XP dürfte abnorme Schwächen im Vergleich haben.

Badesalz

2020-02-23, 12:47:10

Also mein Win10 installiert auf einer NVME SSD direkt am PCI-X Bus fühlt sich extrem lebendig an.Weil du das dann mit Hardware erschlägst. Scheduler, ist dagegen ein Stück Software... Zu Anfang gab es ja noch die Möglichkeit vieles auf der gleichen Hardware zu vergleichen.

Ich hab grad keine Ahnung warum ich dir das erzählen muss und du dir sowas nicht von alleine denken kannst. Bist du dir sicher, daß dir das Thema halbwegs liegt?

Zossel

2020-02-23, 19:33:25

Natürlich, dafür werden die Leute dahinter bezahlt. Das gilt aber eben nur für die Produkte und Interessen ihres Arbeitgebers.

Oft sitzen bei Linux über den Treibern für bestimmte Geräteklassen generische Abstraktionen die bestimmte Funktionen managen die für alle Geräte dieser Klasse gleich sind, das macht die eigentlichen Treiber schlanker. Und so sitzen dann des öfteren verschiedene Hersteller in einem Boot um über die Layer direkt über dem Treiber zu diskutieren. Da kommt es den auch mal zu Änderungen, z.b. für multiqueueing.

Ist es bei W10 immer noch so das LACP und VLAN vom Ethernettreiber des Herstellers bereit gestellt werden muss? Und es würde mich bei Windows auch nicht wundern wenn Multipathing für FC auch in den Herstellertreibern liegt.