|
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 |
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 |
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. |
AW: Delphi vs Visual C++
Zitat:
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 |
AW: Delphi vs Visual C++
Zitat:
Alex |
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 |
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... |
AW: Delphi vs Visual C++
Zitat:
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:
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:
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. |
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 |
AW: Delphi vs Visual C++
Zitat:
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 |
AW: Delphi vs Visual C++
Zitat:
Alex |
AW: Delphi vs Visual C++
Zitat:
Vielen Dank! |
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? |
AW: Delphi vs Visual C++
Zitat:
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. |
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: |
AW: Delphi vs Visual C++
Zitat:
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:
|
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. |
AW: Delphi vs Visual C++
[QUOTE=Assarbad;1354834]
Zitat:
Alex |
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.
|
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. |
AW: Delphi vs Visual C++
Wie sieht eigentlich Bcc vs Vc aus ?
|
AW: Delphi vs Visual C++
Zitat:
Beispielliste mit Karten ab 8GB.Grüße Dalai |
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. |
AW: Delphi vs Visual C++
Eine ziemlich coole Sache in C/C++ ist übrigens auch OpenMP. Noch nie war Parallelisierung so einfach.
|
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 |
AW: Delphi vs Visual C++
Zitat:
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:
|
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) 3. Den Zugriff möchte ich so effizient wie möglich halten. Es wird eine Adresse berechnet. In Delphi z.B.:
Delphi-Quellcode:
In C++ sieht das bei mir dann halt so aus (ohne generischen Type):
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;
Code:
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...
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>)); } Alex |
AW: Delphi vs Visual C++
Zitat:
Alex |
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..."
|
AW: Delphi vs Visual C++
Zitat:
Für numerische Anwendungen wäre es nicht so ungewöhnlich, dass der gesamte genutzte Speicher auch wirklich im physischem Speicher liegt. |
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 19:13 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