Mercurial > repos > public > sbplib_julia
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 |