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).
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
(ne Spaß bei Seite; das Problem tritt auch auf einem zweiten PC mit Intel Prozessor auf)