Transform FD broadcast objs to use MArrays - #1763
Conversation
7e9b0be to
3b779dd
Compare
6ca3a39 to
24b5398
Compare
|
To recap on why this stalled: transforming the broadcasted object into an MArray-backed data structure forces reads of all field variables in the broadcasted object. That means that, even if a variable is not used in the broadcast expression, it still incurs a read, which will tank performance. If there was some way that we could determine which fields are read, and only transform those variables, then this would be feasible, but I'm not sure if that's possible. |
|
Superseded by #2184. |
|
Actually, I think this is may be very useful when it's likely that we'll use all variables in the input field (basically when all expressions are fused). We don't want to replace the existing behavior, but we could define a new operator that uses this behavior. At some point I'd like to revive this. |
|
This is basically superseded by |
Similar to #1735, this PR transforms our broadcast expressions by replacing array-backed DataLayouts to MArray-backed DataLayouts in each column of the stencil kernels.
The main benefit here is that this will result in at most 1 heap memory read for whatever fields we transform. One downside is that those reads become unconditional. I'll update #1746 with more details on these trade-offs, and what design choices we can make to ensure that we only see performance gains without regressions.
Closes #1746.