Verwendet Freepascal wirklich * far * weniger Speicher als gcc

Beachten Sie, dass die Startzeit IIRC ein weiterer Benchmark ist, bei dem FPC-Peaks

Ich denke, die Antwort muss in erster Linie in der Tatsache gesucht werden, dass Free Pascal statisch Programme standardmäßig verbindet, libc und andere Hilfsbibliotheks vermeidend

Dies hat mehrere Konsequenzen:

• Bei den einfachen Programmen, für die ein Benchmarking durchgeführt wird, sind FPC-Programme statisch und verwenden nur die eigene RTL (keine statische Kopie von libc) und haben keinen dynamischen Linking-Overhead (sowohl hinsichtlich Zeit als auch Arbeitsspeicher). Einschließlich der Zuordnung geteilter Glibc-Segmente (ist das so?), Die fälschlicherweise für die Verwendung des Anwendungsspeichers gehalten werden.
• libc könnte möglicherweise nicht benötigte Initialisierungen ausführen, die FPC für diese einfachen Programme nicht durchführt. (wie zoneinfo initialisieren)
• Da FPC einen völlig unabhängigen Speichermanager verwendet, könnte der erste Block des Heap-Unterzuweisers eine andere Größe haben. Möglicherweise sind FPCs systematisch kleiner.
• Bei Threads kann die Größe des Stacks des neuen Threads verschiedene Unterschiede verursachen (Größe und vielleicht die Tatsache, ob es (nur) eine Reservierung oder einen festgeschriebenen Speicher ist oder was auch immer das * nix-Äquivalent davon ist)

Alles in allem denke ich, dass dieses beobachtete Verhalten weniger auf FPC als vielmehr auf mangelnder Variation zwischen den anderen benchmarkten Entwicklungssystemen beruht . FPC hebt sich nur dadurch hervor, dass fast alles andere auf der gcc / glibc-Technologie basiert (entweder weil es sich um ein direktes gcc-Derivat handelt oder weil ihre VM / Interpreter auf gcc aufgebaut sind) und somit alle die libcs ​​behandeln. FPC, die anders sind, hebt nur die schlechte Skalierung (lib) gegenüber einfachen Programmen hervor. (*)

Das Shootout kann wahrscheinlich in dem Sinne voreingenommen sein, dass entweder geteilter Adressraum gezählt wird, anstatt tatsächlich verwendete private Bytes, oder weil er nicht genügend zwischen privaten Bytes unterscheidet, die vom Unterzuordner und vom privaten zugeordnet sind Bytes, die tatsächlich vom Prozess verwendet werden. Es würde wahrscheinlich einen libc / libmalloc core devel benötigen, um dies zu klären, und da die Schießerei Open Source ist, ist die Frage offen, ob Sie eine bessere Messung anbieten können.

Entweder das oder etwas stimmt nicht grundlegend mit (g) libc. (Ich bin kein Experte dafür). Eine mögliche Lösung, um relevantere Informationen zu erhalten, wäre der Benchmark unter FreeBSD oder ein Linux mit uclibc. Kurz etwas anderes als glibc.

Wie Igoyys Post-Statements sagen, erhält FPC beim Verknüpfen mit libc die (schlechten) Eigenschaften der anderen Entwicklungssysteme. Dies ist ein weiterer Hinweis darauf, dass die Frage "Warum glibc mit Binaries schlecht im Shootout Memory-Benchmark funktioniert" und nicht "Warum schneidet FPC im Shootout-Benchmark gut ab"

Beachten Sie, dass FPC libc ursprünglich aufgrund von Kompatibilitätsproblemen bei der Verteilung von Distributionen und nicht der Leistung oder Dateigröße vermied.

Also nehmen wir an, dass dies ein Fehler ist, den Speicherverbrauch von FPC zu messen, jemals in Betracht gezogen, dass es ein Problem mit der Verwendung von Glibc-Speichern oder deren Messung ist? Oder eher, dass die high Glibc-Nummer falsch ist und nicht die niedrige FPC-Nummer ....

.... Ein FPC-Entwickler ....

(*) und bevor Sie sagen können, dass es nur für "beträchtliche" Anwendungen entwickelt wurde, denken Sie daran, dass die Unix Philosophie darin besteht, kleine Werkzeuge miteinander zu verketten und viele Unix-Prozesse kurzlebig zu machen .

Ja, es stimmt wirklich , dass das Unix-Dienstprogramm oben meldet, dass diese Pascal-Programme so viel Speicher verwenden, und diese C ++ - Programme verwenden so viel Speicher.

Zum Beispiel auf x64, während das Free Pascal n-body Programm wird ausgeführt und während des C ++ - N-Body-Programms wird ausgeführt, oben meldet diese Messungen -

Der Speicher verwendet top Berichte für die Free Pascal-Programme ist den Speicher, den das Benchmark-Spiel für die Free Pascal-Programme verwendet .

Sehen Sie sich nun x64 Quad-Core-Vergleich

Wir können zwei verschiedene Fälle sehen:

1. Sowohl die Pascal- als auch die C ++ - Programme verwenden mehrere MBs und die Speicherbelegung ist sehr ähnlich und unterscheidet sich um weniger als ~ 2x. Wenn zusätzlicher Speicher vorhanden ist zugeordnet, um die Aufgabe zu lösen, gibt es nicht viel Unterschied zwischen den Programme.

2. Die C ++ - Programme verwenden einige hundert KB und das Pascal-Programm verwendet a einige KB. Wenn zusätzlicher Speicher nicht zugeordnet ist, um die Aufgabe zu lösen, wird die Pascal-Programme verwenden ein paar hundert KB weniger.

Die Frage stellt zwei Alternativen vor, aber es gibt gewöhnlich eine dritte Alternative - Habe ich falsch verstanden, was vor sich geht?

Die Tatsache, dass ein C ++ Mandelbrot-Programm 4000x mehr Speicher als ein Pascal Mandelbrot-Programm verwenden konnte, war zu viel für das OP, schien es dem OP unmöglich <- aber es gibt eine einfache Erklärung, Zeit / Raum-Kompromiss .