Problem mit Geschwindigkeit

[TomyN]

Hi,

Den Gedanken hatte ich auch schon. Dann habe ich die Datensatzgröße halbiert, leider ohne Verbesserung, d.h. der Effekt bleibt genauso.
Leider hab ich bei dem Thema 'Caching' keine Ahnung, da ich Programmieren gelernt habe, als man noch strukturiert Programmiert hat ..

Tomy

[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?

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