Allocate the per-cell material law parameters from an arena - #5288
Draft
hnil wants to merge 1 commit into
Draft
Conversation
EclMultiplexerMaterialParams::setApproach() allocates the nested parameter object with a bare new, so a grid costs one allocation and one shared_ptr control block per cell. On Norne that is 44927 allocations of 304 B spread over 105.7 MB of address space for 13.7 MB of data. Add makeArena()/arenaSlot() and a setApproach() overload taking externally owned storage, and have the manager hand out aliasing pointers into one vector per parameter array. The aliasing constructor shares the arena's single control block, so the per-cell overhead drops to the pointer itself and the objects land at a fixed 304 B stride. This is not a measured speedup: on Norne the relperm+pc evaluation loop is unchanged in cell order (91.5 -> 91.3 ns/cell, best of 5 alternating runs) and at best 2-3% in shuffled order, which is inside the noise. The allocator already hands out long contiguous runs when the objects are built back to back. What changes is the allocation count and the address span. All 228 opm-common tests pass.
hnil
added
the
manual:enhancement
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Each cell's nested material-law parameter object is a separate
newbehind its ownshared_ptrcontrol block. On Norne that is 44927 allocations of 304 B spread over 105.7 MB of address space for 13.7 MB of data. This addsmakeArena()/arenaSlot()and asetApproach()overload taking externally owned storage, so the manager hands out aliasing pointers into one vector per parameter array — one allocation, one control block, fixed 304 B stride.Draft because it is not a measured speedup. Norne relperm+pc, best of 5 alternating runs: 91.5 → 91.3 ns/cell in cell order, 112.4 → 111.7 shuffled. The allocator already returns long contiguous runs when the objects are built back to back, so only the allocation count and the address span change. Posting it because the layout is a precondition for anything that wants these objects as an array (SoA/GPU), not because it makes Norne faster today.
What does move the number on Norne is the size of these objects: padding them from 304 B to 1440 B — the size they reach once
EHYSTRis active — costs +45 ns/cell in the same loop. That suggests splitting the Killough/WAG scalars out ofEclHysteresisTwoPhaseLawParamsis the change worth making; happy to drop this one if you would rather see only that.All 228 opm-common tests pass.