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

Mr X schrieb:

cvxvvcx schrieb:

Hat jemand eine Erklärung dafür, dass unter Kubuntu LaTeX schneller läuft als auf Windows?

Ich würde davon ausgehen, dass das an der enormen Menge an Konsolenausgaben liegt, die Latex standardmäßig macht. Die Windows-Konsole bremst enorm. Gib mal -quiet mit an, und schau, ob es besser wird.

Ich führe LaTeX aus TeXstudio aus, also keine Konsole. Meine Vermutung ist, dass Linux Festplattenzugriffe cached.

Artchi

Viele Linux-Programme laufen unter Windows langsamer, ist auch mit Git so. Warum sollte Latex da anders sein?
Gibt verschiedene Gründe, z.B. weil ein Posix-Wrapper genutzt wird (Cygwin), oder weil nicht die nativen APIs benutzt werden... außerdem funkt andauernd der Virus-Scanner dazwischen, der ja seit Windows 7 standard ist.

hustbaer

Auch sind diverse File-System Sachen auf Windows leider immer noch langsamer als auf Linux. Bzw. umgekehrt: auf Linux sehr schnell. Daher enthalten viele Programme die in der Linux Welt entstanden sind viele File-System Calls. Was oft durch ne andere Architektur vermeidbar wäre, nur wenn kein guter Grund dagegen spricht, weil die Performance auf Linux eh gut genug ist, dann kann man es ja ruhig so machen. Beim Portieren auf Windows ist es dann langsam, nur bei nem Port kann man an der Architektur natürlich nix mehr ändern. Sonst wäre es ja kein Port sondern quasi ne Neuentwicklung.

Ich hoffe allerdings immer noch dass sich da früher oder später mal 'was tun wird. Entweder dass ReFS weiterentwickelt wird, vielleicht so weit dass man es als Boot-FS verwenden kann, und da dann auch die Performance passt, oder dass MS es mit NTFS irgendwie hinbiegt.

SideWinder schrieb:

Kleiner Einwurf ohne alles gelesen zu haben: für den Task Manager wird unter Windows bereits beim Booten genügend Speicher reserviert. Auch die notwendigen GDI-Handles werden afaik reserviert. Somit sind immer genügend Speicher/Handles verfügbar um den Task Manager zu starten und Prozesse abzuschießen.

Hast du dazu einen Beleg, oder erinnerst du dich, woher du die Information hast? Würde mich interessieren.

hustbaer

Mich auch. Ich glaub das nömlich nicht so ganz. Weil halt das Ergebnis meines Versuchs dagegen spricht. Und weil es mMn. sehr viel Aufwand wäre. Da müsste man den Task-Manager schon in den Desktop-Window-Manager einbauen -- und das ist er AFAIK nicht.

SideWinder

Ich wage mich zu erinnern, dass ich das auf Raymond Chans Blog (the old new thing) gelesen habe, kann es aber gerade nicht mehr finden. Da eure empirischen Ergebnisse anders sind, nehme ich die Aussage mal wieder zurück.

Evtl. wars auch nur der Secure Desktop den man mit CTRL+ALT+DEL immer starten kann...

MfG SideWinder

hustbaer

Hab's grad nochmal ausprobiert mit Testlimit.exe -m
Weder der CTRL+ALT+DEL Screen noch der Taskmanager können mehr gestartet werden (Windows 10 x64 1703).

Kann gut sein dass das mit dem CTRL+ALT+DEL Screen in älteren Windows Versionen mal garantiert war, aber aktuell ist es das ganz offensichtlich nicht (mehr).
Gibt sogar ne schöne Fehlermeldung wo steht dass der Screen leider nicht angezeigt werden kann - vielleicht ist jetzt nur mehr Speicher für diese Fehlermeldung reserviert

Ist natürlich schon doof irgendwie. Aber einfach Prozesse wegschiessen finde ich wie gesagt auch nicht gut. Die Variante mit "garantiert dass Task-Manager immer angezeigt werden kann" wäre da schon besser. Bringt aber auch nur was wenn man vor der Box sitzt. Denn per Remote-Desktop braucht man garantiert nicht versuchen sich in so einer Situation noch einzuloggen

SideWinder schrieb:

für den Task Manager wird unter Windows bereits beim Booten genügend Speicher reserviert. Auch die notwendigen GDI-Handles werden afaik reserviert. Somit sind immer genügend Speicher/Handles verfügbar um den Task Manager zu starten und Prozesse abzuschießen.

