BeamOptics: Generalize SIMD Logic in AMReX#1289
Conversation
ax3l
changed the title
ax3l
changed the title
BeamOptics: Generalize SIMD Logic in AMReX
ax3l
force-pushed
the
topic-generalize-simd-amrex
branch
from
23082d8 to
cbfb21b
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
ax3l
force-pushed
the
topic-generalize-simd-amrex
branch
from
cbfb21b to
0956fc6
Compare
ax3l
force-pushed
the
development
branch
2 times, most recently
from
9a1e4af to
fa61eba
Compare
ax3l
force-pushed
the
topic-generalize-simd-amrex
branch
from
0956fc6 to
d577c40
Compare
ax3l
force-pushed
the
topic-generalize-simd-amrex
branch
3 times, most recently
from
a1ade1e to
43311b1
Compare
ax3l
force-pushed
the
topic-generalize-simd-amrex
branch
from
43311b1 to
86ae08a
Compare
|
@WeiqunZhang @EZoni this is ready now :) |
| store_1d<P_Method, 0>(x, m_part_x, i); | ||
| store_1d<P_Method, 1>(y, m_part_y, i); | ||
| store_1d<P_Method, 2>(t, m_part_t, i); | ||
| store_1d<P_Method, 3>(px, m_part_px, i); | ||
| store_1d<P_Method, 4>(py, m_part_py, i); | ||
| store_1d<P_Method, 5>(pt, m_part_pt, i); | ||
| store_1d<P_Method, 6>(sx, m_part_sx, i); | ||
| store_1d<P_Method, 7>(sy, m_part_sy, i); | ||
| store_1d<P_Method, 8>(sz, m_part_sz, i); | ||
| store_1d<P_Method, 9>(idcpu, m_part_idcpu, i); |
There was a problem hiding this comment.
These store_1d calls are not guarded anymore by
if constexpr (amrex::simd::is_vectorized<T_Element>)
while the store_1d calls below (lines 241-247) kept that guard (line 233).
Is this intentional and, if so, what's the reason for the asymmetry?
There was a problem hiding this comment.
I added a special constexpr check in store_1d in AMReX
// SIMD uses special vector register types in ValType that need to be copied back to RAM array type T
if constexpr (!std::is_same_v<ValType, T>) {that serves the same purpose as the "is this a vectorized type" check we had before.
https://github.com/AMReX-Codes/amrex/pull/4924/changes
I should remove the guard below as well and just forgot (it does not hurt, but it is verbose).
There was a problem hiding this comment.
Ah but here is the catch:
Scalar-only elements like ExactCFbend have a concrete non-template particle operator() that we need to guard the constexpr decltype(auto) P_Method = ... from.
The spin path does not hit that issue because it uses spin_and_phasespace_push, and currently all the spin-capable elements implement that as a templated method.
Co-authored-by: Axel Huebl <axel.huebl@plasma.ninja>
3 participants
Follow-up to #1279 , but now relying on AMReX constructs of 26.02+ in AMReX-Codes/amrex#4924