Enormer Performanceunterschied zwischen 32 und 64 Bit?

[Desmulator]

Zitat:

Zitat von mkinzler (Beitrag 1278316)

Das gilt für IA64 und nicht für X32_64. Dort läuft auch alles nativ auf dem Prozessor

Hat sich der Fragesteller denn schon zu seiner Prozessorarchitektur geäußert? Habe ich dann wohl überlesen ~ ...

[Bernhard Geyer]

Zitat:

Zitat von Desmulator (Beitrag 1278319)

Zitat:

Zitat von mkinzler (Beitrag 1278316)

Das gilt für IA64 und nicht für X32_64. Dort läuft auch alles nativ auf dem Prozessor

Hat sich der Fragesteller denn schon zu seiner Prozessorarchitektur geäußert? Habe ich dann wohl überlesen ~ ...

Im Privatbereich wird man praktisch keine IA64-Rechern antreffen. Und auch bei den Servern dürfte IA64 eher ein Exote sein. Werden die Prozessoren überhaupt noch verkauft?

[stahli]

[DerBlindeÜberFarben-Modus]
Hieß es nicht mal, dass C++ für 64bit einen völlig neuen Compiler bekommen sollte (LLVM)?
Ich hätte zwar gedacht, das würde (weil es eine Zwischenschicht ähnlich .net wäre langsamer...
Hat es vielleicht damit was zu tun?
Ansonsten vielleicht einfach mal MEissing anfragen. Sowas beantwortet er ja i.d.R. schon.
[/DerBlindeÜberFarben-Modus]

[mkinzler]

Visual C++ wird wohl eher kein LLVM verwenden, C++-Builder schon.

[stahli]

Stimmt. Brille ist geputzt. :)

[Bernhard Geyer]

Zitat:

Zitat von stahli (Beitrag 1278324)

[DerBlindeÜberFarben-Modus]
Hieß es nicht mal, dass C++ für 64bit einen völlig neuen Compiler bekommen sollte (LLVM)?
Ich hätte zwar gedacht, das würde (weil es eine Zwischenschicht ähnlich .net wäre langsamer... Hat es vielleicht damit was zu tun?
[/DerBlindeÜberFarben-Modus]

Wie ein Compiler aufgebaut ist hat nix mit der Ausführungsgeschwindigkeit des Compilats zu tun.
Diese "Zwischenschicht" ist eher eine Architektur mit der der Compiler einfacher, modularer und einfacher Optimierbarer entwickelt werden kann.
Der (vermutlich fast nahezu nicht mehr erweiterbare) 32-Bit Compiler von Delphi wäre das gegenstück zu einem auf LLVM aufsetzenden Compiler.

[Zacherl]

Zitat:

Zitat von Dejan Vu (Beitrag 1278309)

Hast das mal eingegrenzt?
Sind es die Switches? Die Lookups? Die Unterfunktionen?
Wäre doch ein Leichtes, ein paar Tests zu machen.

Habe wie gesagt den VS2013 internen Profiler mehrmals drüberlaufen lassen. Dort sehe ich zwar, welche Funktion wie viel Prozent der Gesamtlaufzeit für sich beansprucht, aber die prozentualen Werte unterscheiden sich bei den 2 Versionen nicht wirklich.
Der einzige Unterschied ist, dass das 32 Bit Kompilat eine durchweg deutlich langsamere absolute Laufzeit hat (das gillt auch für externe Runtime Funktionen wie z.b. "sprintf").

Es gibt auch keine Funktion, welche allein betrachtet herraussticht (alle lowest-level Methoden beanspruchen höchstens mal 4% der Gesamtlaufzeit).

Zitat:

Zitat von Bernhard Geyer (Beitrag 1278318)

Diese Erklärung gilt nur für die gescheiterte IA64-Architektur. Die jetzt von Intel als x64 (Ursprünglich von AMD entwickelt) bekannte Architektur emuliert für 32-Bit SW gar nix in SW. Alles wird 100% vom Prozessor direkt ausgeführt. Diese SW-Emulation war ein Hauptgrund wieso Intel mit IA64 gescheitert ist. Niemand wollte einen neuen Recher der für 99% der damaligen SW erheblich langsamer gewesen wäre. Einfach mal die Wiki-Artikel zu IA64 und x64 durchlesen.

Exakt. Ich besitze einen "normalen" i7 Prozessor von Intel, welcher die im Desktopbereich übliche x86-64 Architektur verwendet.

Was den Compiler angeht:
Ich verwende wie gesagt Visual Studio 2013, dementsprechend wird mit MSVC12 kompiliert (das Ding ist dem Delphi Compiler was Performance und Optimierung angeht um Jahrzehnte vorraus). Beide Versionen meines Programms habe ich aber als Release kompiliert, von daher werden beide Kompilate auch maximal optimiert. In IDA (Disassembler) konnte ich zudem einen, beim kurzen überfliegen, fast identischen Aufbau der Programme auf Assembler-Ebene feststellen.

Vielleicht bin ich ja Opfer eines Bootkits geworden, dass alle meine 32 Bit Anwendungen Softwareseitig emuliert :stupid: :mrgreen: (ne Spaß bei Seite; das Problem tritt auch auf einem zweiten PC mit Intel Prozessor auf)

[Dejan Vu]

Zitat:

Zitat von Zacherl (Beitrag 1278347)

Zitat:

Zitat von Dejan Vu (Beitrag 1278309)

Hast das mal eingegrenzt?
Sind es die Switches? Die Lookups? Die Unterfunktionen?
Wäre doch ein Leichtes, ein paar Tests zu machen.

Habe wie gesagt den VS2013 internen Profiler mehrmals drüberlaufen lassen. Dort sehe ich zwar, welche Funktion wie viel Prozent der Gesamtlaufzeit für sich beansprucht, aber die prozentualen Werte unterscheiden sich bei den 2 Versionen nicht wirklich.

Einfach mal auf die Blöde:
100000x Datenlookup durchlaufen lassen.
100000x Switch durchlaufen lassen.

die 100000 sind natürlich nur Richtwerte. Vermutlich musst Du das millionenfach machen. 1x 64bit 1x 32bit. Da wird es doch Unterschiede geben. Pfeif mal auf den Profiler.

Wenn trotzdem alles gleich ist, dann ... irrst Du dich wohl :stupid: oder die Uhren gehen anders (Relativitätstheorie und so)

[Delphi-Laie]

Zitat:

Zitat von Zacherl (Beitrag 1278294)

• 32 Bit: ~9000ms
• 64 Bit: ~800ms

[...]

die 64 Bit Version über 90% schneller sein kann?

90%?

Sind es nicht eher 10%?

Zitat:

Zitat von Zacherl (Beitrag 1278294)

Das Ergebnis hat mich dann doch ziemlich erstaunt (beide Kompilate als Release erstellt):

Weil der Unterschied so gering ist? Der wird ohnehin immer geringer. Wachstum verläuft anfänglich exponentiell, gerät aber irgendwann in seine Sättigung und flacht wieder ab (so daß es eher eine Hyperbeltangensfunktion gleicht). Wir sind schon wieder im abflachenden Zweig, sodaß bei den Bitanzahlverdoppelungen die tatsächlichen Geschwindigkeitssteigerungen immer mehr den erhofften hinterherhinken.

[Valle]

Zähl mal die Nullen. ;-)

Da steht 9s und 0,8s. Gibt also rund 91%.