|
AW: Delphi 64 Bit langsamer als 32 Bit
@Patito: Da SSE imho SIMD arbeitet (nämlich mit je 2 Werten in einer OP), halte ich die Aussage für doch sehr gewagt. Zudem: Brauchst du die Nachkommastellen wirklich alle täglich? Wenn man derart präzise werden muss, ist man doch ohnehin ziemlich schnell bei einer N-Bit Library. (Ansonsten hast du vermutlich oftmals den falschen Datentyp (bzw. schlecht optimierte Rechenwege) benutzt.)
|
AW: Delphi 64 Bit langsamer als 32 Bit
Liste der Anhänge anzeigen (Anzahl: 1)
Interessant, wie viel es hier zu lesen gibt. Eine spannende Aussage ist (da hatte ich gar nicht daran gedacht), dass der 64 Bit-Compiler ja auch (mittels $IFDEF...) teilweise anderen Code nutzt.
Ich habe vor kurzem auch mal ein paar Tests mit ein paar zentralen Funktionen meiner Applikation gemacht. Ich konnte z. T. die Geschwindigkeit durch einfaches Umformulieren erheblich beschleunigen (siehe Anhang). Klar, wir reden von Millisekunden oder Mikrosekunden. Wenn aber eine Durchlauf nachher 3 Minuten anstelle von 5 Minuten braucht, und es sind 100 Durchläufe durchzuführen, dann reden wir von 200 Minuten Einsparung. Diese zentralen Funktionen werden halt teilweise mehrere Milliarden(!) mal aufgerufen. Alex |
AW: Delphi 64 Bit langsamer als 32 Bit
Delphi-Quellcode:
Du überprüfst auf vollständige Gleichheit von IDs[] und ID; u.U. reicht hier auch eine "Teil"-Prüfung ( ich kenne die Deklaration von TfemIDs ja nicht)
function femIDsExists(const IDs: TfemIDs; const ID: Integer): Boolean;
// prüfen, ob ein Eintrag in einer Liste vorhanden ist begin for CheckID := Low(IDs) to High(IDs) do if IDs[CheckID] = ID then Exit( True); result := False; end; |
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
TfemIDs: array of Integer; Ist ja nur ein Bespiel. Obige Funktion soll halt prüfen, ob ein Integerwert in einen dynamischen Array existiert. Das Beispiel soll halt auch verdeutlichen wie ein einfaches umformulieren manchmal was anderes erzeugen kann... Alex |
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
|
AW: Delphi 64 Bit langsamer als 32 Bit
In der 64-Bit Implementierung aber auch nur 32Bit.
|
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
|
AW: Delphi 64 Bit langsamer als 32 Bit
Oder man ersetzt INTEGER durch NativeInt
|
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
 http://channel9.msdn.com/Events/Build/2013/4-329 |
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
Wurde mit Einführung des 32-Bit-Delphis noch großspurig von "generisch" gesprochen, so daß man sich über das "automatische Mitwachsen" der (passend gewählten, also generischen) integren Datentypen bei Bitanzahlvergrößerung des Compilates freuen konnte, ist dieser gute Vorsatz keine 20 Jahre (!) später schon wieder passé und obsolet. Schade. |
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
|
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
|
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
|
AW: Delphi 64 Bit langsamer als 32 Bit
Es ging darum warum Microsoft 32bit auf 64bit Systemen standardmäíg installiert. Es ging nicht um JVCL Kompatibilität.
|
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
Aber von diesen Typersetzungen halte ich nicht viel, da sie im Quelltext an einer konkreten Stelle (abgesehen von Mouseover-Hints) nicht direkt ersichtlich sind. Da schreibe ich es lieber dort hin wo es wirklich gebraucht wird und nehme das IFDEF in Kauf... Beruflich habe ich das Problem ohnehin nicht, da wir Wartungsverträge haben und die Projekte nicht viele Delphiversionen zurückliegen, wenn überhaupt. Aber bei Open Source sieht das halt anders aus... |
AW: Delphi 64 Bit langsamer als 32 Bit
Microsoft hat sich das mit der Frage, wo welches Office installiert werden sollte, schon überlegt. Es gibt reichlich Dokumente dazu, z.B. Folgendes:
http://office.microsoft.com/en-us/wo...010369476.aspxKurzfassung ist wohl, dass die überwiegende Mehrheit der Anwender keinen Vorteil aus den weiteren 32bit ziehen kann. Und die Entscheidung, den Datentyp "int" bei 32-Bit zu belassen ist ja nicht aus der Hüfte heraus getroffen worden. Und schon gar nicht von Embarcadero. Wir dürfen dabei nicht vergessen, dass wir mit Delphi für ein Betriebssystem bzw. Framework - hier: Windows - programmieren und gut damit beraten sind, uns dessen Datenmodels zu bedienen. Alles andere würde unnötige Komplikationen mit sich bringen. Also könnte man auf Microsoft einprügeln - das geht im Allgemeinen ganz gut, man ist ja in Übung. *g* Aber ... auch bei C unter Linux ist der Datentyp "int" 32-Bit. Und bei Mac OS X ebenfalls. Es steht uns natürlich frei, dies weiterhin als skandalös zu empfinden, aber so langsam drängt sich die Frage nach dem "warum" auf. Als das Thema "64 Bit" akut wurde, lag damit natürlich auch die Frage auf dem Tisch, wie man mit den Datentypen umgehen möge. In der Sprache C beispielsweise ist der Datentyp "int" der Meist-Genutzte. Die Entscheidung, wie mit ihm zu verfahren sei, wollte also wohl überlegt werden. Was haben sie getan? Die Entwickler von Microsoft und auch die der Unix-Gemeinde haben unabhängig voneinander Analysearbeit betrieben und einfach eine Art Bestandsaufnahme gemacht. Wo wird der Datentyp "int" genutzt und was bringt es jeweils, diesen um weitere 32 Bit zu ergänzen. Alle Beteiligten kamen zu dem Schluss, dass es in der überwiegenden Mehrheit an Fällen eben gerade keinen Vorteil brächte, weitere 32 Bit zu spendieren oder zu vergeuden. Dies führte zu der bewussten Entscheidung für das Datenmodell "LLP64" (Windows) bzw. "LP64" (Unix / Linux), bei dem der Datentyp "int" eben bei seinen alten 32 Bit verblieb. (Datenmodelle: http://en.wikipedia.org/wiki/64-bit_...it_data_models)Bei Windows kam noch ein weiterer Aspekt hinzu: Die Interoperabilität von Win32 und Win64. http://blogs.msdn.com/b/oldnewthing/...31/363790.aspx So sind z.B. die Header von Bitmap-Dateien recht klar strukturiert und hätten allesamt neu angepasst werden müssen. Ein Mords-Aufwand für Null Ertrag. |
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
Deshalb hätte es dort keinerlei Anpassungsbedarf gegeben. Dass Integer an vielen Stellen benutzt wurde, wo eigentlich eher ein anderer Typ gepasst hätte, mag ja sein, aber letztlich wurde so die falsche Verwendung statt LongInt nachträglich als korrekt erklärt zu Lasten all derjenigen, die den Typ seiner Definition entsprechend genutzt haben. Das finde ich nun einmal nicht gut. Für 32-Bit gab und gibt es LongInt und dessen Name ist ja nicht umsonst entsprechend gewählt worden, eigentlich mit einer klaren Abgrenzung zum Typ Integer, der eine solche Größenangabe gerade nicht enthielt. Nichtsdestotrotz hilft die nachträgliche Diskussion auch nicht weiter. Diejenigen, die sich an die Dokumentation gehalten haben, müssen ihren Quelltext anpassen, die, die es nicht getan haben, können lachen und weitermachen. Aber das ist nun eben so, ändern lässt es sich nicht mehr. |
AW: Delphi 64 Bit langsamer als 32 Bit
Alles ganz einfach:
1. 64 bit müssen einfach langsamer sein als 32 bit, weil die Pipelines im Prozessor mehr Füllung haben, um das mal so auszudrücken. 2. Floats unter 64 bit sind schneller, weil Delphi da die neuen SSE-Befehle nutzt. In 32 bit wird der uralte FPU-Codegenerator von Turbo Pascal anno 1988 benutzt. |
AW: Delphi 64 Bit langsamer als 32 Bit
In diesem Blog geht es zwar um die Problematik MSSQL 64bit ist teilweise langsamer als 32bit.
Jedoch die Ansatzpunkte sind nicht schlecht (in der zweiten Hälfte). http://blogs.msdn.com/b/sqlprogramma...edirected=true |
AW: Delphi 64 Bit langsamer als 32 Bit
Um mal noch kurz einzustreuen, wie das bei Free Pascal ist:
Da die FPU nur unter Windows 64-Bit als "deprecated" deklariert ist, nicht aber unter Linux, Mac OS X und Co verwenden wir nur unter Win64 per default die SSE Unit (Standard ist hier SSE Version 1) mit maximal Double-Precision, aber unter den anderen x86_64-Systemen verwenden wir weiterhin per Default die FPU mit Extended-Precision. Es gibt übrigens ein Define für den Compiler, welches es erlaubt auch die FPU für Win64 zu verwenden, dieses ist aber standardmäßig deaktiviert (und wahrscheinlich auch nicht wirklich getestet). Dies funktioniert aber deswegen, weil Windows trotzdem die FPU Register sichern muss, damit 32-Bit Anwendungen (welche ja die FPU erwarten) weiterhin korrekt laufen. Die Verwendung von SSE bedeutet aber nicht automatisch, dass der Compiler auch Vectorizing oder ähnliche Späße macht. In dem Zusammenhang wird SSE einfach nicht als SIMD, sondern als SISD (Single Instruction Single Data) verwendet... Das es manchmal sinnvoll sein kann von SSE auf SSE2 oder SSE3 zu wechseln zeigt dieser Bugreport in dem die Laufzeit eines Algorithmus unter x86_64 von 125ms auf 64ms gedrückt werden konnte (und noch ein paar Millisekunden mehr nach einer weiteren Optimierung).Ein anderer Fall ist "reine Pascalcode" vs. "Assemblercode". Da hatten wir das Beispiel von
Delphi-Quellcode:
und
Move
Delphi-Quellcode:
. Die Einführung von Assemblerroutinen für diese beiden Basisfunktionen hat bei einem Nutzer den Code von etwa 4 Sekunden auf etwa 500ms beschleunigt. :mrgreen:
FillChar
Nebenbei erwähnt: FPC erlaubt es auch für x86_64 die Verwendung von inline Assembler Abschnitten (es muss also nicht die gesamte Routine Assembler sein). :) Gruß, Sven |
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
Leute die solche Berechnungen mit Millionen Daten und Millarden Operationen darauf machen, haben ja meist dicke Rechner mit mehreren Prozessoren. (GPUs usw. lassen wir mal ganz außen vor.) Bei den oben erwähnten C++ Lösungen dafür hat man ja heute Libs zum z.B. große Arrays auf CPUs zu partitionieren und hinterher die Teillösungen zusammenzubringen. Sind die Delphi/Pascal Lösungen dafür Assemblerroutinen und Threads ? Tiling, Loadbalancing usw. alles händisch ? Arbeitet nicht die Zeit gegen solche Lösungen ? Es gibt schliessich immer mehr Kerne auf CPUs, die aber einzeln nicht schneller werden. |
AW: Delphi 64 Bit langsamer als 32 Bit
@Robotiker: Wir befinden uns hier in einem Delphi (also Pascal Forum) und da wunderst Du dich, dass man hier über Delphi diskutiert? Nach Deiner Definition/Sichtweise gibt es natürlich keinen Grund überhaupt auf die Idee zu kommen, etwas nicht mit (Visual) C++ zu lösen zu wollen, da man mit VC++ ja alles besser machen kann als mit irgendeinem anderen Tool.
Native Gemüter (was wir ja aus Deiner Sicht zu sein scheinen) verwenden, aus vielleicht sentimentalen Gründen, "veraltete" Dinge wie Delphi/FPC/Lazarus, ... Dieser Beitrag habe ich als Mitglied und nichta als Moderator verfasst, das heisst er muss nicht unbedingt der Meinung des Teams entsprechen. |
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
Der Fragesteller hat weiter oben festgestellt, dass ihm schon eine kleine Verbesserung des Codes 200 Minuten (!) Verbesserung bringen würden. Ist es bei solchen Dimensionen vermessen mal zu fragen, warum keiner überhaupt mal über das Thema Parallelisierung redet ? Ich arbeite seit Turbo Pascal 3 mit Pascal, aber bei solchen Aufgaben heute nicht mehr. Aber ich habe Erfahrungen mit solchen Datenmengen. Geht es hier also darum möglichst schnell solche Berechnungen zu lösen, oder einfach nur darum "ein Programm wie früher" zu schreiben ? Besteht "native Code Performance" in Delphi heutzutage daraus "stunning multimedia apps" in FireMonkey zu schreiben, über die dann alle ganz "exited" sind ? Meine Absicht war nicht den Fragesteller zu einer anderen Programmiersprache zu drängen, sondern zu zeigen, was man braucht um auf heutiger Hardware solche Probleme zu lösen. Deswegen meine Frage, ob und wie man sich bei FreePascal dieser Entwicklung stellt. Das solche Frage nicht erwünscht sind, weil man ja auf dem richten Weg ist, habe ich jetzt verstanden. |
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
Zitat:
Zitat:
Zitat:
|
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
Hat nicht JT von Embarcadero einen Blogeintrag darüber geschrieben, dass man das MS Rest SDK im BCB integriert, da ist die PPLx enthalten, die Cross-Plattform Opensource Variante der PPL aus VC. Ich hatte eigentlich durchaus den Eindruck, dass es hier Leute gibt, die professionelle leistungsfähige Software erstellen. Die auch mal eine Blick über den Tellerrand wagen, sei es auch nur um sich Ideen für die Entwicklung in Delphi zu holen. Vom Fragesteller hatte ich schon den Eindruck, dass er sich ernsthaft mit der Materie auseinandersetzt. Ist da ein Link auf ein Video zu MS, wo gezeigt wird, wie man Schleifen cachegünstig optimiert, schlecht, weil es von MS kommt ? Hat das nicht zumindest indirekt mit dem 32/64 Bit Thema zu tun ? (Ganz sicher aber mit dem Problem des Fragestellers.) Gibt es auch nur ansatzweise ähnliche Doku bei Embarcadero, dann verweise ich gerne drauf ? |
AW: Delphi 64 Bit langsamer als 32 Bit
Das Thema war so angenehm zu lesen, eine wahrer Leuchtturm in den tosenden Böen des Internets. Jetzt nicht mehr. :(
Was hat das jetzt noch mit der ursprünglichen Frage am Hut? |
AW: Delphi 64 Bit langsamer als 32 Bit
Um das ganze wieder mehr relevant für Pascal zu machen hätte ich da die Frage wie es denn mit der Verwendung der GPU
in Pascal aussieht? Vermutlich ist da ein Hybrid aus solider Pascal-GUI und einem Number-Cruncher in C for CUDA sinnvoll. |
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
Auch in Pascal hängt die ganze 32/64 Bit Geschichte und eine mögliche Parallelisierung über die Cache-Problematik zusammen. Der 64-Bit Code ist ggf. größer, passt schlechter in den Cache. Noch schwieriger ist es bei Parallelisierung, wie in dem Video gezeigt, man muss möglichst viele "heiße" Daten beieinander halten. Ganz blöd wäre es, wenn man das ganze als Single Thread Lösung implementiert und dann mehrere Programme mit unterschiedlichen Daten parallel startet "um den Rechner besser auszulasten", die klauen sich dann gegenseitig Cache Kapazität. Die Kunst besteht darin eine Balance zischen Parallelisierung und Speicherdurchsatz zu finden, das eventuell auch skalierbar auf unterschiedlich großen PCs. Dazu muss man nicht umbedingt die zitieren Libs verwenden, aber da steckt viel Know-How drin, und in der Doku ist viel darüber geschrieben, wie man Probleme effizient aufteilt. |
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
|
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
Ich weiß nicht, wie die Bitbreite der Register die Pipeline beeinflussen sollten. Außerdem: Volle Pipeline, gute Pipeline :mrgreen: |
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
Meine Idee ist zum Beispiel die Funktionalität von Vector Pascal in FPC zu integrieren, was eine native Nutzung von SIMD Units ermöglichen würde (FPC unterstützt zwar aktuell SIMD Instructions, wendet die aber nur für einzelne Werte an, also eher als FPU-Ersatz). Dann müssten auch noch ein paar Optimierungen her wie Auto Vectorizing oder sonstige Nettigkeiten, wie sie LLVM zur Zeit bekommt. Vielleicht auch ein paar Threading Erweiterungen wie sie Oxygene kennt (z. B.
Delphi-Quellcode:
).
parallel for
Zitat:
Delphi-Quellcode:
und
FillChar
Delphi-Quellcode:
), da hierdurch Prozessorbefehle verwendet werden können, die der Compiler normalerweise nicht verwendet (ein Compiler reizt das Instruction Set eines Prozessors normal nie voll aus).
Move
Was aktuell (zumindest so weit ich das Überblicke) allerdings tatsächlich noch fehlt sind Frameworks (ich nenn es mal einfach so), die einem das Arbeiten mit und Verwalten von vielen Threads abnehmen (du magst das nennen wie du willst, aber von der OS Perspektive her sind es am Ende immer noch Threads, die da parallel laufen). Gruß, Sven |
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
|
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
In diese Richtung zielte ja meine Frage. Warum sollte man es nicht in Pascal machen können, wenn man es z.B. in Matlab hinkriegt. Gerade für solche mathematischen Sachen ist die Pascal-Syntax doch sehr lesbar. Im Grunde geht es ja nur darum, die Fähigkeiten aktueller Hardware auszunutzen. Diese riesigen Datenstrukturen des Threaderstellers kann man am besten bearbeiten, wenn man vorgeht, wie wenn man mit vielen Mähdreschern ein großes Kornfeld mäht. Man stellt alle in eine Reihe und fährt drüber, zusätzlich macht die Vektorisierung quasi jeden Mähdrescher breiter. Sowas kann man in Delphi derzeit nicht wirklich gut ausdrücken, und nur darum ging es mir. Es geht schliesslich darum, dass Berechnungen statt Stunden möglicherweise nur Minuten dauern. Statt zu sagen, "Oh, da haben wir ein Defizit" zu sagen "wir machen das aus sentimentalen Gründen" finde ich, bestenfalls, besorgniserregend. Aber so scheinen die Leute heute eingestellt zu sein, die bei Delphi geblieben sind. Schade. [Edit] Ja, Vector Pascal geht offensichtlich in die Richtung, die ich meine. |
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
Aber so was wäre schön (einfach die Diagramme anschauen, den Code ignorieren): http://www.parallel-universe-online....123-flow-graph[Edit] Sollte aber eigentlich mit dem neuen Compiler im Builder irgendwann verwendbar sein. |
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
Zitat:
So viele schöne Projekte, die man angehen könnte und so wenig Zeit... *seufz* Gruß, Sven |
AW: Delphi 64 Bit langsamer als 32 Bit
Klingt wie Concurrent Pascal oder SuperPascal.
Eine entsprechende Erweiterung für Delphi FPC wäre sicherlich nicht schlecht. |
AW: Delphi 64 Bit langsamer als 32 Bit
Generelle Überlegung: 16 bit ist schneller als 32 bit, 32 bit ist schneller als 64 bit. Trotzdem wurde nach 16 bit 32 bit eingeführt. Vorteil: Der Scrollbalken hat bei längeren Seiten kein Range-error ausgelöst. Und man konnte mehr Speicher adressieren. Alles hat Vor- und Nachteile. Es gibt ein paar Themen in der Mathematik, da sind 32 bit der reine Horror. Von daher kann 64 bit oder noch besser 128 bit nicht schnell genug kommen. Auch wenn 128 bit für 99% aller Computerbenutzer Perlen vor die Säue wäre.
|
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
Aber das nur als Zwischenruf... Sherlock |
AW: Delphi 64 Bit langsamer als 32 Bit
Zitat:
Und über eine 128 Bit Grafikkarte gähnen alle Hardcoregamer da die besseren Grafikkarten schon bei 384 Bit angekommen sind |
AW: Delphi 64 Bit langsamer als 32 Bit
ts ts ts
was man alles durcheinanderwürfeln kann - Operandenbreite CPU, Operandenbreite SIMD (hier auch gern über alle Operanden), Adressbreite logisch ,Adressbreite physisch implementiert, Datenbusbreite intern, Datenbusbreite extern ... |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 11:43 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