Was ich mich während dieser Diskussion auch schon gefragt habe: Wieso kommt das Betriebssystem überhaupt in die Situation, dass Prozesse abgeschossen werden oder gar das ganze System neugestartet werden muss? Wir haben genug Speicher, von dem sich das OS etwas abschneiden kann.

das eigentlich Traurige daran finde ich, dass wir als Programmierer uns so viel Mühe geben um NULL-mallocs und bad_allocs abzufangen und am Ende dann nur SIGTERM kommt

hustbaer

Forkstackerdriver schrieb:

Was ich mich während dieser Diskussion auch schon gefragt habe: Wieso kommt das Betriebssystem überhaupt in die Situation, dass Prozesse abgeschossen werden oder gar das ganze System neugestartet werden muss? Wir haben genug Speicher, von dem sich das OS etwas abschneiden kann.

Das Betriebssystem hat da kein Problem, das läuft eh weiter. Bloss wenn du keine neuen Prozesse mehr starten kannst, weil kein Speicher mehr da ist... dann tut man sich auch schwer bestehende Prozesse zu beenden, damit wieder Speicher frei würde... weil man üblicherweise nicht gerade ein Tool offen hat mit dem man so nen Prozess abschiessen kann.

hustbaer schrieb:

Forkstackerdriver schrieb:

Was ich mich während dieser Diskussion auch schon gefragt habe: Wieso kommt das Betriebssystem überhaupt in die Situation, dass Prozesse abgeschossen werden oder gar das ganze System neugestartet werden muss? Wir haben genug Speicher, von dem sich das OS etwas abschneiden kann.

Das Betriebssystem hat da kein Problem, das läuft eh weiter. Bloss wenn du keine neuen Prozesse mehr starten kannst, weil kein Speicher mehr da ist... dann tut man sich auch schwer bestehende Prozesse zu beenden, damit wieder Speicher frei würde... weil man üblicherweise nicht gerade ein Tool offen hat mit dem man so nen Prozess abschiessen kann.

nach der Logik könnte das OS ja einfach ein Tool offen halten mit dem man den Prozess abschiessen kann

Will aber vor allem nochmal auf meinen anderen Einwand aufmerksam machen: Wieso prüfe ich eigentlich noch den Rückgabewert von malloc()?

Das ist sehr demotivierend.

hustbaer

Ich bin nicht sicher, aber ich würde vermuten dass speziell grosse Allocations auch auf Systemen mit OOM-Killer schief gehen können. Möglicherweise (vermutlich) auch kleine, wenn zu viele kleine Allokationen in zu kurzer Zeit passieren.
Ich vermute dass es beim OOM-Killer eher darum geht dass das System "verwendbar" bleibt bzw. es nach recht kurzer Zeit wieder wird -- und nicht dass jede einzelne Allokation garantiert wird.

Und wenn diese Vermutungen zutreffen, dann heisst das dass du trotzdem den Returnwert von malloc prüfen solltest wenn du willst dass dein Programm in solchen speziellen Situationen nicht trotzdem abkackt.

Wenn du willst kannst du aber natürlich ne eigene malloc Implementierung schreiben die nen Haufen retries macht mit ein bisschen sleep() dazwischen. Und dann nach einer bestimmten Zeit, wenns bis dahin immer noch nicht geklappt hat, einfach abort() aufruft. Dann musst du den Returnwert nicht mehr prüfen

Und natürlich willst du in 32 Bit Prozessen immer den Returnwert von malloc() prüfen.

hustbaer schrieb:

Und wenn diese Vermutungen zutreffen, dann heisst das dass du trotzdem den Returnwert von malloc prüfen solltest wenn du willst dass dein Programm in solchen speziellen Situationen nicht trotzdem abkackt.

Den Rückgabewert von malloc muss man natürlich immer prüfen.
Ich will doch hoffen, das selbst bei 64 bit, malloc(-1) fehlschlägt.

Wenn du willst kannst du aber natürlich ne eigene malloc Implementierung schreiben die nen Haufen retries macht mit ein bisschen sleep() dazwischen. Und dann nach einer bestimmten Zeit, wenns bis dahin immer noch nicht geklappt hat, einfach abort() aufruft. Dann musst du den Returnwert nicht mehr prüfen

oh oh, das klingt ungemütlich. Wenn ich C programmiere, sieht meine malloc Implementierung in pseudo-code so aus:

void* xmalloc (size_t n) {return malloc(n) or abort ("malloc failed");}

(abgeguckt von git und anderen)

In C++ ignoriere ich einfach bad_alloc() und wünsche mir, dass niemand jemals catch(std::exception) oder catch(...) macht.
Das ganze bad_alloc()-exception-Konzept ist IMHO für den Eimer.