Linux vs. Windows (Split aus: Allgemeine Funktion um verfügbaren Speicher zu ermitteln?)

hustbaer

Nen OS Daemon der wenns knapp wird einfach mal so beschliesst irgendwelche Prozesse wegzukillen kann Windows natürlich nicht bieten.

Für solch eine Meisterleistung der Ingenieurskunst, die bekanntermassen niemals nie zu elendigem Aufwand durch Fehlersuche wegen nichts geführt hat, benötigt man dann in der Tat ein *NIX.

SeppJ

hustbaer schrieb:

Nen OS Daemon der wenns knapp wird einfach mal so beschliesst irgendwelche Prozesse wegzukillen kann Windows natürlich nicht bieten.

Ernste Frage: Was passiert bei Windows stattdessen?

Bashar

Eine Windows-vs-Unix-Diskussion? Mir wird ganz nostalgisch.

C++ Forumbot

Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (alle ISO-Standards) in das Forum Themen rund um die IT verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Es gibt ja Spiele, die sowohl auf Windows als auch auf Linux laufen. Gibt es dazu vergleichende Benchmarks?

dfdggdf schrieb:

Es gibt ja Spiele, die sowohl auf Windows als auch auf Linux laufen. Gibt es dazu vergleichende Benchmarks?

https://www.pcwelt.de/a/gaming-benchmark-linux-vs-windows-10,3403023

SeppJ

dfdggdf schrieb:

Es gibt ja Spiele, die sowohl auf Windows als auch auf Linux laufen. Gibt es dazu vergleichende Benchmarks?

Kann man nicht sinnvoll vergleichen. Wenn man die exakt gleich konfigurierte Engine eines Spiels auf ein anderes Betriebssystem überträgt, dann wird es schnarchlahm sein. Wenn man also zwei verschiedene Versionen eines Spiels vergleicht, dann misst man in aller Regel nur, wie viel Arbeit der Entwickler jeweils in Optimierungen für diese Plattform gesteckt hat.

hustbaer

SeppJ schrieb:

hustbaer schrieb:

Nen OS Daemon der wenns knapp wird einfach mal so beschliesst irgendwelche Prozesse wegzukillen kann Windows natürlich nicht bieten.

Ernste Frage: Was passiert bei Windows stattdessen?

Na es fliegen bad_alloc , malloc gibt NULL zurück etc.
Oder was meinst du?

Das "Mist ich hab' was versprochen was ich jetzt nicht halten kann" Problem vermeidet Windows ja, indem es eben nix verspricht was es nicht halten kann.
(Also wenn wir mal ganz krasse Sachen wie IO Fehler beim Paging ignorieren.)
Und daher braucht es natürlich auch keinen Notfallplan für solche Fälle.

hustbaer

SeppJ schrieb:

dfdggdf schrieb:

Es gibt ja Spiele, die sowohl auf Windows als auch auf Linux laufen. Gibt es dazu vergleichende Benchmarks?

Kann man nicht sinnvoll vergleichen. Wenn man die exakt gleich konfigurierte Engine eines Spiels auf ein anderes Betriebssystem überträgt, dann wird es schnarchlahm sein. Wenn man also zwei verschiedene Versionen eines Spiels vergleicht, dann misst man in aller Regel nur, wie viel Arbeit der Entwickler jeweils in Optimierungen für diese Plattform gesteckt hat.

Was soll das gross mit dem OS zu tun haben? Man müsste einfach Spiele vergleichen die auch auf Windows Vulkan verwenden.

Ansonsten hat man einen Vergleich Direct3D vs. OGL/Vulkan. Und den gewinnt im Moment Direct3D. Woran das liegt kann ich nicht sagen. Kann natürlich dran liegen dass das D3D Backend der Game Engines besser optimiert ist als das Vulkan Backend. Kann aber auch sein dass einfach die D3D Treiber besser sind.

SeppJ

hustbaer schrieb:

SeppJ schrieb:

hustbaer schrieb:

Nen OS Daemon der wenns knapp wird einfach mal so beschliesst irgendwelche Prozesse wegzukillen kann Windows natürlich nicht bieten.

Ernste Frage: Was passiert bei Windows stattdessen?

Na es fliegen bad_alloc , malloc gibt NULL zurück etc.
Oder was meinst du?

