Mercurial > repos > public > sbplib_julia
comparison Notes.md @ 1286:23f3b62388ba refactor/grids
Add some notes about grid functions:
| author | Jonatan Werpers <jonatan@werpers.com> |
|---|---|
| date | Fri, 03 Mar 2023 15:40:04 +0100 |
| parents | 79647b60a73b |
| children | 31d0b7638304 |
comparison
equal
deleted
inserted
replaced
| 1285:7d52c4835d15 | 1286:23f3b62388ba |
|---|---|
| 259 component(gf,2,3) # (2,3) elementet av en matris | 259 component(gf,2,3) # (2,3) elementet av en matris |
| 260 component(gf,:,2) # Andra kolumnen av en matris | 260 component(gf,:,2) # Andra kolumnen av en matris |
| 261 @ourview gf[:,:][2] | 261 @ourview gf[:,:][2] |
| 262 ``` | 262 ``` |
| 263 | 263 |
| 264 ### Prestanda-aspekter | |
| 265 [Vidar, Discord, 2023-03-03] | |
| 266 Typiskt sett finns det två sätt att representera vektorvärda gridfunktioner AbstractArray{T,Dim} där T är en vektor över komponenterna. Man skulle alltså i 1D ha | |
| 267 u = [ [u1[x1], u2[x1]] , [u1[x2], u2[x2]], ... [u1[xN], u2[xN]]]. Detta brukar kallas array of structs (AoS). Alternativet är struct of arrays (SoA), där man har alla gridpunkter för en given komponent u = [[u1[x1], u1[x2]],... u1[xN]], [u2[x1], u2[x2], ... u2[xN]]]. | |
| 268 | |
| 269 Personligen tycker jag att AoS känns som den mer naturliga representationen? Det skulle göra det enklarare att parallelisera en vektorvärd gridfunktion över gridpunkterna, och om man opererar på olika komponenter i samma funktion så är det också bra ur en minnesaccess-synpunkt då dessa kommer ligga nära vandra i minnet. Problemet är att AoS sabbar vektorisering på CPU då två gridpunkter i en komponent ligger långt bort från varandra. Efter lite eftersökningar (och efter att snackat lite med Ossian) så verkar det ändå som att AoS är dåligt på GPU, där man vill att trådar typiskt sett utföra samma operation på närliggande minne. | |
| 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. | |
| 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. | |
| 274 | |
| 264 ## Performance measuring | 275 ## Performance measuring |
| 265 We should be measuring performance early. How does our effective cpu and memory bandwidth utilization compare to peak performance? | 276 We should be measuring performance early. How does our effective cpu and memory bandwidth utilization compare to peak performance? |
| 266 | 277 |
| 267 We should make these test simple to run for any solver. | 278 We should make these test simple to run for any solver. |
| 268 | 279 |