Delphi vs Visual C++

**hanvas**

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

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

Zitat von brechi:

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

Zitat von Der schöne Günther:

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

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

[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**

Zitat von BigAl:

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 von BigAl:

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 von stahli:

[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**

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

Zitat von BigAl:

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.