|
AW: Delphi vs Visual C++
Zitat:
(  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ö |
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.
|
AW: Delphi vs Visual C++
Zitat:
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 |
AW: Delphi vs Visual C++
Zitat:
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 |
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. |
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] |
AW: Delphi vs Visual C++
Zitat:
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:
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:
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. |
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 |
AW: Delphi vs Visual C++
Zitat:
|
| Alle Zeitangaben in WEZ +1. Es ist jetzt 12:27 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz