You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, first of all, thanks for the beautiful package. Over at Oceananigans.jl and ClimaOcean.jl, we use offset arrays to store the underlying data of our Field types. However, now that we are increasing the complexity of the model, we are having increasingly frequent problems with GPU parameter space when launching kernels that require many offset array inputs.
We think that this has to do with the fact that offsets are Int64 types, which consume quite a lot of parameter space, however, we typically need offsets in the range of -10 .. 10, so Int8 would be enough for our scope.
However, it looks like the Int type is hardcoded in the OffsetArray type.
Hello, first of all, thanks for the beautiful package. Over at Oceananigans.jl and ClimaOcean.jl, we use offset arrays to store the underlying data of our Field types. However, now that we are increasing the complexity of the model, we are having increasingly frequent problems with GPU parameter space when launching kernels that require many offset array inputs.
We think that this has to do with the fact that offsets are
Int64
types, which consume quite a lot of parameter space, however, we typically need offsets in the range of-10 .. 10
, soInt8
would be enough for our scope.However, it looks like the
Int
type is hardcoded in theOffsetArray
type.OffsetArrays.jl/src/OffsetArrays.jl
Line 114 in 5972e9e
Is there a specific reason for having offsets as
Int64
s or would it be possible to allow flexibility in the sizes of the offsets?In the latter case, could I attempt a PR allowing lower-sized offsets?
cc @glwagner
The text was updated successfully, but these errors were encountered: