# GPUArrays, 64-32bit conversions, and Cassete.jl
**URL:** https://discourse.julialang.org/t/gpuarrays-64-32bit-conversions-and-cassete-jl/14294
**Category:** GPU
**Created:** [August 30, 2018, 8:11am UTC](https://discourse.julialang.org/t/gpuarrays-64-32bit-conversions-and-cassete-jl/14294 "2018-08-30T08:11:40Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [August 30, 2018, 8:11am UTC](https://discourse.julialang.org/t/gpuarrays-64-32bit-conversions-and-cassete-jl/14294/1 "2018-08-30T08:11:40Z")
I’m writing some frameworks that run arbitrary user code on the GPU, but I’m missing the performance gains of using only 32bit numbers.
Is anyone else thinking about automatic 32/64 bit code transformations using Cassette.jl? Or other options?
---
### Author:  [@piever](https://discourse.julialang.org/u/piever)
#### Post date: [August 30, 2018, 8:55am UTC](https://discourse.julialang.org/t/gpuarrays-64-32bit-conversions-and-cassete-jl/14294/2 "2018-08-30T08:55:45Z")
I’m not sure if it’s the recommended option, but there is [https://github.com/stevengj/ChangePrecision.jl](https://github.com/stevengj/ChangePrecision.jl)
---
### Author:  [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [August 30, 2018, 9:01am UTC](https://discourse.julialang.org/t/gpuarrays-64-32bit-conversions-and-cassete-jl/14294/3 "2018-08-30T09:01:38Z")
Oh thanks I hadn’t seen that. But this might be an issue:
> Code _hidden inside_ external functions that are called is not affected.
That’s often the code I’ll need to change! Everything that will be compiled during GPUArrays broadcast needs to be converted first, unless I misunderstand the problem.
---
### Author:  [@vchuravy](https://discourse.julialang.org/u/vchuravy)
#### Post date: [August 30, 2018, 2:30pm UTC](https://discourse.julialang.org/t/gpuarrays-64-32bit-conversions-and-cassete-jl/14294/4 "2018-08-30T14:30:51Z")
Are you interested in `Float32``Float64` or in downconverting integer operations? For the former you just need to make sure that your input data is in the right format and that your code is type-stable.
---
### Author:  [@sdanisch](https://discourse.julialang.org/u/sdanisch)
#### Post date: [August 30, 2018, 2:40pm UTC](https://discourse.julialang.org/t/gpuarrays-64-32bit-conversions-and-cassete-jl/14294/5 "2018-08-30T14:40:41Z")
That doesn’t help if you call some existing function that does e.g. `a + 1.0`
---
### Author:  [@vchuravy](https://discourse.julialang.org/u/vchuravy)
#### Post date: [August 30, 2018, 2:47pm UTC](https://discourse.julialang.org/t/gpuarrays-64-32bit-conversions-and-cassete-jl/14294/6 "2018-08-30T14:47:53Z")
Yes, but that is not a GPU specific problem and not one that we can solve as compiler optimization.
---
### Author:  [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [August 30, 2018, 2:49pm UTC](https://discourse.julialang.org/t/gpuarrays-64-32bit-conversions-and-cassete-jl/14294/7 "2018-08-30T14:49:16Z")
> [@sdanisch](#):
>
> That doesn’t help if you call some existing function that does e.g. `a + 1.0`
Generic codes should never do that. `a + one(eltype(a))` always works.
---
### Author:  [@sdanisch](https://discourse.julialang.org/u/sdanisch)
#### Post date: [August 30, 2018, 3:03pm UTC](https://discourse.julialang.org/t/gpuarrays-64-32bit-conversions-and-cassete-jl/14294/8 "2018-08-30T15:03:19Z")
yeah, generic code should also never contain bugs, but i guess it happens more often than we like in the end 😛
i tried to write a simple cassette pass to always convert float64 to float32 if it encounters it in the arguments of a function call, but the code didnt infer nicely - hopefully just me being a novice cassette user 😉
---
### Author:  [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [August 30, 2018, 3:06pm UTC](https://discourse.julialang.org/t/gpuarrays-64-32bit-conversions-and-cassete-jl/14294/9 "2018-08-30T15:06:30Z")
I want to convert to both Float32 and Int32. Lots of the operations are Int working on arrays of Int, and just passing in an array of Int32 doesn’t seem to work. Just the ram savings of Int32 arrays just working would make it worthwhile.
I personally would never do a + 1.0 but who knows what users will do! Convention and sticking to oneunit(x) etc is the best method but eventually just fixing it all with Cassette.jl might just work…
@sdanisch do you have a gist of that converter? I might have a go in the next few weeks.