[Cython] [cython-users] GSoC 2012

[Robert Bradshaw]

On Sat, Mar 10, 2012 at 10:44 PM, mark florisson
<markflorisson88 at gmail.com> wrote:
> On 8 March 2012 14:27, Stefan Behnel <stefan_ml at behnel.de> wrote:
>> Hi,
>>
>> I noticed that people start rushing for the next season on Python's GSoC
>> mailing lists. Do we have any interested developers here, or general ideas
>> about suitable topics? I would expect that we'll do as in the last years
>> and participate under Python's umbrella.

Also, we'd like to see patches from anyone interesting in being a GSoC
student, as this will be a requirement as in past years.

> I will likely be submitting a proposal for the OpenCL support CEP.

OpenCL would be an interesting experiment, but I think still has
limited utility. Dag and I were talking the other day about the
challenge of generating the best possible code for evaluating array
expressions (think inlined memoryview arithmetic) taking into account
memory layout, blocking, etc. which Fortran does really well which
could be an interesting direction.

> As for other proposals, anyone can come up with something themselves or
> choose a suitable CEP. Some ideas:

Numbering items for clarity:

1.

> - fused cdef classes (probably not as an entire gsoc project)

2.

> - profile guided optimizations (using python's profilers and/or a
> custom profiler that collects data such as types etc, which can be
> used to specialize variables inside loops (or entire functions) with a
> fallback to normal mode in case the type changes)

3.

> - cython library to contain common functionality (although that might
> be a bit boring and rather involved)

4.

> - better type inference, that would be enabled by default and again
> handle thing like reassignments of variables and fallbacks to the
> default object type. With entry caching Cython could build a database
> of types ((extension) classes, functions, variables) used in the
> modules and functions that are compiled (also def functions), and
> infer the types used and specialize on those. Maybe a switch should be
> added to cython to handle circular dependencies, or maybe with the
> distutils preprocessing it can run all the type inference first and
> keep track of unresolved entries, and try to fill those in after
> building the database. For bonus points the user can be allowed to
> write plugins to aid the process.

5.

> - llvm based JIT :), i.e. have Cython instrument the generated code to
> record information and use that to create specializations at runtime
> (probably far out for a gsoc)


What I would most like to see is the common component in 2 and 4, i.e.
the ability to generate optimized code for imperfectly-inferred types,
with transparent fallback to generic code if conditions are not met at
runtime (during as well as at entering the optimized code path). Too
many times we have to decide between being safe for all cases or fast
for the common case.

That being said, there are few people I'd trust with such an ambitious
project, and you're on that short list :).

- Robert