Stop using PtrArrays
#454
Draft
Stop using PtrArrays
#454
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #454 +/- ##
=======================================
Coverage 70.84% 70.84%
=======================================
Files 66 66
Lines 3807 3807
=======================================
Hits 2697 2697
Misses 1110 1110
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
Note that julia> using Polyester
julia> function foo!(x)
@batch for i in eachindex(x)
if i == 1
@show typeof(x)
end
x[i] = sin(i)
end
return sum(x)
end
foo! (generic function with 1 method)
julia> foo!(rand(5))
typeof(x) = StrideArraysCore.PtrArray{Float64, 1, (1,), Tuple{Int64}, Tuple{Nothing}, Tuple{Static.StaticInt{1}}} |
|
The current conclusion of #453 is that its an ARM Julia problem. |
|
So what do we do now? Ignore #453 and this PR because it's only relevant to macOS AMR? I'll try to find a MWE to report it at StrideArrays.jl, but I don't have time for this now. |
|
Yes I would ignore this for now. We should probably look at this again when 1.11 comes around in a month. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The main reason for this PR is the weird heisenbug in #453.
Threaded loops yield different results than non-threaded loops, even though each loop operation works on a different entry of
dv. This problem disappears when using plain JuliaArrays instead ofPtrArrays fordv.I haven't yet managed to reduce #453 to a MWE, so I can't report this in StrideArrays.jl, so I suggest we use plain Julia arrays instead (for now at least).
Also, with plain Julia arrays, we don't run into problems like JuliaSIMD/StrideArrays.jl#88.
Since the reason we used
PtrArrays in the first place is to avoid allocations, this PR is highly performance relevant.As expected, we have some more allocations:
main:
This PR:
Here are some benchmarks with the dam break 2D example:
Apple M2 Pro
1 thread main:
1 thread this PR:
6 threads main:
6 threads this PR:
So we do have a little more allocations, but the performance difference in full simulations is actually negligible.
I'd also like to hear @sloede's or @ranocha's feedback here, since
PtrArrays are also used in Trixi.Here are some full timer outputs:
Ryzen Threadripper 3990X
1 thread main:
1 thread this PR:
24 threads main:
24 threads this PR:
Apple M1 Pro
6 threads main:
6 threads this PR: