Wobei das mit den kompakteren Binaries relativ ist. Wenn ich bei C/C++ die zur Laufzeit benötigten DLLs berücksichtige ist der Unterschied nicht mehr so groß. Bei Delphi werden ja per default alle BPLs etc. direkt in die EXE eingebunden. Lagere ich diese aus, dann bleibt auch nicht mehr viel übrig...
Eigentlich würde es sich gehören zu erwähnen welche Bibliotheken du meinst, denn bei C++ ist die Sache eben im Gegensatz zur
VCL bei Delphi nicht eindeutig. Die VC++-Laufzeitbibliothek kann bei einem WTL-Programm bspw. mit eingelinkt werden und dann komme ich noch immer auf deutlich kleinere .exe-Dateien als mit Delphi. Selbst bei einem statisch gelinkten MFC-Programm gelingt dies oft. Nur wenn du sowas wie Qt oder wxWidgets einsetzt, wird der Overhead größer als bei Delphi.
Aber Größe ist ja nicht alles. Manchmal kann auch Assemblercode der länger ist schneller sein als jener der kürzer ist. Man denke nur an die Einzelfallbehandlung in memcpy/memmove um ausgerichtete DWORDs/QWORDs kopieren zu können statt einzelne Bytes.
Allerdings wäre das ein etwas aufwändigerer Test, da die Windows Funktion für MMF usw. ja dann nicht mehr funktionieren und ich die Linux-Pendants einsetzen müsste. Sollte mich da erstmal intensiver mit der Speicherverwaltung von Linux beschäftigen...
Ist eher einfacher als auf Windows, finde ich.
mmap() ist eigentlich fast schon alles was du benötigst.
Wenn du auf C++ usw. setzt würde ich dir wärmstens empfehlen dich mit existierenden Bibliotheken ala
SageMath oder Blitz++ usw. auseinanderzusetzen. Da existiert unter Umständen vieles schon und wurde oft von vielen Leuten bereits optimiert. Kann sein, daß du damit noch mehr rausholen kannst.
Zuguterletzt scheint sich bei dir dann auch der Einsatz eines Profilers zu rechnen. Auf Windows wären da AQTime (unterstützt übrigens auch Delphi) und vTune (kann auch Kerneltreiber analysieren). Auf Linux haste eine große Auswahl von gprof über oprof zu den exotischeren Vertretern. CacheGrind könnte auch Sinn machen, da es bei dir auch um kleinste Optimierungen geht.
Ich habe eigentlich nichts neues beizutragen, außer dass ich auch dachte dass der Geschwindigkeitsunterschied nicht so überraschend sein sollte. Hatten wir hier vor ein, zwei Jahren nicht sogar mal ein Thema wo selbst JavaScript im Browser schneller Rechnungen gelöst hat als eine DCC32-Delphi-Anwendung und alle waren danach ganz depressiv?
Nicht verwunderlich, da die heutigen JavaScript-VMs viel vom Code in nativen Code für die Ziel-CPU übersetzen (begann vor einigen Jahren mit V8). Da muß man schon auf einer sehr exotischen Architektur unterwegs sein um von diesen Optimierungen nicht zu profitieren.
Und wenn man dann noch betrachtet, daß allein der Umstieg vom mitgelieferten Compiler von MSVC langsameren Code erzeugt als der entsprechende (kompatible) Intel-Compiler - zumindest für Intel-CPUs - weißte auch bescheid. Da ist noch viel Potential, allein aufgrund der Tatsache daß Compiler wie Delphi oder MSVC für allgemeine Anwendungsfälle statt spezielle CPU-Modelle optimieren.