Delphi vs Visual C++

[Assarbad]

Zitat von BigAl:

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.

Zitat von BigAl:

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.

Zitat von Der schöne Günther:

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.

[Chemiker]

Hallo,

ein interessanter Beitrag.

Ich würde auch noch die Anmerkung machen grade im Hinblick auf die Speicherzugriffe, ob es sich um 32- oder 64 –Bit Programme handelt.

Bis bald Chemiker

[BigAl]

Zitat von Chemiker:

Hallo,

ein interessanter Beitrag.

Ich würde auch noch die Anmerkung machen grade im Hinblick auf die Speicherzugriffe, ob es sich um 32- oder 64 –Bit Programme handelt.

Bis bald Chemiker

Hi, das Programm ist "natürlich" für 64-Bit Architektur. Ansonsten gäbe es Probleme mit der Speicheradressierung...

Alex

[himitsu]

MMF mit 9GB
Genug physischen RAM hast du auch oder muß Windows hier auch noch fleißig Daten zwischen RAM und HDD umschaufeln?

Eventuell auch die Speicherzugriffe im Algo optimieren, damit die zugriffe auf den RAM nicht zu sehr verteilt sind?

[BigAl]

Zitat von himitsu:

MMF mit 9GB
Genug physischen RAM hast du auch oder muß Windows hier auch noch fleißig Daten zwischen RAM und HDD umschaufeln?

Eventuell auch die Speicherzugriffe im Algo optimieren, damit die zugriffe auf den RAM nicht zu sehr verteilt sind?

Hi, das merkt man recht schnell wenn nicht genug physischer RAM da ist. Dann kann die Rechenzeit schnell in die Tage gehen . RAM hat der Rechner 64 GB.

Das mit den Speicherzugriffen verteilen ist auch so eine Sache. Wie gesagt: Ich habe hier eine Beschreibung "Lösung linearer Gleichungssysteme auf Parallelrechnern" von Andreas Frommer (Uni Karlsruhe) aber das übersteigt meine Fähigkeiten im Bereich Mathematik.

[himitsu]

Gut, wollte nur sicher gehn.

Wobei.
Ich hab dem Windows hier gesagt, es soll den RAM "vorzugsweise" für Programme nutzen, aber dennoch wird die WFC bevorzugt.
12 Kerne und auch 64 GB RAM

Aber seit 1-2 Monaten (paar Windows-Updates) scheint es sich verbessert zu haben.
Eventuell liegt es auch mit daran,dass wir das Webzeugs (Mail/WebServer) in 'ne VM umgelagert haben. (vorallem der Sicherheit wegen, da sich mal wer in den Webserver gehackt hatte)
Vorher war der RAM oftmals randvoll mit dem Cache (Standby+Geändert) und Programme (in Verwendung) wurden ausgelagert.
Aktuell haben wir meistens ein noch paar GB "ungenutzt/frei".
Kopiere mir grade die Arbeitsverzeichnisse eines kranken Kollegen, da geht das wieder hoch und unsere SSD schafft plötzlich nur noch 5 MB/s

[Assarbad]

Zitat von himitsu:

Ich hab dem Windows hier gesagt, es soll den RAM "vorzugsweise" für Programme nutzen, aber dennoch wird die WFC bevorzugt.
12 Kerne und auch 64 GB RAM

Diese Annahme geht dem grundlegenden Design von Windows aber zuwider. Du kannst zwar in die eine oder andere Richtung lenken, aber du kannst keine tiefergehenden Entscheidungen des MM beeinflussen. Im Benutzermodus haste ohnehin keinen Zugriff auf den echten Speicher, es sei denn ein Treiber gibt dir irgendwie Zugriff. Allerdings ist auch der Speicher den Treiber anfordern können begrenzt. Wobei eben der NonPagedPool (also Speicher der nicht ausgelagert wird) noch immer nicht der echte RAM ist, sondern noch immer eine Abstraktion des physischen Speichers bei welcher die CPU mithilft. In den meisten Fällen spielt das aber keine Rolle, weil der MM zwar faul konzipiert ist, bei Zugriff auf ausgelagerten Speicher aber fleißig wird. Und eine MMF ist nunmal quasi das Gegenteil der Auslagerungsdatei. Sozusagen eine Einlagerungsdatei von der aus Daten in den Speicher gescheffelt werden müssen.

Bei einem Problem mit derlei vielen Daten die im Speicher vorliegen müssen, könnte es auch hilfreich sein nachzudenken inwieweit die Daten komprimierbar sind ohne die Berechnung zu behindern. Buchempfehlung: "Programming Pearls" von Bentley.

RamMap von Sysinternals/Microsoft bietet übrigens einen guten Überblick über die aktuelle Speicherverwendung.

@BigAl: die eine FirePro von AMD ist glaub ich auch mit 32 GB RAM verfügbar.

Zitat:

Die S9170 verwendet den gleichen Grafikchip wie die S9150. Er stammt aus der Hawaii-Serie, enthält 2816 Rechenkerne und ist zu OpenCL 2.0, OpenMP 4.0 und OpenACC kompatibel; zum Nvidia-exklusiven CUDA freilich nicht.

[himitsu]

Nee, "direkten" Einfluss hat man eh nicht.
Es gibt da nur so 'nen Registry-Flag, womit man dem MM sagen können soll, was er "mehr" bevorzugen solle.

Aber wenn man schon 50 GB Cache im RAM liegen hat, dann wäre es nett, wenn der MM zuerst "älteren" Cache entsorgen würde, anstatt "jüngere" aktive Programme auszulagern, die ne halbe Minute später wieder zurück in den RAM geladen werden müssen.

Die Seitenfehler im DWM, im Explorer und im Delphi waren auch immer schön viele.
Arbeitsspeicher (privat) gegen Zugesicherte Größe sahen da im Taskmanager auch immer schön ungleichmäßig aus.



Und so sinnlose Programme, die sich RAM-Cleaner schimpfen, will auch keiner benutzen.

[BigAl]

[QUOTE=Assarbad;1354834]

Zitat von himitsu:

Bei einem Problem mit derlei vielen Daten die im Speicher vorliegen müssen, könnte es auch hilfreich sein nachzudenken inwieweit die Daten komprimierbar sind ohne die Berechnung zu behindern. Buchempfehlung: "Programming Pearls" von Bentley.

Windows komprimiert ja schon von sich aus. Im Taskmanager von Windows 10 (und 8 auch glaube ich) heißt es ja "In Verwendung (komprimiert)". Wenn ich die leere Matrix (alle Felder 0i0) im Speicher erzeuge, dann werden für die Größe mit 25.000 Elementen = 25.000 * 25.000 * 16 Byte = 1e+10 Byte (~9,3 GB) nur ein paar MB belegt. Erst wenn ich die "echten" Daten hole, dann bläht sich der Speicher auf. Leider handelt es sich nicht um eine dünnbesetzte Matrix. Da bringt komprimieren nicht viel...

Alex

[himitsu]

Wenn noch nichts in den Speicher geschrieben wurde, also nur Nullen drin stehen, dann reserviert/mappt Windows dafür keinen physichen Speicher.