Carl Pearson

If I replace the `std::lock_guard` with a relaxed thread fence, it causes the regression (performs like 4.4) ```c++ class RelaxedFenceLock { public: void lock() noexcept { __atomic_thread_fence(__ATOMIC_RELAXED); } void unlock()...

After all this: best guess, two things going on: First, this hot line in the reproducer ```c++ tmp += _leftInput(cl, pt, j, i) * _rightInput(cl, bf, pt, j); ``` Is...

replacing std::lock_guard with these also causes the regression: ```c++ class KokkosAtomicLock { int lock_var; public: KokkosAtomicLock() : lock_var(0) {} void lock() { Kokkos::atomic_increment(&lock_var); } void unlock() { Kokkos::atomic_decrement(&lock_var); } };...

I believe testing is blocked by https://github.com/kokkos/kokkos-kernels/pull/2387

@ndellingwood can you give me a bit more about how to reproduce this?

I can't really figure this out. Even if I build this thing entirely internally to Kokkos Kernels, my understanding is that TriBITS feels entitled to dig around in our directories...

Closed in favor of #2416

We don't test that either, nor is that a pattern used in Trilinos after a cursory search. We do test constructing a pool and assigning that pool to a default-constructed...

I think the allocation size of 15^8 is too large for the CI environments.

If the default constructed pool is not actually useful, maybe we shouldn't allow that either