On 07/15/2010 07:27 AM, Robert Bradshaw wrote: > On Wed, Jul 14, 2010 at 9:49 PM, Kurt Smith<[email protected]> wrote: > >> On Wed, Jul 14, 2010 at 9:09 PM, Robert Bradshaw >> <[email protected]> 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). >
Here's some work which gets the source from decorated functions (in pure Python...the decorator could extract source, compile with Cython, and replace the decorated function with one imported from the compiled one): http://github.com/GaelVaroquaux/joblib/blob/master/joblib/func_inspect.py Of course this requires a stronger pure Python mode. >> 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. > We already discussed having a decorator for disallowing untyped variables. Basically you would need to type every variable in a function, but typing as "object" would be OK. I think this is more useful than "C only" in this context. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
