On Wed, Jul 14, 2010 at 9:49 PM, Kurt Smith <kwmsm...@gmail.com> wrote: > On Wed, Jul 14, 2010 at 9:09 PM, Robert Bradshaw > <rober...@math.washington.edu> wrote: >> >> Though I can see the advantages of weave, I think it'd be even better >> if one didin't have to switch back and forth between completely >> unrelated syntaxes/types/etc. Do people use weave because there are >> certain things that are more natural to express in Fortran (and/or C), >> or is it primarily a convenient way to inline compiled code? Still >> waiting for someone to put up a wiki page on what they like from weave >> and what should go into Cython. > > I'll get to it soon; but this thread serves to get the ideas out there > in raw form. > > My impressions are from using weave a bit in the past and from those > who have mentioned interest in keeping it alive with a Cython > transplant (primarily Fernando). I welcome Fernando (& others) to > chime in with the other killer features that weave offers. And > critics of the weave 'approach' are more than weclome, too :-) > > (Note: I've only used weave, but much of what I say applies to blitz, too.) > > 1) For an existing function that has to be sped up, weave has a lower > barrier to usage than Cython, even with pyximport. (pyximport doesn't > enable an equivalent functionality as weave, so it isn't exactly > germane). It is very nice to just drop into C/C++ in the middle of a > function and have things compiled & run automatically. This is in > large part because weave allows incremental usage wherever needed on a > function-by-function basis, whereas Cython's smallest compilation unit > is the module.
We'd certainly like to support function-level compilation (though there are technical questions about how to get the source) and perhaps even line-by-line via strings. Right now the Sage notebook gives this feel for Cython, which is probably why I haven't felt the pinch (I rarely write and invoke a setup.py manually). > 2) I liked weave because you know you're getting to the metal with no > more than 5-10 lines of setup code, and with absolutely no fuss with > external tools or having to create a setup.py. This may sound lazy, > but it really is nice not to have to deal with these things. > Sometimes numpy array expressions aren't the most natural way to > express something, and you just want to cut through it all and get a > simple, fast C 'for' loop in there and move on, but cythonizing would > be too big of a step, or impossible if you have an inner function > somewhere else in the module, for example. Weave scratches the itch > very nicely. Yep. If I didn't use the notebook, I would also share your pain. > 3) The C-source-in-a-string is pretty ugly, I admit. Weave is very > far on the "practicality" side of the "practicality vs. purity" scale. > It is a small benefit, though, to have the C/C++ code quarantined to > one place in a function, and to always know exactly what to expect > from each part of your code -- python remains python, C remains C. > The fluidity of Cython is a tremendous advantage, but it does require > some care to be sure you're typing everything that needs to be typed, > turning off boundschecking when it's safe, etc. I tend to use 'cython > -a' or inspecting the generated source to be sure I'm "totally C" > fairly often. Weave gives this to you automatically. In short, with > weave, I don't have to pay attention as much to get the same degree of > performance. The tradeoff is ugly code. That's a good point--we should be a lot closer with type inference (and especially if we do the trick of compiling/specializing the code at runtime to the input types) but the fact that untyped code is just slower rather than broken is an interesting one. Almost makes me want to have a "C only" flag or something like that. > 4) Dag mentioned allowing Cython code in the source string. This > certainly has merit and I'm somewhat in favor of it. It would avoid > reinventing the wheel for the array indexing stuff, and would have a > more pythonic feel. But it would negate some of the benefits of > having "just C" in the source string. For those who like C. (Well, and the above point.) > 6) Up until now I've been assuming that this functionality will be > implemented as an external tool. Perhaps you (Robert, Dag, others) > have thoughts on getting some subset of weave's features in Cython > itself, namely the function-level compilation of a chunk of code. > Robert mentions this below with a @cython.compile decorator. And the > 'cython.eval(<cython source>)' has all the essential features of > weave/blitz right there, including the ugliness ;-) The whole build system question is a mess--one that I'm hoping fwrap can solve nicely :). It'd be nice if whatever comes out of it the semantics of inline C/C++/Fortran/Cython all had somewhat the same semantics, and possibly even shared some of the same code. > So, remaining issues: > > -) Essential features of weave/blitz that I haven't mentioned. > > -) Is this thing better off as an external tool, or integrated in cython > itself? > If the source string is cython code, then it's better as an > internal-to-cython tool. If C, then an external tool would suffice. I could see Cython as a "plugin" to a system that does this, aside C/C++/Fortran/??? It would take source and context, and return a callable/run the code. OTOH, some of the simpler features may be easier to put right into Cython itself. Certainly we want to make it easier to use Cython without having to fudge with all the build system stuff (which is, quite honestly, probably the hardest part of learning to use Cython). > -) I'll summarize this, make it less verbose, and put it on the wiki. That would be great. One we have something, others can add their killer/pet feature. - Robert _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