Heißt das, das System ist dann für immer blockiert, weil man den Verursacher nicht abschießen kann? Weil man den Taskmanager/Konsole wegen Speichermangels nicht starten kann.

Ich könnte also ein Windowssystem mit

while(True) calloc(1, 1);

mit einem Schlag lahmlegen? Das ist ja schon ziemlich nahe dran an dem, was jemand im Ursprungthread zur Speichervermessung vorgeschlagen hatte. Ein paar Zeichen vertippt und er hätte dies gehabt. Es finde es nicht so weit hergeholt, dass es Programme gibt, die eine bad_alloc abfangen und sich dann eben nicht sofort beenden.

hustbaer schrieb:

SeppJ schrieb:

dfdggdf schrieb:

Es gibt ja Spiele, die sowohl auf Windows als auch auf Linux laufen. Gibt es dazu vergleichende Benchmarks?

Kann man nicht sinnvoll vergleichen. Wenn man die exakt gleich konfigurierte Engine eines Spiels auf ein anderes Betriebssystem überträgt, dann wird es schnarchlahm sein. Wenn man also zwei verschiedene Versionen eines Spiels vergleicht, dann misst man in aller Regel nur, wie viel Arbeit der Entwickler jeweils in Optimierungen für diese Plattform gesteckt hat.

Was soll das gross mit dem OS zu tun haben? Man müsste einfach Spiele vergleichen die auch auf Windows Vulkan verwenden.

Und das Grafikframework ist das einzige, was zählt? Absolut kein Zusammenhang dazu, wie die Daten in das Framework kommen, wie das Framework genau konfiguriert ist, oder zum sonstigen Drumherum? Es gab mal einen tollen Artikel, ich glaube auf Heise, aber eventuell war es auch Golem, wie Valve ihre Sourceengine nach Linux portiert haben. Da standen viele solche Probleme beschrieben, und wie sie aus der lahmen direkten Portierung mit ein paar einfachen Anpassungen eine spielbare erste Version machten. Und die Entwickler erklärten, wie man solche Optimierungen natürlich umgekehrt auch machte, als man die Engine überhaupt das erste Mal für Windows entwickelt hat. Ich finde ihn leider nicht, aber es klang alles recht plausibel. Da ich selber nur interessierter Laie auf dem Gebiet von Hochleistungsspieleengines bin (und ich erlaube mir auch mal die Vermutung, dass dies für dich ebenfalls gilt), bin ich geneigt, denen, die so etwas tatsächlich beruflich entwickeln eher zu glauben, als der "müsste doch"-Einschätzung eines Außenstehenden.

Mechanics

SeppJ schrieb:

Ich könnte also ein Windowssystem mit
while(True) calloc(1, 1);
mit einem Schlag lahmlegen?

Ich glaub schon, mehr oder weniger. Das ist anscheinend von Version zu Version unterschiedlich und ich hatte mir erhlich gesagt nicht die Mühe gemacht, mich intensiv damit zu befassen. Aber ich hab vor einer Weile mal ausprobiert, was passiert, wenn ein Programm zu viel Speicher anfordert. Dann war erstmal das ganze System lahm und ich habs irgendwann nach Minuten geschafft, den Task Manager zu starten und den Prozess wieder zu killen. Danach hatte sich das System nach und nach wieder gefangen.

SeppJ

Dann müsste ja irgendetwas wieder frei geworden sein, damit du den Taskmanager starten konntest. Oder du hast Glück gehabt, dass ein anderes Programm an Speichermangel gestorben ist und dann korrekt freigegeben hat. Ansonsten könnte einer der am weitesten verbreiteten Programmierfehler überhaupt, das Speicherleck, das gesamte System lahmlegen. Ich kann mir nicht vorstellen, dass die Windowsentwickler solch ein Szenario nicht bedacht haben sollten.

SeppJ schrieb:

Ich kann mir nicht vorstellen, dass die Windowsentwickler solch ein Szenario nicht bedacht haben sollten.

Wobei man die Schleife unter Linux auch nur leicht abaendern muesste:

for (;;) fork();

Und es stellt sich die Frage, inwieweit man allgemein vor solchen Angriffen gewappnet sein muss (da wo es drauf ankommt, gibt es ja Loesungen fuer Linux und vermutlich auch fuer Windows).

Das Prozess-Abschiessen bei OOM, finde ich aber durchaus angebracht. Einfach gar nichts machen ist jedenfalls kaum besser.

