• Reported by. TJN

• (Single threading case) When using purely OpenSHMEM setup, we currently
  get warnings about the lack of OpenMP in some cases. This can generally
  be ignored when not using OpenMP, but guards should be added to avoid
  these warnings in the future. For example:

    warning: ignoring #pragma omp parallel [-Wunknown-pragmas]                
      #pragma omp parallel for 
  

The multithreaded GUPS benchmark calls shmem_init and should instead call shmem_init_thread with a request for SHMEM_THREAD_MULTIPLE.

Reported by Keith Underwood on the openshmem mailing list

I decided to take a look at the GUPs implementation (really HPCCRandomAccess). I don’t think this implementation captures the spirit of the benchmark. While I’m not sure that some of the historical “optimizations” of the benchmark capture its spirit either, my first reading of this makes it look highly serialized. This inner sequence in particular seems troubling:

  remote_val  = shmem_longlong_g( &HPCC_Table[*ran & (LocalTableSize-1)],remote_proc);

  remote_val ^= *ran;

  shmem_longlong_p(&HPCC_Table[*ran & (LocalTableSize-1)],remote_val, remote_proc);

  shmem_quiet();

It would seem like you should replace the first 3 lines of that with a shmem_uint64_atomic_xor(). Then, the shmem_quiet() should only be called once every so often (HPCCRandomAccess chose 1024 as the “every so often”).

Link: https://github.com/ornl-languages/osb/blob/1.0.0-beta/GUPs/SHMEMRandomAccess.c

Important code starts at line 232.

-Keith