On 28 May 2012 13:49, mark florisson <markflorisso...@gmail.com> wrote: > On 25 May 2012 21:53, Frédéric Bastien <no...@nouiz.org> wrote: >> Hi, >> >> >> Sorry for the delay, I had some schedule change. >> >> thanks for adding me. Should I subscribe to cython-dev? How much email >> daily there is? I didn't found this on the archives. Fell free to add >> me in CC again when you think it is appropriate. > > There is usually not so much traffic on cython-dev, unless something > comes up that is debated to the death :) > >> I'll reply here to all email at the same time. Do you prefer that I >> reply to each email individually if this happen again? I'll try to >> reply faster next time. > > No worries, either way works fine, don't worry too much about protocol > (the only thing to note is that we do bottom posting). > >> - About pickling theano, we currently can't pick Theano function. It >> could be made to work in some cases, but not for all cases as there is >> hardware dependent optimization in the Theano function. Currently it >> is mostly CPU vs GPU operation. So if we stay on the CPU, we could do >> some pickling, but we should make sure that the compiled c code into >> python module are still there when we unpickle or recompile them. >> >> - I think it make sense to make a theano graph from cython ast, >> optimize and redo a cython ast from the optimized graph. This would >> allow using Theano optimizations. > > Ok, the important thing is that the graph can be pickled, it should be > pretty straightforward to generate code to build the function again > from the loaded graph. > >> - It also make sense to do the code generation in Theano and reuse it >> in Cython. But this would make the Theano dependency much stronger. >> I'm not sure you want this. >> >> >> - Another point not raised, theano need to know at compile time is the >> dtype, number of dimensions and witch dimensions are broadcastable for >> each variable. I think that the last one could cause problem, but if >> you use specialization for the dtype, the same can be done for the >> broadcsatability of a dimensions. > > Hm, that would lead to kind of an explosion of combinations. I think > we could specialize only on no broadcasting at all (except for > operands with lesser dimensionality). > >> - The compyte(gpu nd array) project do collapsing of dimensions. This >> is an important optimization on the GPU as doing the index computation >> in parallel is costlier. I think on the CPU we could probably do >> collapsing just of the inner dimensions to make it faster. >> >> - Theano don't generate intrinsect or assembly, but we suppose that >> g++ will generate vectorized operation for simple loop. Recent version >> of gcc/g++ do this. > > Right, the aim is definitely to specialize for contiguous arrays, > where you collapse everything. Specializing statically for anything > more would be unfeasible, and better handled by a runtime compiler I > think. For the C backend, I'll start by generating simple C loops and > see if the compilers vectorize that already. > >> - Our generated code for element-wise operation take care a little >> about the memory access pattern. We swap dimensions to iterate on the >> dimensions with the smallest strides. But we don't go further. >> >> - What do you mean by CSE? Constant optimization? > > Yes, common subexpression elimination and also hoisting of unchanging > expressions outside the loop. > >> Fred > > I started a new project, https://github.com/markflorisson88/minivect , > which currently features a simple C code generator. The specializer > and astbuilder do most of the work of creating the right AST, so the > code generator only has to implement code generation functions for > simple expressions. Depending on how it progresses I will look at > incorporating Theano's optimizations into it and having Theano use it > as a C backend for compatible expressions.
I forgot to mention, it's still pretty basic, but it works for simple arithmetic expressions with non-overlapping (shifted) memory from Cython: https://github.com/markflorisson88/cython/commit/2c316abdbc1228597bbdf480f737a59213ee9532#L4R1 _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