SeppJ

Forkstackerdriver schrieb:

SeppJ schrieb:

Ich kann mir nicht vorstellen, dass die Windowsentwickler solch ein Szenario nicht bedacht haben sollten.

Wobei man die Schleife unter Linux auch nur leicht abaendern muesste:
for (;;) fork();

Naja. Ersten bringt das auch Windows zum Erliegen und zweitens und viel wichtiger: Wie viele Programme haben unabsichtliche Speicherlecks und wie viele haben unabsichtliche Threadlecks? Dass man mit einem bösartigen Schadprogramm und den nötigen Rechten einigen Unfug treiben kann, ist wohl außer Frage und gilt systemunabhängig.

Tja, das Speicherleck ist sicher häufiger, aber bis es zu einem Problem wird, vergeht dafür erstmal Zeit.

Ich habe unter Linux schon beides erlebt: OOM-Kills und Prozesse die Amok forken.

Windows hat ja für das Problem, dass Programme über längere Zeit zu viel Speicher reservieren, mittlerweile noch eine andere Lösung gefunden.
Siehe dazu https://www.c-plusplus.net/forum/344206

*SCNR*, mfg, Uptimer

SeppJ

Forkstackerdriver schrieb:

Windows hat ja für das Problem, dass Programme über längere Zeit zu viel Speicher reservieren, mittlerweile noch eine andere Lösung gefunden.
Siehe dazu https://www.c-plusplus.net/forum/344206

*SCNR*, mfg, Uptimer

lol. Das akzeptiere ich fortan als die beste Art und Weise, ein System stets zuverlässig zu halten

hustbaer

SeppJ schrieb:

hustbaer schrieb:

SeppJ schrieb:

hustbaer schrieb:

Nen OS Daemon der wenns knapp wird einfach mal so beschliesst irgendwelche Prozesse wegzukillen kann Windows natürlich nicht bieten.

Ernste Frage: Was passiert bei Windows stattdessen?

Na es fliegen bad_alloc , malloc gibt NULL zurück etc.
Oder was meinst du?

Heißt das, das System ist dann für immer blockiert, weil man den Verursacher nicht abschießen kann? Weil man den Taskmanager/Konsole wegen Speichermangels nicht starten kann.

Ich könnte also ein Windowssystem mit
while(True) calloc(1, 1);
mit einem Schlag lahmlegen? Das ist ja schon ziemlich nahe dran an dem, was jemand im Ursprungthread zur Speichervermessung vorgeschlagen hatte. Ein paar Zeichen vertippt und er hätte dies gehabt. Es finde es nicht so weit hergeholt, dass es Programme gibt, die eine bad_alloc abfangen und sich dann eben nicht sofort beenden.

Möglich. Allerdings verwende ich nun schon wirklich lange Windows, und seit ich Rechner mit > 4 GB RAM habe kann ich mich an keine solche Situation erinnern. Ist also eher ein theoretisches Problem. Also schon eines das man in der Praxis vermutlich ganz einfach absichtlich herbeiführen kann, aber eines das halt ansonsten kaum auftritt.

Jetzt direkt hab' ich keine Zeit, aber wenn ich heute später nochmal dran denke werd' ich das ausprobieren. Gibt ja schliesslich fertige Tools die genau dafür gemacht sind "out of memory" Conditions zu produzieren - zum Testen wie stabil Programme unter solchen Umständen laufen. Hab' ich erst letztens in der Arbeit gemacht. Dabei hab' ich den Speicherfresser allerdings mit Ctrl+C abgebrochen (hatte ein Kommandozeilenprogramm verwendet). Daher weiss ich nicht ob man es schafft dann noch den Task-Manager aufzumachen.

SeppJ schrieb:

hustbaer schrieb:

SeppJ schrieb:

dfdggdf schrieb:

Es gibt ja Spiele, die sowohl auf Windows als auch auf Linux laufen. Gibt es dazu vergleichende Benchmarks?

Kann man nicht sinnvoll vergleichen. Wenn man die exakt gleich konfigurierte Engine eines Spiels auf ein anderes Betriebssystem überträgt, dann wird es schnarchlahm sein. Wenn man also zwei verschiedene Versionen eines Spiels vergleicht, dann misst man in aller Regel nur, wie viel Arbeit der Entwickler jeweils in Optimierungen für diese Plattform gesteckt hat.

Was soll das gross mit dem OS zu tun haben? Man müsste einfach Spiele vergleichen die auch auf Windows Vulkan verwenden.

Und das Grafikframework ist das einzige, was zählt? Absolut kein Zusammenhang dazu, wie die Daten in das Framework kommen, wie das Framework genau konfiguriert ist, oder zum sonstigen Drumherum? Es gab mal einen tollen Artikel, ich glaube auf Heise, aber eventuell war es auch Golem, wie Valve ihre Sourceengine nach Linux portiert haben. Da standen viele solche Probleme beschrieben, und wie sie aus der lahmen direkten Portierung mit ein paar einfachen Anpassungen eine spielbare erste Version machten. Und die Entwickler erklärten, wie man solche Optimierungen natürlich umgekehrt auch machte, als man die Engine überhaupt das erste Mal für Windows entwickelt hat. Ich finde ihn leider nicht, aber es klang alles recht plausibel. Da ich selber nur interessierter Laie auf dem Gebiet von Hochleistungsspieleengines bin (und ich erlaube mir auch mal die Vermutung, dass dies für dich ebenfalls gilt), bin ich geneigt, denen, die so etwas tatsächlich beruflich entwickeln eher zu glauben, als der "müsste doch"-Einschätzung eines Außenstehenden.

Wäre interessant was das für Anpassungen waren. Hast du zufällig den Link zu dem Aritkel noch? Würde mich interessieren.

Mir fällt halt nicht wirklich etwas ein, was man unter Linux anders machen müsste als unter Windows. Also speziell bei dem was Spiele so machen. Kann natürlich sein dass ich mich da verschätze - gerade deswegen wäre ja der Artikel interessant.

hustbaer

Forkstackerdriver schrieb:

Und es stellt sich die Frage, inwieweit man allgemein vor solchen Angriffen gewappnet sein muss (da wo es drauf ankommt, gibt es ja Loesungen fuer Linux und vermutlich auch fuer Windows).

Das Prozess-Abschiessen bei OOM, finde ich aber durchaus angebracht. Einfach gar nichts machen ist jedenfalls kaum besser.

Für mich stellen sich zwei Fragen.
Erstmal was du schon schreibst, also ob es überhaupt nötig ist eine fest eingebaute Lösung für solche Fälle zu haben, die ohne vorherige Konfiguration und/oder Zutun des Benutzers etwas unternimmt.

Und dann: was sollte in so einem Fall sinnvollerweise unternommen werden? Ich finde es auf jeden Fall sehr fragwürdig einfach anhand irgend einer Metrik einen oder mehrere Prozesse auszuwählen und diese dann zu killen. Dann lieber noch das ganze System neu starten. Das aber bitte auch nur als opt-in. Für die meisten Server wäre das IMO die bessere Variante. Denn durch Wegschiessen irgendwelcher Prozesse kann man Server recht leicht in einen Zustand versetzen wo sie zwar ewig weiterlaufen werden und auch kein "out of memory" mehr produzieren werden, aber die gehostete Anwendung einfach nicht mehr funktioniert. Was ich ehrlich gesagt nicht so sexy finde.

Gibt auch einige Interessante Beiträge dazu, z.B.:
http://thoughts.davisjeff.com/2009/11/29/linux-oom-killer/

Ich weiss nicht ob die "badness" Metrik diesbezüglich schon gefixt wurde. Aber das was da beschrieben ist liest sich für mich nicht so prickelnd.

hustbaer schrieb:

Ansonsten hat man einen Vergleich Direct3D vs. OGL/Vulkan. Und den gewinnt im Moment Direct3D. Woran das liegt kann ich nicht sagen. Kann natürlich dran liegen dass das D3D Backend der Game Engines besser optimiert ist als das Vulkan Backend. Kann aber auch sein dass einfach die D3D Treiber besser sind.

oder daran, dass die entwickler keine lust haben, ihren quellcode offen legen zu müssen und daher auf sog. Adapter-Pattern (heißt das so?) zurückgreifen müssen und jeder furz erst einmal durchgereicht und das ergebnis dann zurückgereicht werden muss, was eben Zeit kostet.

Jedenfalls habe ich mir das in Bezug auf binäre Linux-Kernel-Treiber so erklären lassen und Direct3D kann ja vom Compiler entsprechend in Treiber-Funktionen oder was auch immer umgewandelt werden, denke ich mal.