fista.lua:61: bad argument #1 to 'resizeAs' (torch.FloatTensor expected, got torch.CudaTensor)

[graphific]

running the demo_conv_psd_gpu.lua or my own code I get the following error. Seems like it still uses optim.fista in line 119

local code, h = optim.FistaLS(self.f, self.g, self.pl, self.code, self.params)

error:

==> constructed convolutional predictive sparse decomposition (PSD) auto-encoder
==> training model
==> estimating diagonal hessian elements
XXX/torch/install/share/lua/5.1/optim/fista.lua:61: bad argument #1 to 'resizeAs' (torch.FloatTensor expected, got torch.CudaTensor)
stack traceback:
    [C]: at 0x010e1851d0
    [C]: in function 'resizeAs'
    /Users/XXX/torch/install/share/lua/5.1/optim/fista.lua:61: in function 'FistaLS'
    .../XXX/torch/install/share/lua/5.1/unsupgpu/FistaL1.lua:119: in function 'updateOutput'
    /Users/XXX/torch/install/share/lua/5.1/unsupgpu/psd.lua:52: in function 'updateOutput'
    demo_conv_psd_gpu.lua:186: in main chunk

[viorik]

As per issue #2, there is a compatibility issue with optim/fista.lua, so I added this at line 55 in optim/fista.lua:

if (xinit:type() == 'torch.CudaTensor') then
      params.xkm = params.xkm:cuda()
      params.y   = params.y:cuda()
      params.ply = params.ply:cuda()
end

I still need to think of a better way to do this, so that we don't need to change fista. Does this solve the problem?

[graphific]

yes that works! I also had to remove the torch.setdefaulttensortype('torch.FloatTensor') which is causing trouble as it makes fista expect a float.

So your code does work on the gpu, congrats to that!
It seems though to to switch data back and forth between gpu and ordinary float storage quite a bit.

Running the same conv-psd demo with and without the gpu, using batchsize of both 1 and similar settings, the pure cpu code has a steptime of 80ms, while the cuda one stays around 140ms, so actually much worse.

Have you tried to benchmark the times yourself, is it maybe something I'm doing wrong on my side?

If I can make the time, I'll play around with it a bit more, and see if I can speed things up a bit.

[viorik]

Cool, could you close this issue then?
For benchmarking, I haven't tried to do that. However, I've made the necessary changes to make it run on mini-batches, hoping the advantage would be visible there. In the same time, optimisation-wise it's better to have relatively small batches, so that weights get updated more often, so tough to say if gpu really helps in this case. I am using it with batchSize 5.