[Cython] [cython-users] GSoC 2012

[Dag Sverre Seljebotn]

On 03/21/2012 01:56 PM, Robert Bradshaw wrote:
> 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.

Yes, a lot of water has run in the river since March 8 here. Anyone 
interested in reading up on current ideas on what Mark is thinking for 
his GSoC proposal should read up on the numpy-discussion thread "Looking 
for people interested in helping with Python compiler to LLVM".

Dag

>
>> 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
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel