FFT-Calculator, AVX2-und AVX-Version

[Helle]

Davon habe ich mehrere am laufen !
Eben getestet, Durchschnittswerte für M50:
- Intel i7 7700K @5.0GHz: AVX=44.5s, AVX2=43.6s
- AMD Ryzen 7 1800X @3.7GHz: AVX=76.3s, AVX2=77.0s
Man sieht (wieder) den AMD-Nachteil bei 256-Bit-Register-Anwendungen.

[Sicro]

Mersenne M50

Code: Alles auswählen

AVX-Version:  70431ms
AVX2-Version: 69034ms

Getestet unter Linux und der CPU "Intel Core i7-6700K @ 8x 4.2GHz".

Beim Code bitte #MB_ICONERROR durch #PB_MessageRequester_Error und

Code: Alles auswählen

FontHigh = Int(9.0 / (GetDeviceCaps_(GetDC_(WindowID(0)), #LOGPIXELSY) / 96.0))     ;muss für anderes OS (hier Windows 64Bit) neu!
;LoadFont(0, "Arial", FontHigh)
LoadFont(0, "Trebuchet MS Fett", FontHigh)  ;in Windows 7 verfügbar; evtl.testen

durch

Code: Alles auswählen

;FontHigh = Int(9.0 / (GetDeviceCaps_(GetDC_(WindowID(0)), #LOGPIXELSY) / 96.0))     ;muss für anderes OS (hier Windows 64Bit) neu!
LoadFont(0, "Arial", 12)
;LoadFont(0, "Trebuchet MS Fett", FontHigh)  ;in Windows 7 verfügbar; evtl.testen

ersetzen. Dann funktioniert es auch unter Linux.

[ccode_new]

STRG+F oder ein Makro oder/und PureBasic eigene Konstanten (Der nicht Windowsnutzer würde sich freuen )

Anbei:
Ich habe mal den RAM beobachtet.
Das ganze benötigt gewaltig viel Speicher.

1. Programm nicht gestartet: RAM: 1,6 GB
2. Programm gestartet (M50): Ram steigt bis auf 6,72 GB
3. Nach der Berechnung behält sich das System 5,32 GB.
4. Nach Beendigung des Programms sinkt der RAM-Verbrauch wieder auf 1,68 GB

Beobachtung CPU: (Ich habe eine 4 Kern-Intel-CPU)
Vor der Berechnung: 3-7% Auslastung
Bei der Berechnung: Steigt auf ca. 30-40 % Gesamt - bleibt dann aber konstant bei um die 30% Auslastung, dabei wird immer im Wechsel ein Kern zu 100% ausgelastet.

Soviel zu meiner Beobachtung.

[NicTheQuick]

Meine olle CPU braucht für M50 83724 ms.

[Kiffi]

@Helle:

Die Abfrage des OS lieber mit Compiler-Direktiven gestalten. Denn so, wie es momentan ist, bekommt man unter Linux noch immer einer Fehlermeldung ("GetDeviceCaps_() is not a function..."):

also anstelle von:

Code: Alles auswählen

If OSVersion() > #PB_OS_Windows_XP And OSVersion() < #PB_OS_Linux_2_2     ;Linux fängt bei 1000 an
  ;Windows
  FontHigh = Int(9.0 / (GetDeviceCaps_(GetDC_(WindowID(0)), #LOGPIXELSY) / 96.0))   ;GetDeviceCaps kann bei der Bildschirmanpassung nützlich sein
  ;LoadFont(0, "Arial", FontHigh)
  LoadFont(0, "Trebuchet MS Fett", FontHigh)     ;in Windows 7 verfügbar; evtl.testen
 ElseIf OSVersion() >= #PB_OS_Linux_2_2 And OSVersion() < #PB_OS_MacOSX_10_0   ;MacOSX fängt bei 10000 an
  ;Linux
  LoadFont(0, "Arial", 12)   ;das hat Sicro zu verantworten :-). Unter Windows ist (bei mir) 12 zu groß
EndIf                        ;Mac?

besser das hier:

Code: Alles auswählen

Define FontHigh
Define FontName.s

CompilerSelect #PB_Compiler_OS 
    
  CompilerCase #PB_OS_Windows
    FontHigh = Int(9.0 / (GetDeviceCaps_(GetDC_(WindowID(0)), #LOGPIXELSY) / 96.0))   ; GetDeviceCaps kann bei der Bildschirmanpassung nützlich sein
    FontName = "Trebuchet MS Fett"                                                    ; in Windows 7 verfügbar; evtl.testen
    
  CompilerCase #PB_OS_Linux
    FontHigh = 12
    FontName = "Arial"
    
  CompilerCase #PB_OS_MacOS
    FontHigh = 12 ; ?
    FontName = "Arial" ; ?
    
CompilerEndSelect

LoadFont(0, FontName, FontHigh)

Grüße ... Peter

[Helle]

Liebe Linux-Jünger,
ich habe aus obigen Codes die zarten Kompatibilitäts-Annäherungen an Linux wieder entfernt. Beim Test mit der brandneuen PB-Version 5.46 LTS fiel mir wieder ein, weshalb ich z.B. die Konstante #PB_MessageRequester_Error nicht verwendet habe: Sie wird von den LTS-Versionen (Windows) schlicht nicht unterstützt. Ich selbst benutze aber LTS häufig (Unicode-Thema!), so das dies für mich Priorität hat. Linux (und Mac) kann ich eh selbst nicht testen.
Man könnte jetzt das Icon (ist ja nicht unbedingt nötig) entfernen, aber wo anfangen und wo aufhören?
Ihr seid doch prima selbst in der Lage, den Code für Linux lauffähig zu machen.

Mit Kernel-Gruß
Helle

[Kiffi]

Liebe Linux-Jünger, [...]

ok, ich finde es halt nur schade, dass die beiden "Inkompatibilitäten" in Deinem Code eigentlich gar nicht sein müssten.

Aber kein Thema. War halt nur ein Hinweis. Ist ja Dein Code. Kannst damit machen, was Du willst.

Grüße ... Peter

[NicTheQuick]

Da haut er die verrücktesten Assembler-Codes raus, aber ist zu faul für ein kleines CompilerIf.

[Helle]

Nic, Du weißt doch: Programmierer sind von Haus aus faule Hunde und Hobby-Programmierer (wie meiner einer) sind da keinen Deut besser !
@ccode_new: Ja, der Speicherbedarf ist bei der Butterfly-Methode enorm. Jede Faktoren-Dezimal-Ziffer (Byte) wird als DWord in Double konvertiert, dann 2x abgespeichert, wobei noch der Platz für den Imaginärteil reserviert wird, für jedes N ist Cos und Sin als Double zu berechnen und abzuspeichern...
N ist die nächsthöhere 2-er Potenz der Faktoren-Länge, beide Faktoren müssen auf gleiche Länge getrimmt werden... Das läppert sich zusammen !

Habe oben die Prozedur Calc() auf Speicher-Optimierung getrimmt, aber das macht den Kohl nicht fett.

Gruß
Helle