You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since addition mod 2 is xor, we can have multpile threads writing to the same FpVectorP<2> using AtomicU64::fetch_xor. This can be useful for parallelizing certain operations, such as acting on a FreeModule.
This will make the mod 2 situation substantially different from the odd prime situation though. Maybe wait till specialization...
The text was updated successfully, but these errors were encountered:
Are you suggesting we use AtomicU64s as limbs instead of u64s? We could always have something like AtomicFpVector and have it implement BaseVector, assuming #53.
The transmute fn(&mut [u64]) -> &mut [AtomicU64] is safe, but other functions will need Atomic support. I don't have concrete architectural ideas at the moment
I've done a bit of experiment and I think this is just a bad idea. Concurrent atomic writes still incur some synchronization cost, and just makes everything really slow.
Since addition mod 2 is xor, we can have multpile threads writing to the same
FpVectorP<2>
usingAtomicU64::fetch_xor
. This can be useful for parallelizing certain operations, such as acting on aFreeModule
.This will make the mod 2 situation substantially different from the odd prime situation though. Maybe wait till specialization...
The text was updated successfully, but these errors were encountered: