mae schrieb:
Compiler fuehren selten SIMD-Befehle aus (beim Initialisieren von Speicherbereichen vielleicht), und wenn sie stattdessen skalare Befehle ausfuehren wuerden, waeren sie kaum langsamer.
Um deine Methode zu replizieren, ohne tiefere Analyse (das ist mir zu viel Arbeit):
Code:
objdump -d /lib/libLLVM.so.20.1 | grep xmm | grep $'\tp' | grep -v pxor | wc -l
31032
objdump -d /lib/libLLVM.so.20.1 | grep ymm | grep $'\tv' | grep -v vpxor | wc -l
1975
Also LLVM mit einem X86_64_v2 Target (Manjaro Repos), verzweigt auf AVX2, und AVX512. Mir ist das zu viel Aufwand für "bringt wenig". Wobei ich da genauso einschränken muss, dass ich nicht genauer nachgeschaut habe wann der Code zum Einsatz kommt.
mae schrieb:
Da kommen oft Spezialbefehle zum Zug, zumindest fuer beliebte Methoden wie AES. Hat RVA23 solche Befehle? Wenn nicht: die S-Box von AES bildet sich nicht gut auf SIMD-Befehle ab.
Ja, wobei selbst bei der Standardisierung der Risc-V Profile der Wille klar formuliert wurde, von skalarer Beschleunigung von Kryptografie auf Vektorisierte umzuschwenken um den Durchsatz zu verbessern.
https://drive.google.com/file/d/12QKRm92cLcEk8-5J9NI91m0fAQOxqNAq/view ; Seite 5 schrieb:
The scalar crypto extensions Zkn and Zks that were options in RVA22 are not options in
RVA23. The goal is for both hardware and software vendors to move to use vector crypto,
as vectors are now mandatory and vector crypto is substantially faster than scalar crypto.
Zudem ist es allein mit der Beschleunigung von AES Algorithmuses auch nicht getan. Es kommt der Block Cipher (mode) dazu. Da kommt es stark darauf an, wie das Ganze implementiert ist. In der x86-Welt ist es aber kein Teil von AES-Ni und wird über Software geregelt. Bei RISC-V kommt es bisschen auf den Modus an, GCM/GMAC ist über Zvkg realisiert, andere Modi müssten aber auch wieder in Software erledigt werden. Zvkned ist dann grob die Entsprechung von AES-Ni.
Aber aus welchen Gründen auch immer, sind die Erweiterungen optinal :/
Zvkg; Zvkned sind auf Seite 503..504 der aktuellen ISA Dokumentation (unprivileged) zu finden.
https://drive.google.com/file/d/1uviu1nH-tScFfgrovvFCrj7Omv8tFtkp/view
mae schrieb:
Kaum SIMD, ausser fuer das uebliche: Schreiben und Kopieren von groesseren Speicherbereichen.
Kann man leider nicht testen, da alle AMD64-Prozessoren SSE2 haben und alle ARM-Prozessoren, auf denen solche Sachen laufen, Neon. Und die verwenden sie auch fuer skalare FP-Befehle (und das ist die haeufigste Nutzung von SSE2 und Neon). Aber schauen wir's uns ein Beispiel einmal naeher an: zstd, ein Kompressions/Dekompressionswerkzeug.
Also ungefaehr 0.2% der Befehle. Kann natuerlich sein, dass die in einem heissen Kernel verwendet werden, aber um das noch zu recherchieren, habe ich im Moment keine Zeit.
Testen lässt sich sowas grundlegend ja schon auf den entsprechenden Prozessoren, einfach Software ohne Erweiterungen bauen. Wenn man befürchten muss, dass der Code intern auf Code verzweigt und Compilerflags nicht reichen, kann man ne KVM aufmachen und da Features beschränken. Bei Zstd scheint mit das nicht der Fall, entsprechend habe ich es mit
make zstd CC=gcc CFLAGS="-O2 -march=x86-64 -mno-sse" probiert. Was jedoch fehlschlägt, da schon benchfn.c zwingend SSE2 braucht.
Code:
benchfn.c: In function ‘BMK_extract_runTime’:
benchfn.c:71:15: error: SSE register return with SSE disabled
71 | BMK_runTime_t BMK_extract_runTime(BMK_runOutcome_t outcome)
| ^~~~~~~~~~~~~~~~~~~
make[2]: *** [Makefile:329: obj/conf_05b61b52cf7a6eaa44804ce8ab5d4cae/benchfn.o] Error 1
make[1]: *** [Makefile:149: zstd] Error 2
make[1]: Leaving directory '/home/gom/temp/zstd/programs'
make: *** [Makefile:67: zstd] Error 2
Was aber keine Implikation hat, ob es für die Performance relevant ist. Es besagt nur, dass ich es so nicht gebaut bekommt :/
Offenbar gehen die Argumente zur Sache aus.
Das war eine Überzeichnung dessen, dass da ein Argument darauf basierte, was Stand der Technik 1996 war und auch irgendwie ging. Was 1996 als Desktop ging, hat halt nicht viel Relevanz dreißig Jahre später, ebenso wie der Alltag der frühen Steinzeit.
.
.
