[pythran] [serge.guelton@xxxxxxxxxxxxxxxx: A few ideas cocnerning JIT-typing]

From: serge Guelton <serge.guelton@xxxxxxxxxxxxxxxx>
To: pythran@xxxxxxxxxxxxx
Date: Tue, 26 Feb 2013 09:29:35 +0100

Ooops forgot to send this to everyone.

----- Forwarded message from serge Guelton <serge.guelton@xxxxxxxxxxxxxxxx> 
-----

Date: Mon, 25 Feb 2013 21:57:11 +0100
From: serge Guelton <serge.guelton@xxxxxxxxxxxxxxxx>
To: Mehdi AMINI <mehdi.amini@xxxxxxxxxxxxxxx>
Subject: A few ideas cocnerning JIT-typing

Hi Mehdi, (and the other pythraners)

here are the few ideas I had concerning JIT-typing, i.e. translating
python code to native code at runtime, using the type informations
available during execution

First step, that seems easy but already raises a few issues, would be
include the type signature in the decorator

import pythran

@pythran.native([int],[int])
def dprod(l0,l1):
    return sum(x*y forr x,y in zip(l0, l1))

It would be nice to be able to have several types

@pythran.native([int],[int])
@pythran.native([float],[float])
def dprod(l0,l1):
    return sum(x*y forr x,y in zip(l0, l1))

what if we have callees ? you have to build a (potentially) approximated
callgraph, isolate them in a new module and native-compile them. Note
that there is no such analysis in Pythran, although the callgraph is
built during execution of a few passes. And that you cannot rely on the
ast refinements made by the early python passes.

Otherwise everything is already there and you should be able to handle
everything with the top-level functions from pythran package. That would
make a single nice commit, let's say step1

But the real challenge is to handle (let's say step2, and commit n°2)

@pythran.native
def dprod(l0,l1):
    return sum(x*y forr x,y in zip(l0, l1))

sounds easy as you have all the typing informations available, and from
them you should be able to apply step1.

*but* if one passes an empty list to be filled by the function
processing? What's its type.

Well currently Pythran will not fill the list, because top level
arguments are all const (it makes python <> C conversion easier). To
handle the case properly, we have the update effect that tells you if
it's really const. And if it's not, one should manage the copy-back (how
to do this elegantly in boost.Python?) and the backward-typing
information, the well-known combiners.

That's all what I have been thinking about, if anyone has ideas /
comments....

----- End forwarded message -----

[pythran] [serge.guelton@xxxxxxxxxxxxxxxx: A few ideas cocnerning JIT-typing]

Other related posts: