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
Julia 1.11 introduced Core.Memory and made Array a purely Julia type, which is nice for different optimization reasons. The interesting part for us is that GenericMemory has a parameter for kind and another for addrspace, which could potentially be exploited by us to store the memory managed by XLA.
This means that ConcreteRArrays could be managed by a simple Array instead, with the address space managed by Reactant.
Docs say the following:
addrspace can currently only be set to Core.CPU. It is designed to permit extension by other systems such as GPUs, which might define values such as:
module CUDA
const Generic = bitcast(Core.AddrSpace{CUDA}, 0)
const Global = bitcast(Core.AddrSpace{CUDA}, 1)
end
The exact semantics of these other addrspaces is defined by the specific backend, but will error if the user is attempting to access these on the CPU.
A lot of info is missing on how to customize this behavior but we should keep an eye on it.
The text was updated successfully, but these errors were encountered:
Julia 1.11 introduced
Core.Memory
and madeArray
a purely Julia type, which is nice for different optimization reasons. The interesting part for us is thatGenericMemory
has a parameter forkind
and another foraddrspace
, which could potentially be exploited by us to store the memory managed by XLA.This means that
ConcreteRArray
s could be managed by a simpleArray
instead, with the address space managed by Reactant.Docs say the following:
A lot of info is missing on how to customize this behavior but we should keep an eye on it.
The text was updated successfully, but these errors were encountered: