Hallo Zusammen!
Langeweile am Sonntag? Kein Bock auf Tatort? Gut...
Bevor ich mein Github-Projekt update, möchte ich noch ein paar Tests
machen. Leider habe ich nicht die Hütte voller PCs stehen. Gesucht
werden Rechner mit Windows 64-Bit (Windows 7 und höher) mit CPUs vom
Athlon64 bis zur aktuellen Supertrooper-CPU. Der Test dauert nur ein
paar Sekunden und sieht wie im Bildchen aus. Getestet werden die
verschiedenen Instructions-Sets (also SSE2 bis AVX512F+VL+BW) in einer
DLL für QIRX (SDR). Die 256-bit Intrinsics funktionieren, aber den schon
herausgezogenen ASM-Code kann ich nicht testen. Normalerweise müsste der
funktionieren, aber Faselfehler kann ich nicht ausschließen. Das
Testprogramm muß dort jedenfalls auch
BER 485/3072000 ( 0.000158) FER 111/1000 ( 0.111)
anzeigen (wie bei der Referenz-DLL), sonst ist was kapööött.
Im Zip sind die Templates der DLL und des 0815-Testprogis für VS2022
drin, falls jemand selbst Hand anlegen und kompilieren möchte (vorher
den clang-Compiler installieren). Im "bin" Verzeichnis sind die DLLs und
das Testprogramm schon drin. Bitte vor dem Testen die CPU auf eine
Frequenz "festnageln" ("Energieoptionen" oder externes Tool). Die CPU
muß nicht mit 100% rennen - Hauptsache stabil. Firefox während des Tests
starten, Filme gucken etc. ist out. ;) Eventuell auch den Turbomode
(oder wie das heißt) im BIOS deaktivieren. Sonst tourt die CPU eventuell
schon gegen Ende des Tests leicht ab. Wer selbst kompiliert, bitte
"Ref_asm" benutzen - der Compilercode hat keine Chance. Notfalls den
Punkt "DIY" in der Textdatei konsultieren.
Ich würde mich freuen , wenn Ihr eure Ergebnisse (es geht nur um die
Prozente gegenüber der Referenz-DLL, nicht um die eigentliche
Geschwindigkeit) hier reinstellt. Bitte noch den CPU-Namen hinschreiben,
also meinetwegen Ivybridge, Zen3 etc., denn ich habe die CPUIDs auch
nicht im Kopf. ;)
Wer den ASM-Code schneller bekommt - bitte gern! Bei AVX2 und AVX512
sind zwei Procs drin, jeweils eine auskommentiert. Laut uops.info nehmen
die sich nicht viel, aber wer weiß?
TIA Heiko
ZIP SHA1: 4d69143bd4dd97fa553d2e6f800f9dc4b83e09eb
Angehängte Dateien:
-
Clipboard01.png
88 KB -
Clipboard02.png
100 KB
:
Verschoben durch Moderator
unter Windows 10 Edu 64bit
Danke Lukas! Das sieht bald danach aus, als ob bei AVX2 im ersten Durchgang die 256-Bit Stages noch nicht komplett aufgewacht sind. Da ist wohl die warm-up Schleife etwas zu kurz. Im Idealfall sollten die Zeiten skalieren und in der ersten Zeile (32 KBit) müßten etwa 0,085s stehen. Kannst ja, wenn Du Lust und Laune hast, die beiden Schleifen im Testprogi abändern, also die Division rausnehmen. for (tr = 0; tr < TESTLOOPS / 4; tr++) // warm up Die Zeiten sehen allgemein etwas "unruhig" aus, die Referenz wird langsamer. Daß SSSE3 und SSE4.1 so schlecht abschneiden, wundert mich etwas. Liegt vielleicht an der höheren Speicherbandbreite der CPU. Aber Danke erstmal!
@Clemens: Aha, Du hattest deinen IVB-Rechner mit etwas über 3 GHz laufen. Da war wohl der "TurboBoost" (3.1 GHz) angesprungen. Ansonsten sehen die Werte so ähnlich wie in "lap1_bench.txt" (im Zip) aus. Das war ein (gedrosselter) "i5 3340M" mit max. 2.7 GHz (Win10 Pro, 8GB DDR3 800MHz ein Riegel). Die andere Datei stammt von einem i5-520M (Win7 Pro). @Jörg: Sieht auch gut aus. Wenn AVX2 35++ Prozent bringt, dann hat sich das Ganze doch schon gelohnt. Danke für euer Feedback. Kein AMD'ler hier? BTW: Wer vergibt hier eigentlich Negativpunkte? Mir ist das ja egal, aber so viel Langeweile kann man doch gar nicht haben.
@Mario: Vielen Dank für deinen heldenhaften Einsatz für die AMD-User! ;) Auf deinem Rechner scheint aber ganz schön was los zu sein. So wie die Zeiten aussehen, tourt die CPU hoch und runter. Der Test ist so leider nicht vergleichbar. Wie schon geschrieben, sollte die CPU mit konstanter Core-Frequenz (fester Multiplikator) laufen. Im Idealfall (!) sollten dann die gemessenen Zeiten mit steigender Bitrate proportional ansteigen: Testing function "deconvolve" from viterbi_qirx.dll with 10000 calls... BER 485/3072000 ( 0.000158) FER 111/1000 ( 0.111) Bitrate: 32 Framebits: 768 Time: 0.1000 sec Bitrate: 64 Framebits: 1536 Time: 0.2000 sec Bitrate: 96 Framebits: 2304 Time: 0.3000 sec Bitrate: 128 Framebits: 3072 Time: 0.4000 sec Das klappt natürlich nicht 100%ig, aber auf einem Rechner sollte das wenigstens grob (mit ein paar Prozent Abweichung) funktionieren und ein Trend erkennbar sein. "Klemm" die CPU doch bitte mal über die "Energieoptionen" im Win10-Pro auf meinetwegen 80% fest (siehe Bildchen ganz oben) und teste dann nochmal. Liebe Grüße Heiko
Heiko schrieb: > BTW: Wer vergibt hier eigentlich Negativpunkte? Das ist nur die Bestätigung, das dein Beitrag gelesen wurde, eine neuartige Forumsautomatik. Windows 10 Pro 64-Bit, Intel XEON 5690 @ 3,47GHz. Edit: Oh, sorry, habe das mit dem Dateinamen nicht mitgekriegt.
:
Bearbeitet durch User
Holla, die Waldfee: Matthias fährt mit einer 1600$ Server-CPU. Aber schön, wie die Zeiten skalieren. Fast wie mit dem Lineal gezogen! ;) So wie das mittlerweile aussieht, werde ich SSE4.1 rausnehmen. Diese Version ist zu langsam gegenüber SSSE3 und war ja nur wegen dem praktischen PMULLD Befehl drin. CPUs mit SSE4.1 können (hoffentlich) auch SSSE3 und sind damit gut bedient. Beim RYZEN vom Christopher sieht man sehr schön, wie die CPU hochtaktet. Pi mal Daumen sind das etwa 200ms, bis die CPU aus der Hüfte gekommen ist. Dagegen hilft dann wohl nur, die TRAILS im Testprogi von 1000 auf 10000 zu setzen. Das sollte reichen. Warum AVX2 so "moderat" (+16% am Ende) ausfällt, keine Ahnung. Wenn das nicht eine modere CPU wäre, würde ich jetzt sagen, daß die CPU die 256-Bit Befehle intern mit 2x128 Bit verarbeitet. Das gab es ja früher und ist ja auch heute noch so, während die CPU ihre 256-Bit Stages anwirft. Agner Fog spricht von über 50000 Takten, bevor die CPU richtig losrennt. Der i7-4790 vom Jörg kommt am Ende auf +36%. Alles etwas komisch. Matthias, ich hab dich mal up-gevotet. Nicht, daß Du dich wunderst. :D
Windows 10 AMD Ryzen 7 4800H P.S. Unschön an der Datei-Umlenkung über doit.bat: Man sieht die Ausgabe "Press a key" nicht und wartet und wartet... Die Ausgabe dieser Meldung über stderr statt stdout würde die Meldung im Eingabeaufforderungs-Fenster trotz Umlenkung sichtbar machen.
:
Bearbeitet durch Moderator
Heiko schrieb: > Matthias fährt mit einer 1600$ Server-CPU Man gönnt sich ja sonst nichts. Nee, Ernst beiseite, das ist ein alter HD-Video-Schnittplatz.
Ich habe es auch mal ausprobiert, unter VirtualBox 7.0.10 r158379 (Qt5.15.2) auf einem Macbook Pro - MacBook Pro Retina 15 - 2,2 GHz Quad-Core Intel Core i7 - 16 GB 1600 MHz DDR3 - Intel Iris Pro 1536 MB VBox hat 8GB Ram und es läuft Windows 10. Was mir auffiehl: a) Bei mir fehlt der Header in der Bench-Datei mit den Systemangaben b) am Ende die Aufforderung "press key" reagiert nur auf Enter, keine andere Taste
Kann das Programm nicht ausprobieren, vcruntime140.dll fehlt. Nachinstalliert wird nicht, brauche ich ja sonst auch nicht.
Angehängte Dateien:
-
Clipboard01.png
100 KB
Sodele, ich habe SSE41 rausgenommen und dafür die Standard-SSE2 Version vom Compiler eingefügt. Die ist jetzt Referenz. Dann das Bench-Progi geändert: - Der "schöne" Prozessorname kommt jetzt aus der Registry (wenn der Aufruf nicht fehlschlägt). Spart man sich das heraussuchen. - Laufzeit verlängert, damit die CPUs hochtouren - "Press a key" über stderr Ich hoffe, die Zeiten werden jetzt stabiler. Wer mag, kann nochmal testen. Frank E. schrieb: > a) Bei mir fehlt der Header in der Bench-Datei mit den Systemangaben Da fehlen auch die Ausgaben der Referenz-DLL und von der SSE2-Version. Komisch. Ansonsten macht das Ding ganz schön "Ballet". ;) Jetzt schau ich mir erstmal die Texte an.
Bitte schön 12th Gen Intel(R) Core(TM) i9-12900HK 2.50 GHz Windows 11 Pro 64-Bit-Betriebssystem, x64-basierter Prozessor Gruß Frank
Frank E. schrieb: > am Ende die Aufforderung "press key" reagiert nur auf Enter, keine > andere Taste Das liegt daran, dass das verwendete getchar() aus stdio bis zur Eingabebestätigung (RETURN oder ENTER) puffert. Die Meldung "Press Enter" wäre daher hier sinnvoller.
Wir sind hier ganz schön "Frank-reich". ;) Es ist schon erstaunlich, wie der Ryzen 4800H von Frank M. den 128-Bit Code "wegknallt". Der Sprung bei AVX2 ist dann nicht mehr ganz so groß. Der i9-12900HK von Frank L. lässt es gemütlicher angehen. Beide treffen sich dann beim AVX2-Code, der bei beiden praktisch gleich schnell läuft (1,5% Unterschied). Ob beide mit der gleichen Geschwindigkeit liefen, können wir ja noch rauskriegen. Schade, daß der 12th Gen. "Alder-Lake" kastriert ist und kein AVX512 mehr unterstützt. Aber vielleicht kommt ja noch jemand mit solch einem Geschoß vorbei. Euch allen erstmal vielen Dank fürs testen.
Win 10 Pro, i5 10600k, 4,1GHz Basistakt
Ungefragt stell ich hier mal meine Linux Benchmarks rein. Direkt mit Wine gemessen. Ich hab keine gesonderten Aufwand betrieben, was Frequenzen oder so angeht.
Windows 10, Intel i9-13900K
Anbei mal der Test mit meinem i7 960 auf Win 7 x64
Heiko schrieb: > Ob beide mit der gleichen Geschwindigkeit liefen, können wir ja noch > rauskriegen. Der AMD Ryzen 4800H lief dabei mit 2900 MHz, also ohne "Turbo-Boost".
Angehängte Dateien:
-
comp_vs_asm.png
91 KB
Roland E. schrieb: > Anbei mal der Test mit meinem i7 960 auf Win 7 x64 Hallo Roland! Kann es sein, daß Du die DLL selbst kompiliert und dabei die "Ref_cpp" Konfiguration genommen hast? So sieht es für mich auf den ersten Blick aus. Ich kann das jetzt aber nicht mit meinem alten i5-520M (SSE42) Lappi ausprobieren. Mach ich dann am Abend. Die aktuelleren CPUs ziehen 128-Bit Code knallhart durch, egal ob SSE2, SSSE3 oder AVX. Darum gab es dabei oben oft nur marginale Unterschiede zu sehen. Aber bei einer CPU von 2009? Auf Ivy-Bridge komme ich mit dem Compiler-Code (/o2 - volle Pulle bitte) auch nur auf rund +8% bei SSE2-LUT und SSSE3 gegenüber der Standard-SSE2 Version. Mit der "Ref_asm" Konfiguration sind es dann rund +16%. Siehe Bildchen.
Heiko schrieb: > Roland E. schrieb: >> Anbei mal der Test mit meinem i7 960 auf Win 7 x64 > > Hallo Roland! Kann es sein, daß Du die DLL selbst kompiliert und dabei > die "Ref_cpp" Konfiguration genommen hast? ... Nein. Einfach das bin aus dem ZIP über die enthaltene batch. PS: Das ist einer für den 'großen' Sockel mit 3 RAM-Bänken. Der gehört wimre zur xeon-Familie. Falls das einen Unterschied macht. Chipsatz ist ein X58.
:
Bearbeitet durch User
Roland E. schrieb: > PS: Das ist einer für den 'großen' Sockel mit 3 RAM-Bänken. Der gehört > wimre zur xeon-Familie. Falls das einen Unterschied macht. Chipsatz ist > ein X58. Das ist das gleiche wie bei meiner Maschine, nur das meine mal auf den Xeon 5690 aufgebohrt wurde. Auch hier sinds 6 RAM Sockel und der X58 Express Chipsatz im praktischen HP Z400 Gehäuse :-)
Matthias S. schrieb: > Roland E. schrieb: >> PS: Das ist einer für den 'großen' Sockel mit 3 RAM-Bänken. Der gehört >> wimre zur xeon-Familie. Falls das einen Unterschied macht. Chipsatz ist >> ein X58. > > Das ist das gleiche wie bei meiner Maschine, nur das meine mal auf den > Xeon 5690 aufgebohrt wurde. Auch hier sinds 6 RAM Sockel und der X58 > Express Chipsatz im praktischen HP Z400 Gehäuse :-) Hat hier ein Chieftec Mesh Tower. Der Knecht rechnet hier seit knapp 11 Jahren tapfer vor sich hin. War halt der letzte, der noch IDE, PCI und Firewire onBoard hatte. PCI war damals ne BT848 drin, und am IDE hängt heute noch ein SW-9576S. Für Sata habe ich keine RAM-Cartridge-Laufwerke mehr gefunden. Ab und an taucht der größte kern auf, der hier passen würde, aber deutlich über Neupreis X-D. Ist mir zu billig für 400MHz mehr...
Ein Durchgang mit Wine, Fedora36, i7 NB und einer mit i3 W8 NB. Bei Wine musste ich die Ausgabe aus der Konsole kopieren, die Ausgabe war in etwa doppelt so lang, als sie sein sollte. Also viel Platz hinter "Taste drücken". Taste drücken ging aber nicht, sondern nur Enter. Nicht ganz klar ist, ob die Formatierung zurückkommt. Notepad macht da nicht mit.
:
Bearbeitet durch User
..äh, ja, die Formatierung oben bei dem Wine-Text kommt zurück :)
:
Bearbeitet durch User
Heiko schrieb: > @Mario: Vielen Dank für deinen heldenhaften Einsatz für die AMD-User! ;) > > Auf deinem Rechner scheint aber ganz schön was los zu sein. So wie die > Zeiten aussehen, tourt die CPU hoch und runter. Der Test ist so leider > nicht vergleichbar. Hier noch mal der neue Test auf dem selben PC mit frisch installiertem/geupdatetem Windows 11 Pro.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.