Problem mit Geschwindigkeit

[Uwe Raabe]

Wie sind datenA und datenB denn definiert?

[TomyN]

Zitat von Uwe Raabe:

Wie sind datenA und datenB denn definiert?

Code:

TAE = Array of Extended

Anzahl siehe den Post darüber.

[TurboMagic]

Hinweis: Extended wird bei x64 auf Double gekappt da der 64 Bit Compiler nicht die FPU sondern SSE2 benutzt. Evtl. könnte ein Wechsel auf Single noch signifikant was bringen, falls das genau genug ist.

[Stevie]

Intel VTune oder AMD μProf (je nach CPU) zur Hand nehmen und schauen, wo der Flaschenhals liegt.

[himitsu]

Extended war "eigentlich" nie zur Speicherung gedacht, sondern nur kurz während der Berechnung (drum kennen/kannten viele Programmiersprachen diesen Typ garnicht erst)

Tja, und wie schon erwähnt, gibt es den in Win64 garnicht mehr.
Extended außerhalb von Win32 ist im Delphi daher ein Alias für Double (Abwärtskompatibilität, damit Programme/Komponenten/Quellcodes von Programmierern, die es nicht besser wussten, dennoch kompilierbar bleiben)

Und dieses 10 Byte-Align vom Extended ist für das Caching auch nicht grade optimal.

[TomyN]

Hi,

Erstmal Danke für Euere Antworten.
Zuerst wollte ich nur verstehen, warum die Doppel-FFT teilweise langsamer ist als zwei einzelne FFTs, obwohl dabei deutlich weniger Berechnungen nötig sind. Da war die erste Antwort 'CPU-Cache' eigentlich schon die 'Lösung'.
Durch die weiteren Antworten bin ich aber etwas neugierig geworden und habe noch ein wenig rumgespielt. Ich habe jeweils 100 Durchläufe berechnen lassen (jeweils mit den gleichen Startdaten).

Wenn ich nach Windows 64 kompiliere, wird Extended wohl einfach in Double umgewandelt. Daher meine irrige Meinung, dass Extended mehr Präzision 'ohne Aufpreis' bringt (und daher die Umstellung von double auf Extended). Bei den Tests war jedenfalls kein Unterschied bei der Geschwindigkeit feststellbar.

Bei Win32 als Target ist ein Unterschied zwischen Extended und Double feststellbar, dieser ist in den meisten Fällen aber relativ gering, nur bei einer FFT-Größe fällt auf, dass der CPU Cache mit double noch zurecht kommt, mit Extended aber nicht mehr so gut (oder der Compiler deutlich unterschiedlich kompiliert). Da beträgt die Verbesserung fast 50%.

Single als Datentyp bringt bei Win64 keinerlei Vorteile sondern ist sogar etwas langsamer, speziell bei kleineren FFT Größen. Vermutlich wird da erstmal alles 'verdoubled' und zurück 'gesinglet', was auch etwas Zeit kostet.

Bei Win32 bringt single eine deutliche Verbesserung.

Bei single ist Win64 als Target deutlich langsamer als die Win32, ansonsten ca. 1/3 schneller.
Für mich habe ich aktuell entschieden auf double zu gehen und das Thema 'Abwärtskompatibilität zu 32Bit Windows' nochmals zu überdenken.

[freimatz]

Wie ist der Vergleich 32-Bit mit 64-Bit?

[TomyN]

Hier mal ein paar Zahlen
(A): Berechnung zweier FFTs hintereinander.
(B): Berechnung einer 'Dualen' FFT.

Kompiliert für win64 (Daten: double)

1024k FFT -> A: 289ms, B: 331ms
512k FFT -> A: 88ms, B: 139ms (!!)
256k FFT -> A: 29ms, B: 40ms (!!)
128k FFT -> A: 13ms, B: 13ms
64k FFT -> A: 6ms, B: 6ms
32k FFT -> A: 2,5ms, B: 2,4ms

Kompiliert für win32 (Daten: double)

1024k FFT -> A: 309ms, B: 350ms
512k FFT -> A: 96ms, B: 142ms (!!)
256k FFT -> A: 34ms, B: 38ms
128k FFT -> A: 16ms, B: 14ms
64k FFT -> A: 7ms, B: 6ms
32k FFT -> A: 3,0ms, B: 2,7ms

Irgendwie hängt das anscheinend sehr von der Umgebung ab. Wenn ich das Programm im VTune ausführe, dann bekomme ich (win32 + win64) bessere Werte bei der größten FFT (1024k FFT -> A: 286ms, B: 332ms, win32 und A:269ms, B: 315ms in win64), ab 512k sind die Resultate bei 32bit gleich, bei win64 gibt's bei 512k / 'dual' ein besseres Resultat ( 126ms zu 139ms).

Insgesamt sind die Unterschiede anscheinend sehr von der Umgebung abhängig, so dass ich das alles nur als große Richtung verstehe. Interessant war und ist es aber schon.

[Uwe Raabe]

Zitat von himitsu:

Tja, und wie schon erwähnt, gibt es den in Win64 garnicht mehr.

Zumindest git es noch den TExtended80Rec, mit dem man solche Zahlen auch aus einem Stream lesen kann. Der hat auch ein automatisches Fallback auf Extended unter Win32.

Um die Größe eines Extended festzustellen gibt es auch die Compilerdirektive $EXTENDEDIS10BYTES.

Zitat von TomyN:

Single als Datentyp bringt bei Win64 keinerlei Vorteile sondern ist sogar etwas langsamer, speziell bei kleineren FFT Größen. Vermutlich wird da erstmal alles 'verdoubled' und zurück 'gesinglet', was auch etwas Zeit kostet.

Dazu gibt es hier noch ein paar Informationen: Steuerung der Gleitkommagenauigkeit (Delphi für x64)

[TomyN]

Danke für die Infos.
Interessant finde ich auch, dass der Einsatz von Int64 für die Indizes die Performance sowohl für win32 (da hätte ich es erwartet) aber auch für win64 (was mich überrascht) deutlich verschlechtert.