Enormer Performanceunterschied zwischen 32 und 64 Bit?

[Zacherl]

Hallo zusammen,

ich arbeite momentan an einem C++ Projekt mit Visual Studio 2013, zu dem ich leider nicht näheres sagen kann. Grob beschrieben ist es ein Parser für ein relativ komplexes Datenformat.

Jetzt habe ich mir mal eine kleine Anwendung geschrieben, welche einfach nur 100MiB an Daten sequenziell dekodiert.

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

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

Die Dekodierung basiert größtenteils auf arithmetischen und logischen Funktionen, ein paar Lookups in einer Datentabelle, ein paar Switches und das ganze verpackt in einige Unterfunktionen. Dazu kommen noch einige "sprintf" Aufrufe (welche laut Profiler sowohl in der 32, als auch der 64 Bit Version relativ langsam sind).

Ich weiß, es sind recht wenig Infos, aber kann sich jemand erklären, wie die 64 Bit Version über 90% schneller sein kann? :shock:

Viele Grüße
Zacherl

[Namenloser]

Bei 64 Bit ist der virtuelle Adressraum größer und fragmentiert daher nicht so leicht. Aber ob sich das auf herkömmliche Speichermanager auch auswirkt, weiß ich nicht. Ich habe es nur vor allem bei Firefox beobachtet, dass der unter 64 Bit einfach viel besser läuft als unter 32 Bit, obwohl er netto nicht mal mehr Speicher in Anspruch nimmt. Unter 32 Bit hatte ich alle paar Sekunden Ruckler, wenn der Garbage Collector angesprungen ist, unter 64 Bit läuft alles flüssig.

Ansonsten: Keine Ahnung... Alignment vielleicht? Bessere Cache-Ausnutzung? Oder der Compiler benutzt unter 64 Bit irgendwelche Super-Spezial-Instruktionen...

[Zacherl]

Benutze momentan ausschließlich statischen Speicher (bzw. einen Vector, welcher aber nur einmalig alloziiert wird), deshalb denke ich nicht, dass dieser enorme Boost mit geringerer Speicherfragmentierung zu erklären ist.
Spezialinstruktionen kann ich ebenfalls zu 99% ausschließen. Sah auf den ersten Blick in IDA zumindest alles recht ähnlich aus und die selben AVX Instructions, die ich bei der 64 Bit Version finden konnte, existierten meistens auch beim 32 Bit Kompilat.

Hatte den Verdacht, dass es daran liegt, dass ich viele 64 bit Integer verwende (auch unter 32 Bit), aber laut Stackoverflow macht das von der Performance her keinen allzu drastischen unterschied (Addition war glaube ich 2 statt 1 Instruktion, etc).

Die einzigen zwei Dinge, die mir noch in den Sinn kamen, sind:

1. die effizientere Callingconvention unter 64 Bit
2. die zusätzlichen 8 General-Purpose Register unter 64 bit

Bloß lese ich überall, dass man bei 64 Bit Kompilaten mit ca. 2-20% Performancezuwachs rechnen kann. In meinem Fall sind es halt über 90%, weshalb ich mir irgendwie Gedanken mache unter 32 Bit auf gut Deutsch irgendwas verkackt zu haben.

Der Profiler von VS2013 kann mir leider auch keinen genaueren Einblick verschaffen. Der prozentuale Anteil der einzelnen Funktionen ist bei beiden Kompilaten in etwa gleich. Der einzige Unterschied ist wirklich, dass die Ausführung der Methoden unter 32 bit signifikant länger dauert.

[Namenloser]

Zitat:

Zitat von Zacherl (Beitrag 1278305)

Benutze momentan ausschließlich statischen Speicher (bzw. einen Vector, welcher aber nur einmalig alloziiert wird), deshalb denke ich nicht, dass dieser enorme Boost mit geringerer Speicherfragmentierung zu erklären ist.
Spezialinstruktionen kann ich ebenfalls zu 99% ausschließen. Sah auf den ersten Blick in IDA zumindest alles recht ähnlich aus und die selben AVX Instructions, die ich bei der 64 Bit Version finden konnte, existierten meistens auch beim 32 Bit Kompilat.

Hatte den Verdacht, dass es daran liegt, dass ich viele 64 bit Integer verwende (auch unter 32 Bit), aber laut Stackoverflow macht das von der Performance her keinen allzu drastischen unterschied (Addition war glaube ich 2 statt 1 Instruktion, etc).

Könnte mir schon vorstellen, dass das einen ziemlichen Unterschied macht, nicht nur wegen weniger Instruktionen, sondern auch weil ein Int64 unter 64 Bit genau in ein Register passt. Ich weiß nicht, ob unter 32 Bit der Compiler überhaupt in der Lage ist, 64 Bit-Integer in Registern zu speichern, oder ob sich dort dann alles zwangsweise auf dem langsameren Stack abspielt (und höchstens mal eine Hälfte für Zwischenberechnungen in ein Register geladen wird). Aber so oder so bleiben natürlich unter 64 Bit dadurch viel mehr freie Register übrig, die entsprechend genutzt werden können. Dazu kommen dann noch obendrauf nochmal die zusätzlichen 8 Register.

