Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   Delphi vs Visual C++ (https://www.delphipraxis.net/190996-delphi-vs-visual-c.html)

BigAl 28. Nov 2016 09:26

Delphi vs Visual C++
 
Hallo zusammen,

mich beschäftigt hier ein Thema, welches ich eigentlich so nie erwartet hätte. Kurz zum Hintergrund:

Ich habe hier über mehrere Jahre ein recht umfangreiches Projekt mit Delphi entwickelt. Das Projekt besteht aus mehreren Teilprogrammen. Eines dieser Teilprogramme ist ein Gleichungslöser, welcher große Matrizen mit komplexen Zahlen (Double-Komplex) nach Gauss löst. Bei diesem Programm handelt es sich um eine Kommandozeilen-Applikation, welche die vorbereitete Matrix in den Speicher lädt (aktuelle Berechnung ca. 25.000 Unbekannte), den "Solver" durchläuft und die Ergebnisse dann zur Weiterverarbeitung speichert.

Das Programm benötigt mit Delphi deutlich mehr als eine Stunde. Dazu muss man sagen, dass es bereits extrem optimiert ist. Ich habe die Matrix-Zugriffe soweit als möglich optimiert (z.T. auf Assembler-Ebene) sowie die Algorithmus selbst solange umgestellt bis ich die beste Laufzeit hatte. Vieles arbeitet als inline um die Aufrufzeiten weiter zu optimieren. Alle Compilerschalter wurden auf Leistung eingestellt. Weiterhin wurde der Algorithmus soweit angepasst, dass er in einer Multi-Thread Umgebung läuft und die verfügbaren CPU-Kerne des Systems soweit als möglich ausnutzt. Das Testsystem besitzt zwei XEON-Prozessoren mit jeweils 10 Kernen. Jeder zusätzlich Kern bracht in der Vergangenheit eine Geschwindigkeitssteigerung.

Nun hatten wir die Idee die CUDA-Kerne der Grafikkarte zum Berechnen zu nutzen. Dafür habe ich das Programm nun in C++ (Visual Studio) noch einmal geschrieben. Hierbei habe ich dann festgestellt, dass ich bereits mit etwa 8 CPU-Kernen das volle Leistungspotential erreiche und die Applikation mehr als doppelt so schnell rechnet (Ergebnis liegt nach etwa 30 Minuten vor). Weiteres Forschen ergab dann, dass der Flaschenhals nun nicht mehr die CPU-Kerne sondern der Speicherzugriff ist (die Test-Matrix hat eine Größe von ca. 9 GB). Ich muss dazu sagen, dass die komplette Matrix für die Berechnung in den Speicher geladen wird (MMF). CUDA-Programmierung würde das Ganze nicht mehr beschleunigen, da die Speicherzugriffe nicht mehr so effizient wären...

Ich habe nun festgestellt, dass das C++-Programm wesentlich effizienter arbeitet. Schaue ich mir den erzeugten Assembler-Code an, so ist der in Delphi zwar kompakter, in C++ jedoch wesentlich besser auf Geschwindigkeit optimiert. Es werden z.B. mehr die verfügbaren CPU-Register eingesetzt.

Ich denke nun ernsthaft darüber nach auch andere rechenintensive Programmteile nach C++ zu portieren. Die Sprache an sich gefällt mir zwar lange nicht so gut wie mein geliebtes Delphi aber das Ergebnis ist schon beeindruckend.

Habt Ihr ähnliche Erfahrungen gemacht?
Warum optimiert der C++-Compiler um so vieles besser als der Delphi-Compiler? (die Einzelthread rechnet etwa vier bis fünf mal schneller)

Mich würden mal Eure Erfahrung zu dem Thema interessieren. Habt Ihr ähnliche gemacht?

Alex

Sherlock 28. Nov 2016 09:39

AW: Delphi vs Visual C++
 
Kurz gesagt, und auch wenn es grob klingt, nicht böse gemeint: was Du da entdeckt hast, ist allgemein bekannt. C/C++ erzeugt deutlich schnellere und kompaktere Binaries als Delphi. Aber Numbercrunching ist nicht Delphis Spezialgebiet. Da geht es hauptsächlich um die Entwicklung hübscher Anwendungen für Fat Clients.

Sherlock

TiGü 28. Nov 2016 09:47

AW: Delphi vs Visual C++
 
Hast du bei der Neuimplementierung auf gängige Bibliotheken gesetzt oder alles wieder von Hand implementiert? OpenCL? C++ AMP?

Kurz und schmerzlos: Der Delphi Compiler ist für derartige Anwendungen eben nicht optimiert und wird es wohl nicht werden.
Allein schon aus dem Umstand heraus, dass die Mannschaft hinter dem Visual C++-Compiler wohl um ein Vielfaches größer sein wird, als das zuständige Team bei Embarcadero.

BigAl 28. Nov 2016 09:51

AW: Delphi vs Visual C++
 
Zitat:

Zitat von Sherlock (Beitrag 1354807)
Kurz gesagt, und auch wenn es grob klingt, nicht böse gemeint: was Du da entdeckt hast, ist allgemein bekannt. C/C++ erzeugt deutlich schnellere und kompaktere Binaries als Delphi. Aber Numbercrunching ist nicht Delphis Spezialgebiet. Da geht es hauptsächlich um die Entwicklung hübscher Anwendungen für Fat Clients.

Sherlock

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...

Aber ich gebe Dir recht. Für Oberfläche / GUI und Datenbank würde ich immer Delphi so ziemlich allem anderen vorziehen (was kenne). Bei rechenintensiven Programmen werde ich künftig aber wohl eher C/C++ einsetzen. Ich denke auch schon darüber nach das ganze mal unter Linux zu testen. Da hatte ich in der Vergangenheit - speziell bei Zugriffszeiten auf den Speicher - auch schon interessante Ergebnisse erzielt. 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...

Alex

BigAl 28. Nov 2016 09:56

AW: Delphi vs Visual C++
 
Zitat:

Zitat von TiGü (Beitrag 1354809)
Hast du bei der Neuimplementierung auf gängige Bibliotheken gesetzt oder alles wieder von Hand implementiert? OpenCL? C++ AMP?

Kurz und schmerzlos: Der Delphi Compiler ist für derartige Anwendungen eben nicht optimiert und wird es wohl nicht werden.
Allein schon aus dem Umstand heraus, dass die Mannschaft hinter dem Visual C++-Compiler wohl um ein Vielfaches größer sein wird, als das zuständige Team bei Embarcadero.

Das Rahmenprogramm ist recht rudimentär. Kommandozeile halt. Der größte Unterschied dürfte wohl die Bibliothek für komplexe Zahlen sein. Bei C++ habe ich den Standardtyp "complex" verwendet (complex<double>). In Delphi habe ich das selbst geschrieben usw. mir möglich optimiert. Wie gesagt: Bereits kleine Umstellen bei der Berechnung haben teilweise ein paar Nanosekunden gebracht, was sich am Ende gleich wieder in Minuten geäußert hat. Das Delphi-Programm brauchte ursprünglich etwa vier Stunden. Ich habe so lange optimiert bis es "nur noch" etwas mehr als eine Stunde benötigte... Im C++-Programm habe ich bis jetzt noch gar nichts optimiert...

Alex

TiGü 28. Nov 2016 10:03

AW: Delphi vs Visual C++
 
Mal als Einstieg zu C++ AMP, denn die Stunde kriegst du bestimmt noch kürzer hin:
https://msdn.microsoft.com/en-us/library/hh873134.aspx

Der schöne Günther 28. Nov 2016 10:07

AW: Delphi vs Visual C++
 
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? :cyclops:

Ich stecke da schon viel zu lange nicht mehr drin, aber bist du dir wirklich sicher dass man mit CUDA/OpenCL nicht doch mehr rausholen kann? Die blanke Rechenleistung ist ja teilweise gewaltig, mit dem Hoch/runterladen auf den Speicher ... keine Ahnung wie viel sich da in den letzten Jahren getan hat...

Assarbad 28. Nov 2016 10:19

AW: Delphi vs Visual C++
 
Zitat:

Zitat von BigAl (Beitrag 1354810)
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:

Zitat von BigAl (Beitrag 1354810)
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:

Zitat von Der schöne Günther (Beitrag 1354815)
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? :cyclops:

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 28. Nov 2016 10:36

AW: Delphi vs Visual C++
 
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 28. Nov 2016 10:37

AW: Delphi vs Visual C++
 
Zitat:

Zitat von Der schöne Günther (Beitrag 1354815)
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? :cyclops:

Ich stecke da schon viel zu lange nicht mehr drin, aber bist du dir wirklich sicher dass man mit CUDA/OpenCL nicht doch mehr rausholen kann? Die blanke Rechenleistung ist ja teilweise gewaltig, mit dem Hoch/runterladen auf den Speicher ... keine Ahnung wie viel sich da in den letzten Jahren getan hat...

Hallo Günther,

bei CUDA sehe ich momentan das Problem mit dem Speicherzugriff. Natürlich ist der Speicher auf den Grafikkarten rasend schnell, allerdings muss erstmal das was berechnet wird dorthin kommen. Weiterhin kenne ich keine Grafikkarte, welche die gesamte Matrix aufnehmen könnte. Die besten Karten haben derzeit 4 GB. Wenn die Karte auf den Speicher des Host-Rechners zugreifen muss ist diese scheinbar langsamer als ein Zugriff durch den Hauptprozessor (so steht es zumindest in meinen CUDA-Büchern). Die GAUSS-Lösung benötigt halt anfangs den Zugriff auf die gesamte Matrix. Gegen Ende wird das zwar immer weniger, dann läuft es aber auch wesentlich schneller. Ich habe hier auch paar Artikel bezüglich paralleler Lösung durch Aufteilung in Untermatrizen, das übersteigt aber mein mathematisches Verständnis...

Alex

BigAl 28. Nov 2016 10:41

AW: Delphi vs Visual C++
 
Zitat:

Zitat von Chemiker (Beitrag 1354820)
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

BigAl 28. Nov 2016 10:47

AW: Delphi vs Visual C++
 
Zitat:

Zitat von TiGü (Beitrag 1354814)
Mal als Einstieg zu C++ AMP, denn die Stunde kriegst du bestimmt noch kürzer hin:
https://msdn.microsoft.com/en-us/library/hh873134.aspx

Das mit C++ AMP werde ich mir mal zu Gemüte führen. Das scheint sehr interessant zu sein.

Vielen Dank!

himitsu 28. Nov 2016 11:14

AW: Delphi vs Visual C++
 
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 28. Nov 2016 11:32

AW: Delphi vs Visual C++
 
Zitat:

Zitat von himitsu (Beitrag 1354827)
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 28. Nov 2016 11:41

AW: Delphi vs Visual C++
 
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 :lol:

Assarbad 28. Nov 2016 12:31

AW: Delphi vs Visual C++
 
Zitat:

Zitat von himitsu (Beitrag 1354833)
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 28. Nov 2016 13:25

AW: Delphi vs Visual C++
 
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 28. Nov 2016 14:09

AW: Delphi vs Visual C++
 
[QUOTE=Assarbad;1354834]
Zitat:

Zitat von himitsu (Beitrag 1354833)
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 28. Nov 2016 15:29

AW: Delphi vs Visual C++
 
Wenn noch nichts in den Speicher geschrieben wurde, also nur Nullen drin stehen, dann reserviert/mappt Windows dafür keinen physichen Speicher.

Assarbad 28. Nov 2016 15:40

AW: Delphi vs Visual C++
 
@himitsu: https://en.wikipedia.org/wiki/Virtua...ry_compression ... ist in Windows 10 enthalten. Er meint sicher das. Man könnte es als das Gegenstück zu "sparse files" betrachten.

Und zumindest die Strukturen für die Buchhaltung dieser vielen Speicherseiten muß Windows bereits bereitstellen. Ich schätze mal, daß dies der beobachtete Overhead ist.

@BigAl: ich meinte eher weniger klassische Komprimierungsalgorithmen als clevere Methoden um deine Daten auf weniger Speicher abzubilden. Das Buch ist auf Deutsch unter dem Titel "Perlen der Programmierkunst" im Handel oder vielleicht bei einer Bibliothek in deiner Nähe erhältlich. Seitdem wir nämlich Speicher- und Plattenplatz im Überfluß zur Verfügung haben und uns ggf. zukaufen können, machen sich viele Entwickler keine Gedanken mehr über die Algorithmen. Dabei liegt dort oft das eigentliche Optimierungspotential.

Rollo62 28. Nov 2016 15:58

AW: Delphi vs Visual C++
 
Wie sieht eigentlich Bcc vs Vc aus ?

Dalai 28. Nov 2016 16:08

AW: Delphi vs Visual C++
 
Zitat:

Zitat von BigAl (Beitrag 1354821)
Weiterhin kenne ich keine Grafikkarte, welche die gesamte Matrix aufnehmen könnte. Die besten Karten haben derzeit 4 GB.

Es gibt problemlos (mit dem nötigen Kleingeld) Karten mit bis zu 24 GB VRAM, nur mal eine Beispielliste mit Karten ab 8GB.

Grüße
Dalai

jfheins 28. Nov 2016 21:45

AW: Delphi vs Visual C++
 
Wenn du so ein Standard-Problem wie einen Gauss effizient rechnen möchstest, lohnt sich vielleicht auch ein Blick auf die Intel® Math Kernel Library kurz MKL.
Damit solltest du auf halbwegs aktuellen Intel-CPUs sehr gute Rechenzeiten erreichen. Wie ich Intel einschätze, werden AMD-CPUs von den Optimierungen nicht profitieren.

Ist deine Matrix eigentlich dicht besetzt?

Eventuell könntest du auch über algebraische Mutigrid-Verfahren nachdenken. Diese erstellen quasi eine kleinere Version deiner Matrix, lösen diese, und können mit dieser Näherungslösung die große Matrix schneller lösen.

Namenloser 28. Nov 2016 21:59

AW: Delphi vs Visual C++
 
Eine ziemlich coole Sache in C/C++ ist übrigens auch OpenMP. Noch nie war Parallelisierung so einfach.

BigAl 29. Nov 2016 08:20

AW: Delphi vs Visual C++
 
Hallo zusammen,

ist ja doch eine recht rege Diskussion geworden. Folgende Fragen / Kommentare bleiben allerdings doch:

1. Was soll Komprimierung bringen? Das ist doch noch einmal zusätzliche Rechenleistung die benötigt wird, oder?

2. Ja, meine Matrix ist dicht besetzt. 0-Felder gibt es praktisch keine.

3. Über Multigrid habe ich schon oft nachgedacht. Allerdings bräuchte ich da ein Beispiel um es zu verstehen.

4. Karten mit viel VRAM wären nur interessant wenn die nach oben offen / erweiterbar wären oder ich eine Möglichkeit hätte meine Matrizen in Schritten zu berechnen. Je nach Feinheit der Berechnungen kann die Größe auch noch ansteigen...

5. Richtig interessant finde ich AMP. Da muss ich mich mal intensiver mit beschäftigen.

Alex

Assarbad 29. Nov 2016 09:44

AW: Delphi vs Visual C++
 
Zitat:

Zitat von BigAl (Beitrag 1354871)
1. Was soll Komprimierung bringen? Das ist doch noch einmal zusätzliche Rechenleistung die benötigt wird, oder?

Lies dir bitte nochmal meinen Vorschlag durch.

Wenn du eine Zahl als String und Dezimalzahl darstellst, ist die üblicherweise auch länger als der gleiche Wert als Hexadezimalzahl (ohne spezielle Formatierung) dargestellt. Das ist auch eine Form von Komprimierung.

Wenn du bspw. sechzehnbittige Dezimalzahlen hast und sollst bei Speichermangel herausfinden ob es Lücken in der Zahlenreihe gibt, kannst du wahlweise eine Liste mit 16-bittigen Einträgen bauen und diese durchsuchen (2 x 2^16 == 2 x 65536 == 131072 Bytes), oder du bastelst dir ein Bitfeld aus 65536 Bits (8192 Bytes) und setzt jedes Bit je nach Index (== Zahlwert) oder eben nicht. Und jetzt denken wir uns das mal mit 32-bittigen Werten und dann kommt es auch näher an die Größenordnung deines Problems.

Das ist auch eine Komprimierung ohne klassische Komprimierungsalgorithmen (Deflate, bzip2, LZMA, PPMd).

Aber selbst klassische Algorithmen können manchmal was bringen, bspw. beim Abspeichern auf der Platte und darauffolgendem Einlesen in den Arbeitsspeicher. Es ist nämlich manchmal deutlich flotter etwas im Speicher per Inflate (Brotli usw. kämen auch in Frage) zu dekomprimieren als die bereits dekomprimierte Menge Daten vom Festspeicher zu lesen. Kommt natürlich auf den Festspeicher an, bei einer SSD wären die Vorteile deutlich geringer als bei einer Festplatte. Aber das ist auch einer der wenigen Gründe warum EXE-Packer manchmal Sinn machen. Sie können tatsächlich das Laden eines großen Programms beschleunigen (auch wenn sie danach CoW verhindern und somit ab einer zweiten Instanz mehr Speicher verbrauchen).

Und es ist klar, daß solche Ansätze wie die oben genannten nur dann infrage kommen, wenn die Struktur deiner Daten das zuläßt. Aber du könntest ja mal ne Woche so tun als gäbe es noch keine Grafikkarten mit viel RAM und als hätte dein Rechner nicht soviel RAM und versuchen anhand dieser Einschränkungen nach Optimierungen zu suchen. Manchmal fällt es einem dann wie Schuppen von den Augen.

Das ist so ähnlich wie bei den Fragen in einschlägigen Foren und F&A-Seiten ala "Wie kann ich mit meinem Spannungsprüfer am besten diese Sechskantschraube mit Mutter in meine Wand bekommen?". Das eigentliche Ziel ("Bild an Wand befestigen") bleibt bei solchen Fragen ungenannt und der Fragesteller erwartet eine sinnvolle Antwort die seinen Vorgaben folgt.

Kurzum: schau über den Tellerrand.

(Es kann natürlich sein, daß es andere Sachzwänge gibt, die - ebenfalls ungenannt - bedingen, daß viele unserer Vorschläge unsinnig sind. Dann solltest du diese Sachzwänge erwähnen.)

Zitat:

Zitat von BigAl (Beitrag 1354871)
5. Richtig interessant finde ich AMP. Da muss ich mich mal intensiver mit beschäftigen.

Wenn du nach wie vor mit Linux liebäugelst ist dies eine Einbahnstraße.

BigAl 29. Nov 2016 10:28

AW: Delphi vs Visual C++
 
Zitat:

Zitat von Assarbad (Beitrag 1354881)
Kurzum: schau über den Tellerrand.

Das man komprimieren kann ist schon klar. Aber:

1. Speichermangel habe ich nicht. Hauptspeicher lässt sich (nahezu) nach belieben kostengünstig hochrüsten.
2. Laden und Speichern der Daten ist recht flott (10 GB Matrix etwa 10 Sekunden)
3. Den Zugriff möchte ich so effizient wie möglich halten. Es wird eine Adresse berechnet. In Delphi z.B.:

Delphi-Quellcode:
function TMatrixMMF<T>.GetValue(Y, X: Cardinal): T;
type
  P = ^T;
begin
{$IFDEF CheckRange}
  if (X >= FCountX) or (Y >= FCountY) then
    raise EMatrix.CreateFmt('TMatrixMMF<%s>.GetValue(Y=%d, X=%d). Parameter out of Range', [GetTypeName, Y, X]);
{$ENDIF}
  Result := P(UInt64(FMMFPtr) + (Y * FCountX + X) * SizeOf(T))^;
end;
In C++ sieht das bei mir dann halt so aus (ohne generischen Type):

Code:
std::complex<double>& MatrixMV::get_Value(UINT32 Y, UINT32 X)
{
  return *(std::complex<double> *)((UINT64)m_pMapFile + (Y * m_SizeX + X) * sizeof(std::complex<double>));
}
Ich denke also alles Zusätzliche erhöht nur den Rechenaufwand. Obige Funktion ist nur ein Beispiel. Natürlich ist es effizienter im Programm direkt mit den Zielpointern zu arbeiten und nicht erst die Werte durch die Gegend zu kopieren...

Alex

BigAl 29. Nov 2016 10:33

AW: Delphi vs Visual C++
 
Zitat:

Zitat von Assarbad (Beitrag 1354881)
Zitat:

Zitat von BigAl (Beitrag 1354871)
5. Richtig interessant finde ich AMP. Da muss ich mich mal intensiver mit beschäftigen.

Wenn du nach wie vor mit Linux liebäugelst ist dies eine Einbahnstraße.

Ist schon klar, dass das dann unter Windows bleibt. Gefragt habe ich mich nur wie effizient Linux mit dem Speicher umgeht. Das Betriebssystem schleift sich ja (denke ich mir mal) selbst nochmal in jeden direkten Speicherzugriff ein. Wie sollte das sonst mit dem komprimierten Speicher, dem Swappen etc. funktionieren... Meine Abdresse kann ja letztendlich sonstwo landen...

Alex

Der schöne Günther 29. Nov 2016 11:09

AW: Delphi vs Visual C++
 
Ganz unabhängig vom Compiler und Speicher: Hast du nun einen Profiler überhaupt mal laufen lassen? Vielleicht bin ich einfach nur schlecht, aber mich überrascht oft genug "Ach DA geht die ganze Rechenzeit hin..."

BUG 29. Nov 2016 19:48

AW: Delphi vs Visual C++
 
Zitat:

Zitat von BigAl (Beitrag 1354889)
Das Betriebssystem schleift sich ja (denke ich mir mal) selbst nochmal in jeden direkten Speicherzugriff ein.

Die Übersetzung von logischer zu physischer Adresse macht die MMU in Hardware. Nicht präsente Einträge in den Übersetzungstabellen führen zu Zugriffsfehlern, die das Betriebssystem dann behandeln kann. Also keine zusätzlichen Kosten für erfolgreiche Zugriffe.

Für numerische Anwendungen wäre es nicht so ungewöhnlich, dass der gesamte genutzte Speicher auch wirklich im physischem Speicher liegt.

hanvas 29. Nov 2016 21:47

AW: Delphi vs Visual C++
 
Zitat:

1. Speichermangel habe ich nicht. Hauptspeicher lässt sich (nahezu) nach belieben kostengünstig hochrüsten.
2. Laden und Speichern der Daten ist recht flott (10 GB Matrix etwa 10 Sekunden)
Wenn das deine "typischen" Größen sind (und die 10GB und mehr zum Ausschluss von CUDA geführt haben) könntest Du es auch mal mit Vector Pascal

(https://sourceforge.net/projects/vectorpascalcom/)

probieren. Das ist ein autoparalelisierender (SIMD,MIMD) Compiler mit einer Delphi sehr ähnlichen Sprache. Auch wenn es auf den ersten Blick so aussiehr als ob das Projekt nicht mehr gepflegt wird, das stimmt nicht, das letzte Update ist etwas älter als einen Monat. Als Ziel kommt auch CUDA in Frage, aber eben auch "normale" CPUS mit oder ohne MMX, SSE, AVX usw. Paralelisierung per Threads wird auch unterstützt und sogar der XEON Phi. Mit den richtigen Einstellungen landet das Compilat in einer DLL welche Du dann wieder in einer Hochsprache einbinden kannst.

Die Dokumentation ist von 2005 - natürlich werden auch moderne Zielprozessoren unterstützt nur ist das dort nicht entsprechend dokumentiert. Es gibt auch ein Buch dazu (https://www.amazon.de/Glasgow-Pascal...or-extensions/) - das ist aber nicht unbedingt up to date und die vorhandene Doku ist einigermaßen ausreichend und ähnlich aussagekräftig (http://www.dcs.gla.ac.uk/%7Ewpc/repo...dex/manual.pdf).

hth Ha-Jö

brechi 29. Nov 2016 21:52

AW: Delphi vs Visual C++
 
Du solltest wirklich mal sagen was du genau vor hast. Dein Speicherzugriff ist ja schon nicht optimal. Du hast dir da eine GetPixel Funktion gebastelt, obwohl bekannt sein sollte, dass Scanline schneller ist, und selbst das kann noch parallelisiert werden... Wie schon gesagt, schau dir mal die o.g. Bibliotheken an und versuch den algorithmus zu optimieren.

BigAl 30. Nov 2016 09:17

AW: Delphi vs Visual C++
 
Zitat:

Zitat von brechi (Beitrag 1354974)
Du solltest wirklich mal sagen was du genau vor hast. Dein Speicherzugriff ist ja schon nicht optimal. Du hast dir da eine GetPixel Funktion gebastelt, obwohl bekannt sein sollte, dass Scanline schneller ist, und selbst das kann noch parallelisiert werden... Wie schon gesagt, schau dir mal die o.g. Bibliotheken an und versuch den algorithmus zu optimieren.

??? GetPixel ???
Wo bitte sollte ScanLine seine Daten hinschreiben wenn nicht wieder in den Speicher? Das Problem ist halt, dass man (zumindest bei Beginn) alle Daten Anfassen muss. Um beim Beispiel zu bleiben ScanLine entgegen GetPixel ist im Wesentlichen auch nur dadurch schneller weil eine größere Datenmenge in bereits optimiertem Code verarbeitet wird und sich die Menge der Funktionsaufrufe etc. verringert.

Vielleich noch ein Gedankengang den ich auch schon hatte: Wenn ich die Matrix zweimal im Speicher anlege, dann könnte ich evtl. den Algorithmus des Solvers invertieren. Ich würde dann nicht mehr von 1..n sondern von n..1 arbeiten und könnte evtl. mit den Ergebnissen des vorherigen Laufs weiterarbeiten. Durch die gespiegelte Matrix hätte ich die originalen Werte ja noch im Zugriff...

Mein Ziel im Moment ist im Wesentlichen die Speicherzugriffe bzw. den Datentransfer zwischen Speicher und CPU zu minimieren. Das ist momentan der Flaschenhals. Wenn ich durch die Parallelisierung bereits mit ein paar Prozessoren an die Grenze stoße bringen da erstmal noch mehr Prozessoren nichts.

Alex

BigAl 30. Nov 2016 09:24

AW: Delphi vs Visual C++
 
Zitat:

Zitat von Der schöne Günther (Beitrag 1354893)
Ganz unabhängig vom Compiler und Speicher: Hast du nun einen Profiler überhaupt mal laufen lassen? Vielleicht bin ich einfach nur schlecht, aber mich überrascht oft genug "Ach DA geht die ganze Rechenzeit hin..."

Den Profiler hatte ich unter Delphi anfangs mal laufen. Ist schon mehr als ein Jahr her. Hatte damals noch die Vollversion von AQTime zur Verfügung. Da ist mir allerdings mittlerweile die Lizenz abgelaufen. Die habe und werde ich nicht mehr erneuern, da das Teil zum einen recht instabil zum anderen auf Dauer zu teuer ist. Leider bieten auch die nur noch Subscriptions...

Ein Problem bei den Profilern ist auch, dass die beim Messen das Ergebnis teilweise stark verfälschen. Der alte Spruch "wer misst, misst mist" trifft auch da leider wieder zu. Interessant waren natürlich die CallCounter etc. Das kann man aber mit entsprechendem Code auch mal schnell nachbilden wenn man einfach mal wissen will welche Funktionen wie oft benötigt werden etc.. Ich habe mir dann die "Zeitfresser" mal auf Assemblerebene angesehen und bei kleineren Funktionen auch schon mal die benötigten Taktzyklen ermittelt etc.

Alex

Blup 30. Nov 2016 09:59

AW: Delphi vs Visual C++
 
Das der C++ -Compiler besser optimierten Code liefert ist bekannt. Wenn das Programm dadurch aber erheblich schneller wird, könnte das aber an Fehlern bei der manuellen Optimierung liegen, die der Delphi-Compiler nicht erkennt.

Das wichtigste beim Parallelbetrieb mehrerer Prozessoren an einer Aufgabe ist, ein Speicherbereiche der gemeinsam von den Prozessoren gelesen wird, darf auf keinen Fall verändert werden. Ebenso darf ein Speicherbereich der von einem Prozessor verändert wird, nicht von anderen Prozessoren gelesen oder verändert werden.

Das größte Optimierungspotential ist aber fast nie beim Compiler zu suchen, sondern steckt in der Logik des Programms selbst.
Ohne Quelltext sind konkrete Vorschläge eher nicht möglich.

stahli 30. Nov 2016 10:06

AW: Delphi vs Visual C++
 
[OT, aber mal zu AQTime]
Die Lizenz dürfte, so wie ich es kenne, nicht auslaufen, nur die Updateberechtigung.
AQTime Pro sollte man nicht in die Delphi-IDE einbinden sondern extern benutzen. Dann ist das ein hilfreiches und stabiles Tool.
[/OT]

Assarbad 1. Dez 2016 01:00

AW: Delphi vs Visual C++
 
Zitat:

Zitat von BigAl (Beitrag 1355000)
Den Profiler hatte ich unter Delphi anfangs mal laufen. Ist schon mehr als ein Jahr her. Hatte damals noch die Vollversion von AQTime zur Verfügung. Da ist mir allerdings mittlerweile die Lizenz abgelaufen. Die habe und werde ich nicht mehr erneuern, da das Teil zum einen recht instabil zum anderen auf Dauer zu teuer ist. Leider bieten auch die nur noch Subscriptions...

Öhm nö: https://smartbear.com/product/aqtime-pro/pricing/

Ich hab mich soeben extra nochmal eingeloggt. Mein Abo lief im Oktober aus. Kann nach wie vor alles im Kundenbereich machen. Allein, es wird kein aktives Abo angezeigt.

Zitat:

Zitat von BigAl (Beitrag 1355000)
Ein Problem bei den Profilern ist auch, dass die beim Messen das Ergebnis teilweise stark verfälschen.

Ist das ein Vorurteil oder eine eigene bereits bewiesene Beobachtung? Auf modernen CPUs kommen nämlich Zähler in der CPU direkt zum Einsatz. Und durch die Instrumentalisierung des Codes kann man ja schon sehr gut den Overhead von eigentlichen Meßdaten trennen. Es gibt natürlich durchaus einiges zu beachten. Aber dann sind die Ergebnisse zumindest bei mir bisher sowohl mit AQTime als auch mit gprof und oprof und CacheGrind scheinbar vertrauenswürdig gewesen (eine Behebung führte zu Performanceschüben).

Sowas wie CacheGrind ist bspw. auch kein Profiler im klassischen Sinn. Und manchmal lehrt einen der Aufrufzähler des klassischen Profilers wo sich Flaschenhälse verstecken das zeilenweise Profiling verfeinert den Blick auf die Problembereiche dann gehörig. Schleifen aufzudröseln bringt ja öfter auch was (siehe memmove/memcpy).

Zitat:

Zitat von stahli (Beitrag 1355006)
[OT, aber mal zu AQTime]
Die Lizenz dürfte, so wie ich es kenne, nicht auslaufen, nur die Updateberechtigung.
[/OT]

Korrekt. Habe meine auch auslaufen lassen, da die Aktualisierungen in homöopathischen Dosen kommen und in keinem vernünftigen Verhältnis zum Preis stehen. Da bekomme ich bei IDA mehr pro Euro ;)
Auch haben die nach der Übernahme (AutomatedQA -> Smartbear) diese Softdongles (wieder mal SafeNet/Sentinel, zufällig jenes System welches ich 2002 auszutricksen mithalf) eingeführt, was mich unheimlich genervt hat. Zuvor hatte ich nämlich eine Lizenz die besagte, daß ich AQTime auf mehreren Rechnern, die ich allein nutze, installieren dürfe. Nach anfänglicher Beschwerde gab man mir dann eine Zweiplatzlizenz und die ging dann nach weiteren turnusmäßigen Aktualisierungen in eine Einzelplatzlizenz (node-locked) über.

BigAl 1. Dez 2016 10:22

AW: Delphi vs Visual C++
 
Habe eben mal nachgesehen. Die letzte für mich verfügbare AQTime-Version ist 8.22. Die kann ich auch nach wie vor herunterladen. Allerdings weiß ich nicht wie die sich mit Delphi 10.1 verträgt...

Mit verfälschen der Ergebnisse meine ich, dass sich z.T. das Laufzeitverhalten beim Messen stark verändert hatte. Und das leider nicht proportional. Manche Dinge wurden stärker beeinflusst als andere. Wie gesagt: Es ist schon eine Weile her dass ich das Profiling gemacht habe. Ich weiß nicht mehr genau wo das war. Evtl. starte ich da nochmal eine Session.

Alex

Assarbad 1. Dez 2016 11:02

AW: Delphi vs Visual C++
 
Zitat:

Zitat von BigAl (Beitrag 1355088)
Habe eben mal nachgesehen. Die letzte für mich verfügbare AQTime-Version ist 8.22. Die kann ich auch nach wie vor herunterladen. Allerdings weiß ich nicht wie die sich mit Delphi 10.1 verträgt...

Die Integration möglicherweise nicht, aber dann kannste immer noch die selbständige Version von AQTime nehmen, die auch installiert wird.


Alle Zeitangaben in WEZ +1. Es ist jetzt 13:01 Uhr.

Powered by vBulletin® Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf