comparison Notes.md @ 1290:31d0b7638304 refactor/grids

More notes
author Jonatan Werpers <jonatan@werpers.com>
date Tue, 07 Mar 2023 09:21:27 +0100
parents 23f3b62388ba
children e352630a0309
comparison
equal deleted inserted replaced
1289:3b7ebd135918 1290:31d0b7638304
270 270
271 Vad tänker du kring detta ur ett interface-perspektiv? Jag hittade paketet https://github.com/JuliaArrays/StructArrays.jl som verkar erbjuda AoS-interface men SoA-minneslayout så det kanske kan vara något vi kan använda? Inte native-stödd på samma sätt som SVector, men verkar iaf utvecklas aktivt. 271 Vad tänker du kring detta ur ett interface-perspektiv? Jag hittade paketet https://github.com/JuliaArrays/StructArrays.jl som verkar erbjuda AoS-interface men SoA-minneslayout så det kanske kan vara något vi kan använda? Inte native-stödd på samma sätt som SVector, men verkar iaf utvecklas aktivt.
272 272
273 [Efter telefonsamtal] För optimal prestanda behöver vi antagligen se till att man kan räkna ut varje komponent i en punkt individuellt. Detta så att man har frihet att till exempel låta den innersta loopen hålla komponentindexet konstant för att underlätta intruktionsvektorisering. 273 [Efter telefonsamtal] För optimal prestanda behöver vi antagligen se till att man kan räkna ut varje komponent i en punkt individuellt. Detta så att man har frihet att till exempel låta den innersta loopen hålla komponentindexet konstant för att underlätta intruktionsvektorisering.
274 274
275
276 [Vidare tankar]
277 * Det borde bara vara output-gridfunktionen som behöver special-indexeras? Det viktiga på inputsidan är att den är lagrad på rätt sätt i minnet.
278 * Det borde inte vara några problem att behålla det "optimala" interfacet (gf[1,1,1][2]) till gridfunktionerna. Om man verkligen behöver kan skapa parallella indexeringsmetoder som gör det man behöver, i.e, "deep indexing".
279 * Det är inte säkert att vi behöver göra något speciellt på outputsidan överhuvudtaget. Det känns inte orimligt att kompilatorn skulle kunna optimera bort den koden som räknar ut onödiga komponenter.
280 * Om vi behöver special-indexering kommer till exempel LazyTensorApplication att behöva implementera det.
281 * För att komma vidare med något mer avancerat behöver vi antagligen implementera några operatorer som ger och agerar på vektorvärda funktioner. Tex grad, elastiska operatorn, andra?
282
283
275 ## Performance measuring 284 ## Performance measuring
276 We should be measuring performance early. How does our effective cpu and memory bandwidth utilization compare to peak performance? 285 We should be measuring performance early. How does our effective cpu and memory bandwidth utilization compare to peak performance?
277 286
278 We should make these test simple to run for any solver. 287 We should make these test simple to run for any solver.
279 288