On Thu, Jun 11, 2009 at 5:22 PM, Dag Sverre Seljebotn < da...@student.matnat.uio.no> wrote:
> Thanks for your input!, you definitely know more about such computations > than me. > > Roland Schulz wrote: > > > > > > On Thu, Jun 11, 2009 at 4:01 PM, Dag Sverre Seljebotn > > <da...@student.matnat.uio.no <mailto:da...@student.matnat.uio.no>> > wrote: > > > Right :-) Now linear algebra support in the compiler *would* be > taking > > things quite overboard (and probably only slow things down, unless N > is > > really small, like 4x4 3D game matrices...), I'm actually against > that. > > > > > > > > Well only if you do it directly in a hard-coded datatype. > > > > Why not having a non numeric base class as Stefan proposed. And then > > allowing the operator functions be handled by Eigen/Blitz. This would > > enable very fast numerics, including SSE and fast linear algebra. And > > without having it as tightly coupled in the main language. Similar in > > that expect to weave, but with all the advantages of cython. > > I'll answer this below. > > > > > Component wise operations without optimization (thus collapsing > > d=a*b*c*d into one loop instead of 3 and not using temporary arrays) > > does not give you any speed-up over Numpy for vectorized code with large > > arrays. > > > > For vectorized Numpy code the bottleneck is not the call from Python to > > C, but the inefficient use of cache because of the temporary arrays. > > I don't know enough about this, but these two paragraphs seem slightly > contradictory to me. I think it is important to see which features of this proposals are possible but will only be included in the unforeseeable (=may be never) future and what could/will be done soon. Of course this depends on how much time there is so it is difficult to say. By point is, if collapsing d=a*b*c*d into one loop is possible, but is not clear when it will be added, this proposal won't speed up calculations over vectorized numpy for the foreseeable furture. Or putting it another way: Introducing only element-wise access won't help performance by itself, so performance wise it is not a meaningful intermediate step. Also this optimization is not straight forward. If you look at http://eigen.tuxfamily.org/index.php?title=Benchmark-August2008 you see that many libraries trying to do even simple Y+=alpha X do a bad job performance wise. And having to do all the required optimization in the cython compiler would basicly mean rewriting the Frotran Compiler. And of course the language is suboptimal but the compiler can be sometimes rather smart. And putting all this in the Cython compiler sounds like awful a lot of work. > > Anyway: Any builtin features as such in Cython can't really depend on > Eigen/Blitz. (I know this is perhaps not what you are suggesting, but > bear with me.) > > As the CEP 517 says, I see this as a two-step process: > > 1) Naive C loops produced by Cython, which will be "good enough" for > many cases, and which gives a reference spec and implementation which > runs out of the box without library requirements. > > 2) Various plugins (with a seperate release process from Cython so that > work in this area doesn't bog down Cython development), using e.g. > Eigen/Blitz as backends, or run it on a GPU, in parallell using OpenMP > (well, for heavy componentwise functions), etc. etc. Why does it bog down Cython delvelopment if it is a library with ships with cython? Also you can always require certain version of the external components (and make it optional for complication for people not interested in numerics). > > > > > And I don't think you need a full metalanguage to map the array class to > > Eigen/Blitz. Though it would be still be couple somewhat to the main > > language otherwise I agree you would need a metalanguage or full > > template support. But it seems to me that there should be an optimum > > between full template support and doing the numerics directly in a > > language specific numeric array type. Sorry for being vage in this > > central point. I just don't know the cython details here. > > Well, the point here is that when you use Eigen/Blitz, what you do is > use the metalanguage of C++. Which is much more powerful than anything > we're likely to get in Cython. So in some sense you use C++ to do what > you cannot do in Cython. Exactly you have rather easy usage of Eigen/Blitz and only that code has to be generated by Cython. Then the C++ compiler takes care of the expression templates. Roland -- ORNL/UT Center for Molecular Biophysics cmb.ornl.gov 865-241-1537, ORNL PO BOX 2008 MS6309
_______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev