ARM builds and SIMD-assembler prospects

[retina]

I actually find it easier to not bother with all the myriad of ID values and registers. Instead I just set an invalid instruction trap and start executing something from the set I want to use. If it traps then I drop back one level and try again. This covers both bases where either the OS or the CPU doesn't support the instructions.

[ewmayer]

Originally Posted by retina

I actually find it easier to not bother with all the myriad of ID values and registers. Instead I just set an invalid instruction trap and start executing something from the set I want to use. If it traps then I drop back one level and try again. This covers both bases where either the OS or the CPU doesn't support the instructions.

A similar thought had occurred to me when I couldn't find any CPUID-style mention in the ARM instruction manual, but time to get concrete about this. Is that something easily doable in C - e.g. using the functionality of signal.h to catch SIGILL - or does it need C++'s try/catch exception handling?

If you could post some sample code with your implementation, that would be great.

[retina]

Originally Posted by ewmayer

A similar thought had occurred to me when I couldn't find any CPUID-style mention in the ARM instruction manual, but time to get concrete about this. Is that something easily doable in C - e.g. using the functionality of signal.h to catch SIGILL - or does it need C++'s try/catch exception handling?

If you could post some sample code with your implementation, that would be great.

I don't use C/C++, or any HLL. It's all assembly. And I don't use Linux, or any commercial OS. So I'm not sure how much any code I have that could help you. But the try/catch thing (or its equivalent) would appear to be the easiest thing to use here. Pick a representative instruction and put it in the try block. Build up a pool of true/false flags.

[jasonp]

I don't think the exception-handling semantics in C++ are capable of dealing with unix style signals, which by their nature involve interrupt handling and a context switch to the OS. I suppose you could ignore the illegal instruction signal and then look to see if the instruction you are testing has had the intended effect on sample data, i.e. do a SIMD vector add and check that vector(1)+vector(1) == vector(2).

More mundane: what about parsing /proc/cpuinfo in linux? On x86 this parses the cpuid bits for you. Is there an ARM equivalent for that?

[retina]

Originally Posted by jasonp

I don't think the exception-handling semantics in C++ are capable of dealing with unix style signals, which by their nature involve interrupt handling and a context switch to the OS. I suppose you could ignore the illegal instruction signal and then look to see if the instruction you are testing has had the intended effect on sample data, i.e. do a SIMD vector add and check that vector(1)+vector(1) == vector(2).

I'm not sure how you could just ignore the illegal instruction trap. You would have to rewrite EIP/RIP properly to skip the faulting instruction, else you keep returning the the same instruction.

For my code I just lay it out like this (pseudo code):

//set all flags to zero
supports_FPU = 0
supports_CMOV = 0
//...
supports_AVX512F = 0

//test each instruction set
try {
	finit		//FPU instruction
	supports_FPU = 1
}
catch {
	//nothing to do here
}

try {
	cmoveq eax,eax	//CMOV instruction
	supports_CMOV = 1
}
catch {
	//nothing to do here
}

//...

try {
	vpabsq zmm1 {k1}, zmm2, zmm3	//AVX512 Foundation instruction
	supports_AVX512F = 1
}
catch {
	//nothing to do here
}

[jasonp]

Ignoring SIGILL presupposes that the processor triggers a synchronous exception that starts an exception handler, and when the user-defined portion of that handler does nothing then execution restarts at the instruction after the faulting one, whose address was saved by hardware and is accessible somewhere. At least that's how the embedded CPUs I'm familiar with would work.

I see there are some projects on github that use unix internals to trap things like segfaults and convert them into C++ exceptions; pretty slick.

[retina]

Ideally the try block will set the trap address to the start of the following catch block. So when it traps EIP/RIP is updated to point to the catch block and the flag never gets set to 1. The EIP/RIP rewrite has to be handled in the exception code. And for code like I have above it won't work if the code always returns to the following instruction because then the flag is always set regardless of whether or not the instruction was valid.

[ldesnogu]

Here is the output of cat /proc/cpuinfo on a 64-bit machine:

$ cat /proc/cpuinfo | grep Features | sort -u
Features    : fp asimd evtstrm

And here is code to check undefined instructions in C:

#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <signal.h>

static int got_sigill;

static void illegal_handler(int signum, siginfo_t *info, void *context)
{
  ucontext_t *uc = (ucontext_t *)context;

  printf("Got SIGILL\n");
  got_sigill = 1;
  uc->uc_mcontext.pc += 4; /* AArch64 instructions always are 4-byte long */
}

static int setup_illegal(void)
{
  struct sigaction act;

  memset(&act, 0, sizeof(act));
  act.sa_handler = illegal_handler;
  act.sa_flags = SA_SIGINFO;
  errno = 0;
  if (sigaction(SIGILL, &act, NULL) < 0) {
    perror("signaction");
    return 1;
  }

  return 0;
}

