On Mon, Feb 20, 2012 at 2:57 PM, Lluís <xscr...@gmx.net> wrote: > James Bergstra writes: > [...] > > I should add that the biggest benefit of expressing things as compound > > expressions in this way is not in saving temporaries (though that is > nice) it's > > being able to express enough computation work at a time that it offsets > the time > > required to ship the arguments off to a GPU for evaluation! > > Right, that's exacly what you need for an "external computation" to pay > off. > > Just out of curiosity (feel free to respond with a RTFM or a RTFP :)), do > you > support any of these? (sorry for the made-up names) > > * automatic transfer double-buffering >
Not currently, but it would be quite straightforward to do it. Email theano-dev and ask how if you really want to know. > > * automatic problem partitioning into domains (e.g., multiple GPUs; even > better > if also supports nodes - MPI -) > Not currently, and it would be hard. > > * point-specific computations (e.g., code dependant on the thread id, > although > this can also be expressed in other ways, like index ranges) > > No. > * point-relative computations (the most common would be a stencil) > > No, but I think theano provides a decent expression language to tackle this. The "Composite" element-wise code generator is an example of how I would think about this. It provides point-relative computations across several arguments. You might want something different that applies a stencil computation across one or several arguments... the "scan" operator was another foray into this territory, and it got tricky when the stencil operation could have side-effects (like random number generation) and could define it's own input domain (stencil shape), but the result is quite powerful. -- http://www-etud.iro.umontreal.ca/~bergstrj
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
