Stefan Behnel wrote: > Roland Schulz wrote: >> 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. >> [...] >> 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). > > I think the main question then is: what would be the minimum required > change to the compiler that would enable providing these things as > external > modules?
Provided that everything in the proposal is implemented in core Cython (i.e. naive SIMD loops are implemented as a simple fallback mechanism etc.), and it is done in a way using seperate node types (e.g SIMDArithmeticNode), I was thinking to just have a pluggable pipeline, and allow plugins to provide transforms and positions in the pipeline to plug them in. (Oh, and plugin transforms could insert their own nodes too.) This would require plugin developers to follow Cython node tree changes (which one wouldn't promise to keep stable). I'm not sure whether such a thing would work or whether there will be requests of the form "can you just change this thing in this node before it gets to our plugin transform". But I think that's a luxury problem -- if people do develop such plugins, it means more eyes on the Cython codebase too. Dag Sverre _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
