[Cython] Fwd: Re: [Numpy-discussion] Proposed Roadmap Overview

[Robert Bradshaw]

On Tue, Feb 21, 2012 at 12:18 PM, Nathaniel Smith <njs at pobox.com> wrote:
> On Tue, Feb 21, 2012 at 8:02 PM, Robert Bradshaw
> <robertwb at math.washington.edu> wrote:
>> On Tue, Feb 21, 2012 at 9:19 AM, mark florisson
>> <markflorisson88 at gmail.com> wrote:
>>> On 21 February 2012 04:42, Robert Bradshaw <robertwb at math.washington.edu> wrote:
>>>> Python bytecode -> LLVM is a great idea for creating ufuncs, the
>>>> overhead of Cython + GCC is atrocious for stuff like this. (I think
>>>> Cython could make a good frontent as well, especially if we generated
>>>> just the .c code for the function rather than a full extension module
>>>> and used a good compiler to generate machine code in-memory
>>>> on-the-fly.)
>>>
>>> I want elementwise functions and reductions for Cython as well, but
>>> they would be specialized according to the types you use them for, so
>>> it wouldn't be atrocious bloat (at least, no more then you'd already
>>> be having).
>>> I've been giving profile guided optimizations some thoughts as well, I
>>> think they are most neatly handled through a python tracer that is
>>> installed e.g. through sitecustomize which collects data about types,
>>> time spent in which code regions etc during testing and development.
>>> You can then tell Cython to compile the module, so e.g. if it
>>> registered "a numpy array" it could generate some specializations for
>>> dtypes either statically or dynamically through OpenCL. The
>>> alternative approach using code instrumentation would be more of a
>>> chore but would work just as well for Cython code with object-typed
>>> arguments. That's all rather far off, and this looks like an
>>> interesting development.
>>
>> One of the reasons JIT compilers can do so well is that they can use
>> runtime profile information to write specialized code. It'd be great
>> to be able to incorporate this kind of profiling into a Cython compile
>> too. One of the big missing features here is a "fallback mode" where
>> we can insert guards and fall back to generic code if they're not met,
>> which I think would open us up to a huge number of optimizations
>> without violating Python semantics.
>
> A really neat first-step would be to write a straight LLVM backend for
> Cython -- instead of generating code, one could generate equivalent
> in-memory IR. (The really hacky way to do this would be to throw the
> output of the current C code generator through Clang.) That seems
> achievable (at least as pie-in-the-sky projects go), and even if
> no-one ever got around to adding fancier profile-guided optimizations,
> it would still be useful.

For better or for worse, Python is still pretty tied to C (or C like
languages, with higher level concepts like function calls). But
spitting out C snippets for Clang to consume would still be cool.

> For instance, it would be possible to not
> just import .pyx modules directly, but reload() them after editing
> (!!). Or have a cython.inline() function that works like weave.inline,
> but more awesome.

Note that there is a cython.inline:
http://wiki.cython.org/enhancements/inline . The compile-time overhead
(it creates a full extension module to compile with gcc (but does do
caching)) could be greatly improved with something like this.

- Robert