Open Roger-luo opened 5 years ago
current interface is some_circuit |> cu
, why don't we use cu
instead of gpu
?
I used to use cu
in Flux but ended up going against that; adapt
means something different and it doesn't really work to apply it to models.
It might be nice to re-use Flux's treelike
functionality in Yao though. I'd be happy to split it out into its own package if that's useful to you.
@MikeInnes Unfortunately, we can not import Flux into our project for using the gpu
interface only. Is there any example to help me and Roger understand why using cu
can be a problem?
Also, what are the treelike
functionality in Flux? It sounds very interesting.
@MikeInnes
I personally prefer cuda
instead of gpu
tho, pytorch use this as well.
Regarding to treelike, we already have one (tho, it's a bit ugly at the moment), it provides the traversing functionality and printing etc. I think we should bring that abstract tree package back to life, so we could merge those effort on this.
we will consider to integrate with Flux's AD or Zygote in another package which provides AD for quantum circuits. But Yao will be something like DE.jl, a meta package.
Sure, I'm not expecting you to take a Flux dependency. Splitting out the treelike
stuff would be the right move.
The reason for gpu
as opposed to cu
, in Flux, is that it's hardware agnostic, e.g. in principle gpu
could convert to CLArrays, if you have that loaded. I can't remember what the specific problem with using adapt directly was though, to be honest. If you don't hit any conflicts with it then it might be fine.
@MikeInnes What about AbstractTree.jl, I copied part of it while implementing our printings. Is there any reason Flux is not using this?
Maybe we should just have some functions instead of providing any type for them.
For Flux's purposes at least, we don't really need AbstractTrees' functionality. We really just need mapchildren
and then the rest follow from there.
@MikeInnes I see. I guess you only need that for the conversion between CPU and GPU in Flux.
We do need some traverse API to dispatch/collect parameters however, unlike normal machine learning models we need to dispatch parameter across the whole tree. The block tree in Yao is actually a kind of AST in some sense, so it requires more functionality of a tree-like data structure.
Maybe we should avoid using gpu
, since we do have a vague plan to combine Yao.jl
and Flux.jl
in the future in another projects about differentiable quantum circuits. Then it will be anoying to have naming conflicts. Also, CuYao.jl
supports CuArrays
only, so that we don't have the problem of different types of GPU arrays. So far, I haven't see any problem of using cu
in my current research project yet. But still thank @MikeInnes for reminding us about this potential problem.
The block tree in Yao is actually a kind of AST in some sense, so it requires more functionality of a tree-like data structure.
In fact, I am pretty happy with current recursive approach to visit all nodes :joy: . What can we expect from the AbstractTree
? Or what kind of functionality do you want to support? @Roger-luo
@MikeInnes I'd love to have cuda
for converting to CuArray
and opencl
/cl
for converting to CLArray
and maybe also tpu
for converting to XRTArray
. And they are also simple bindings to a mapchildren
in Flux. This is more explicit than gpu
. (maybe I should post this in Flux).
@GiggleLiu No, I mean it requires more functionality of a tree-like data structure than Flux's treelike
.
For conversion between CPU and GPU in Yao, I think we can just use our own tree operators for now.
This package should provide a
gpu
function that do the following, like https://github.com/FluxML/Flux.jl/pull/513