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

SG1

hustbaer schrieb:

Mem O. Ry schrieb:

Wenn ich z.B. malloc(1TB), malloc(512GB), malloc(256GB),..., malloc(1GB).
So lange mache, bis es keinen Nullpointer zurück gibt und dann gleich wieder lösche sollte das doch nur im Arbeitsspeicher sein.

Wenn das Pagefile/die Paging-Partition gross genug ist, dann bekommst du auch bei malloc(1TB) keinen NULL Pointer zurück sondern die gewünschten 1TB Speicher.

Von Overcommit gar nicht zu reden...

hustbaer

Vernünftige OSen tun halt auch nicht over-committen. Ich weiss schon wieso ich Windows verwende und nicht *NIX

SeppJ

hustbaer schrieb:

Vernünftige OSen tun halt auch nicht over-committen. Ich weiss schon wieso ich Windows verwende und nicht *NIX

Du könntest ja im laufenden Betrieb Speicher reinstecken. Ok, bei Windows natürlich nicht, bei Linux schon

hustbaer

Klar geht das auch mit Windows. Is aber ganz neu, erste Version die das konnte war Server 2003

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