Yes, it seems like transonic could be of use here.
But there will be some issues:
How do we handle this function?
def StridedSlice(input_, begins, ends,strides):
slices = tuple([slice(b,e if e else None,s) for b,e,s in
zip(begins,ends,strides)])
return (input_)[slices],
I'm pretty sure this can't be compiled by pythran at this point.
Jean
On 3/21/19 12:57 AM, PIERRE AUGIER wrote:
----- Mail original -----
De: "serge guelton" <serge.guelton@xxxxxxxxxxxxxxxxxxx>
À: "pythran" <pythran@xxxxxxxxxxxxx>
Envoyé: Jeudi 21 Mars 2019 07:24:29
Objet: [pythran] Re: [ripngo@xxxxxxxxx: Re: Re: Use pythran to deploy
tensorflow models.]
I hacked hacked a script to load a tfdeploy graph and output a .py
file that contains the series of calls to the tensorflow-equivalent
functions that are defined in tfdeploy. In addition, the script copies
those functions to the output .py file, and loads the various graph
variables from a .npz file.
I'm happy to say that this simple hack just worked right off the bat
(in python, not in pythran yet).
Note that this kind of boring task (write a Pythran file to pythranize
functions, by extracting the code needed for Pythran to compile them) could be
done by Transonic. Transonic is not right now able to add an imported function
to the Pythran file, but technically, it does not seem difficult. And anyway,
this feature has to be added.
I mean something like:
from tfdeploy import bar
from transonic import jit
@jit
def foo(x, y):
return x + bar(y)
With @jit no Pythran signature needed.
To me this is already a big improvement!
This output .py file could *almost* compile in pythran as-is, but
because of the use of slices to select part of a tensor this won't
compile just yet.
I forsee an issue opening in the bug tracker :-)
In any case, this shows that the concept is doable. But I see some
complications:
- Tensorflow functions can accept tensors of any dimensions, but
pythran many not be that flexible if I'm not mistaken. That's
especially true when exporting (float [] [] vs float [] [] [] for
example).
Yeah, that's a hard limitation of pythran. The usual way to deal with that in
pythran is to spawn multiple `#pythran export`. Is that an issue in your
context?
This could be a good use case for the @jit decorator of Transonic for which you
don't need to write the function signatures because they are automatically
added at run time.
- Some operations require functions that are not yet implemented in
pythran (solve etc). I don't use them myself, and I don't know anybody
who does, as inference typically does not require such functions. So
this may not be a problem in practice.
We can operate on-demand and implement those as needed.
But this is pretty cool!
It is!
Indeed! Great idea!