int main(void)
{
  int err;

  /* first setup the signal handler */
  err = setup_illegal();
  if (err) {
    return 1;
  }

  /* now check instruction */
  got_sigill = 0;
  asm(".inst 0x0");
  if (got_sigill) {
    printf("Instruction is undefined.\n");
  } else {
    printf("Instruction is not undefined.\n");
  }

  return 0;
}

[ldesnogu]

And here is how to use HW capabilities:

#include <stdio.h>
#include <sys/auxv.h>
#include <asm/hwcap.h>

static int has_asimd(void)
{
  unsigned long hwcaps = getauxval(AT_HWCAP);

  if (hwcaps & HWCAP_ASIMD) {
    return 1;
  }

  return 0;
}

int main(void)
{
  int asimd;

  asimd = has_asimd();
  if (asimd) {
    printf("AdvSIMD is supported.\n");
  } else {
    printf("AdvSIMD is NOT supported.\n");
  }

  return 0;
}

[ewmayer]

All odd-radix-DFT macros in place, thus we have full non-power-of-2 FFT capability. Timings look good, in the sense of nicely monotonic behavior, no significant anomalies related to the DFTs at the larger odd-prime lengths 11 and 13. I have been noticing a timing effect where I get as much as a 5-10% speedup for a given 100-iteration timing test (lasting 10-20 sec for FFT lengths in the 2-4Mdoubles range, using all 4 cores of my Odroid C2) when the CPU has been 'idle' (just OS background stuff running) for at least a few minutes. That indicates to me that thermal-based throttling is indeed occurring. As a near-term workaround will run any timings I post here with the top half of the plastic protective case removed; longer term will see about finding a small cooling fan and suitable power pinouts on the C2 board to run it from.

Laurent, many thanks for the sample code related to SIGILL - I will be looking at that over the next few days, in conjunction with some basic small-DFT macros I use for low-level SIMD correctness and timing tests - those are currently only used in a special #define-flag-enabled build mode, but I think I will enable them in all SIMD builds and wrap them in SIGILL checking.

[ewmayer]

Originally Posted by ewmayer

All odd-radix-DFT macros in place, thus we have full non-power-of-2 FFT capability. Timings look good, in the sense of nicely monotonic behavior, no significant anomalies related to the DFTs at the larger odd-prime lengths 11 and 13.

BTW, there is no fundamental reason why FFTs using these prime radices at the front end should perform worse than their smoother counterparts. Here's why: First off, the per-input-normalized opcounts for e.g. DFT-11 and 13 are unavoidably worse than their neighbors 10,12,14. On FMA hardware a simple implementation of a prime-length-N-DFT which uses a simple FMA-based pair of quadratic matrix-multiplies to do the (N-1)/2 x (N-1)/2 subconvolutions by sine and cosine parts of the complex roots needs precisely 5*(N-1) ADD and (N-1)^2 FMA, with 2*(N-1) of the FADD replaceable by the same number of FMA in the opening and closing (N-1)-butterflies if register availability is a problem, both variants having the same total opcount, (N+4)*(N-1). For example, such a basic approach to a 13-DFT, using the ADD-to-FMA replacement to ease register pressure, needs 36 ADD and 168 FMA, a total opcount comparable to the best-of-breed van Buskirk tangent-DFT for the same radix, with FMAs used to minimize the total opcount of the latter, as well. (The reason to prefer the simpler approach, if opcounts are comparable, is that it tends to have significantly better roundoff error properties than e.g. the tangent-DFT.)

Compare those ~200 arithmetic ops to the mere 96 needed for an optimized 12-DFT (four 3-DFTs needing 12 ops each followed by three 4-DFTs needing 16 ops each) and the 160 needed for an optimized 14-DFT (two 7-DFTs needing 66 ops each followed by seven 2-DFTs needing 4 ops each), radix-13 is clearly worse. But, since e.g. 11 and 13 are prime - and the same argument also applies to odd composites like 9 and 15 - they contain no power-of-2 components as do 12 and 14, meaning we use some index-permutation magic to twiddlelessly combine them with the ensuing larger-power-of-2 FFT pass sequence. For the 13-DFT, saving a full layer of complex twiddle MULs is equivalent to saving ~50 FMAs, so our effective opcount for 13-DFT drops to ~150 total arithmetic ops, which is roughly the same ops-per-input as the 14-DFT and only slightly more than the very factorization-smooth 12-DFT, when one places things in the context of doing a large-length FFT with said DFTs being accompanied by multiple power-of-2 passes which do the bulk of the overall work.