Conversation
Adds a JIT backend for POWER8 and later Power ISA CPUs. Assembly instructions were restricted to those available in Power ISA v2.06 in order to facilitate adding support for POWER7, but currently only RandomX V1 is supported on those chips due to its lack of AES instructions. Support has been added for both little-endian and big-endian CPUs, but only little-endian has been tested. Fixes tevador#132
|
Benchmarks on a Raptor Computing Systems Talos II with dual POWER9 CPUs:
|
The vector permutation is unnecessary on little-endian systems when using `stvx`.
RandomX v1 also uses AES in the scratchpad hash/fill step, so you can use the existing soft AES code for RandomX v2 loop. It shouldn't be that hard compared to the full JIT implementation that you've done already. |
This only saves one or two instructions, but there are no drawbacks to how this optimization is implemented so there's no reason not to do it.
|
FYI, the ppc64le build is failing: https://github.com/tevador/RandomX/actions/runs/24008647458/job/70025217444 |
This only saves one or two instructions in a very cold path in the code, but there are no drawbacks to implementing this optimization so there's no reason not to do it.
This optimization can save one or two instructions for some immediates.
From the CI log:
We could also avoid the dependency entirely by Which option would you prefer? FWIW, in the future I plan to use more of those definitions (full list is here) to detect the system's ISA version in order to patch in more-optimized code for the newer architectures, so my personal preference is to just use the Linux kernel header so there's no possibility of copy/paste issues. That said, I'll understand completely if you want to avoid a dependency on kernel headers just for a handful of constant definitions (which AIUI should never change between kernel versions). |
We already query the CPU feature support in cpu.cpp, so there's no need to do it again.
This is the same split in Debian--the ppc64el port is only supported on POWER8 and later, so POWER7 and earlier can only run Debian ppc64 (big-endian 64-bit PowerPC). Because of this, we set the default little-endian architecture to POWER8. And since the RandomX JIT backend for PPC64 requires VSX, which is only supported by POWER7 and later, the lowest we can set the default big-endian architecture to is POWER7.
Most big-endian Power systems use V1 of the Power ELF ABI, so in order for this code to run on those systems we need to make a few changes. - We increase the size of the stacks by 80 bytes to avoid overwriting any of the information callers will write there. These larger stack frames are compatible with both ABI V1 and V2. - We add a macro to declare a C function with metadata that the linker is able to use when building for an ABI V1 system. - We generate function descriptors for JIT-generated functions, since pointers to functions in the V1 ABI actually point to function descriptors, not the functions themselves.
The Argon2 implementation writes to the cache in native endianness, so we need to read it in native endianness. And since nothing that reads the dataset cares about its byte order, we can keep that in native endianness as well despite the spec saying that it should be in little-endian byte order.
The scratchpad and register file must both be read from and written to in little-endian byte order.
We need to byte-swap 128-bit vectors for AES mixing on big-endian PPC64. Otherwise, the interpreter v2 hash tests will fail.
In ABI v1, register GPR2 is loaded by the caller from the function descriptor, so we don't need to emit instructions to load it ourselves.
|
Just a quick update on this: Big-endian PPC64 works now, but after doing more thorough testing on little-endian, it seems there's a very intermittent bug where the scratchpad pointer base address is getting added to |
This should make the code a little bit easier to reason about.
GCC's built-in cache clearing function didn't do anything on Power, so we use our own code, borrowed from LLVM and modified to detect the cache line size at runtime. Also, to avoid a huge hit to performance (~13%), rather than clearing the cache for the whole 128 KiB of constants and code, we clear the cache just for the bytes of the program that was just written, and we only do that cache clearing after the whole program has been written. And since the constants aren't used as instructions, we can skip clearing any caches for that data. So now instead of clearing caches for 128 KiB of memory, we're only doing that for about 4+ KiB of just the program memory. Total hit to performance from actually clearing the cache seems to be in the range of 0.2%-0.3%, which is more than acceptable considering the alternative results in wasted cycles and random crashes.
|
I fixed the segfaults and memory corruption bugs. Turns out the caches weren't being invalidated after writing the code, causing stale instructions to get executed from the cache and leading to intermittent, unpredictable results. But now the caches are being properly invalidated and the code is running reliably. |
3 participants
Adds a JIT backend for POWER8 and later Power ISA CPUs. Assembly instructions were restricted to those available in Power ISA v2.06 in order to facilitate adding support for POWER7, but currently only RandomX V1 is supported on those chips due to its lack of AES instructions.
Support has been added for both little-endian and big-endian CPUs, but only little-endian has been tested.
Fixes #132