Edit:
Du könntest ja mal valgrind drauf loslassen. Soweit ich weiß kann man sich da auch Statistiken zur CPU-Cache-Effizienz und ähnlichem Low-Level-Kram ausgeben lassen.

[himitsu]

Eine 32-Bit-CPU/FPU, bzw. der 32-Bit Teil einer CPU, für die 32-Bit-Programme, kann natürlich nur mit 32-Bit-Integern rechnen.
Bei Fließkommazahlen bis 64/80 Bit.

Wenn ihr mal in die CPU-Ansicht schauen würdet, dann hättet ihr bemerkt, daß 64-Bit-Integeroperationen in Win32 nur "emuliert" werden, indem die Rechenoperationen auf zwei 32-Bit-Integer aufgeteilt werden, was natürlich nicht wirklich schnell sein kann.

PS: schaut mal in die System.pas und haltet ausschau nach

Delphi-Quellcode:

{ 64-bit Integer helper routines }
{$IF defined(CPU386)}
procedure __llmul;
procedure __lldiv;
procedure __lludiv;
procedure __llmod;
procedure __llmulo;
procedure __lldivo;
procedure __llmodo;
procedure __llumod;
procedure __llshl;
procedure __llushr;
{$ENDIF}

Das sint praktisch die Funktionen, welche Delphi/C++ intern benutzt, wenn man *, div, mod, shl usw. auf Int64 oder UInt64 anwendet. :stupid:

Ja, via SSE/MMX gibt es auch in Win32 ein paar 64- und 128-Bit-Register, aber diese sind ja nicht für einen Wert vorgesehn, sondern stellen eine Technik zur Stream-/Parallelverarbeitung mehrerer gleichartiger Berechnungen dar.

[Zacherl]

Zitat:

Zitat von Namenloser (Beitrag 1278306)

Du könntest ja mal valgrind drauf loslassen. Soweit ich weiß kann man sich da auch Statistiken zur CPU-Cache-Effizienz und ähnlichem Low-Level-Kram ausgeben lassen.

Danke, ich werds mir mal anschauen!

Zitat:

Zitat von himitsu (Beitrag 1278307)

Wenn ihr mal in die CPU-Ansicht schauen würdet, dann hättet ihr bemerkt, daß 64-Bit-Integeroperationen in Win32 nur "emuliert" werden, indem die Rechenoperationen auf zwei 32-Bit-Integer aufgeteilt werden, was natürlich nicht wirklich schnell sein kann.

Das ist mir schon bewusst, deshalb hatte ich ja auch den entsprechenden Verdacht, dass es an der expliziten Verwendung des uint64_t Datentyps liegen könnte :D Die Sache ist, dass nur ca. 5% der Berechnungen wirklich mit diesen Variablen durchgeführt werden. Eben da, wo es wirklich notwendig ist einen großen Integertyp zu verwenden. Das kann einfach nicht einen Performanceunterschied von über 90% ausmachen :cry:

Da die Verteilung im Profiler doch ziemlich gleich aussieht, ist der für mich plausibelste Grund momentan die Existenz der 8 zusätzlichen GP-Register und die langsamere Callingconvention.

[Dejan Vu]

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

[Desmulator]

Hat irgendjemand schonmal in betracht gezogen, dass auf einem 64-Bit Windows 32-Bit Anwendungen mittels WOW64 emuliert werden? Das heiß im Klartext:

Zitat:

Trotz der äußerlichen Ähnlichkeit auf allen 64-Bit-Versionen von Windows unterscheidet sich die Implementierung von WOW64 aufgrund der Architektur des Ziel-Prozessors. Die 64-Bit-Version von Windows beispielsweise, welche für Intel-Itanium-2-Prozessoren entwickelt wurde (bei Microsoft IA-64-Architektur genannt), benutzt die Wow64win.dll für die Emulation von x86-Anweisungen mittels des Befehlssatzes des Itanium 2. Diese Emulation ist rechenaufwendiger als die Funktionen der Wow64win.dll auf AMD64-Architekturen, welche lediglich den Prozessor aus dem 64-Bit-Modus in den 32-Bit-Modus schalten, während ein 32-Bit-Thread ausgeführt wird. Auf AMD64-Systemen ist für WOW64 keine Emulation notwendig.

Man könnte tippen, dass du einen Intel-Prozessor hast?
Also werden die Befehle in SOFTWARE verarbeitet und nicht vom Prozessor direkt ausgeführt.

Ich denke, das ist der Hauptgrund, warum das ganze so langsam ist. Wohl gemerkt solltest du dein Programm mal auf einem echten 32-Bit windows testen... vermutlich läuft es dort deutlich schneller.

[mkinzler]

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

[Bernhard Geyer]

Zitat:

Zitat von Desmulator (Beitrag 1278315)

Ich denke, das ist der Hauptgrund, warum das ganze so langsam ist. Wohl gemerkt solltest du dein Programm mal auf einem echten 32-Bit windows testen... vermutlich läuft es dort deutlich schneller.

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.

[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%.

[Dejan Vu]

Von den Nullen her stimmts doch. 90 hat eine Null, 10 hat eine Null. Und eine Null ist es ja auch weniger. :stupid: