librelist archives

« back to archive

Things to learn from pymothoa

Things to learn from pymothoa

From:
Travis Oliphant
Date:
2012-06-30 @ 22:34
I just saw this project announced on LLVMdev.  I've contacted the author 
already to see if we can't collaborate together.   But, regardless, we 
should learn from what he is doing.   I don't like the way he is spelling 
types, but on the other hand that is something that can have multiple 
styles.   He is also not handling NumPy arrays directly and I think the 
desire to try and write matrix-multiply in Python and hope to beat ATLAS 
or MKL is going to be a challenge. 

But, there is a lot to learn from his project.  It's very cool. 

http://code.google.com/p/pymothoa/

-Travis

Re: [numba] Things to learn from pymothoa

From:
mark florisson
Date:
2012-07-01 @ 10:26
On 30 June 2012 23:34, Travis Oliphant <travis@continuum.io> wrote:
> I just saw this project announced on LLVMdev.  I've contacted the author
> already to see if we can't collaborate together.   But, regardless, we
> should learn from what he is doing.   I don't like the way he is spelling
> types, but on the other hand that is something that can have multiple
> styles.   He is also not handling NumPy arrays directly and I think the
> desire to try and write matrix-multiply in Python and hope to beat ATLAS or
> MKL is going to be a challenge.
>
> But, there is a lot to learn from his project.  It's very cool.
>
> http://code.google.com/p/pymothoa/
>
> -Travis
>

Great, I think it would be better to rebase the numba idea on this
project, since the current approach is in dire need of an AST, since
the bytecode format is too stateless and not easily adaptable to AST
transformations (as an example, we handle range()/xrange() rewrites
through a delayed state which crosses multiple instructions and
finally triggers a for loop code generation at the STORE_FAST
instructrion). I think there's definitely code that can be kept and
moved over. We could discuss whether the author is open to
type-inference which does not allow rebinding of the type for
variables.

As for control flow, I've been wondering whether we really need to
manually implement SSA manually (however cool), since LLVM's mem2reg
optimization pass can promote most (or all?) alloca memory accesses to
registers.

Re: [numba] Things to learn from pymothoa

From:
Travis Oliphant
Date:
2012-07-01 @ 12:24
On Jul 1, 2012, at 5:26 AM, mark florisson wrote:

> On 30 June 2012 23:34, Travis Oliphant <travis@continuum.io> wrote:
>> I just saw this project announced on LLVMdev.  I've contacted the author
>> already to see if we can't collaborate together.   But, regardless, we
>> should learn from what he is doing.   I don't like the way he is spelling
>> types, but on the other hand that is something that can have multiple
>> styles.   He is also not handling NumPy arrays directly and I think the
>> desire to try and write matrix-multiply in Python and hope to beat ATLAS or
>> MKL is going to be a challenge.
>> 
>> But, there is a lot to learn from his project.  It's very cool.
>> 
>> http://code.google.com/p/pymothoa/
>> 
>> -Travis
>> 
> 
> Great, I think it would be better to rebase the numba idea on this
> project, since the current approach is in dire need of an AST, since
> the bytecode format is too stateless and not easily adaptable to AST
> transformations (as an example, we handle range()/xrange() rewrites
> through a delayed state which crosses multiple instructions and
> finally triggers a for loop code generation at the STORE_FAST
> instructrion). I think there's definitely code that can be kept and
> moved over. We could discuss whether the author is open to
> type-inference which does not allow rebinding of the type for
> variables.

We should move over code from pymothoa and not the other way around.    We
will need to have more control over what goes into Numba and the road-map 
than will be afforded by piggy-backing on his project. 

I think we can and should keep the current byte-code based path and start 
another path that uses the AST.    Pymothoa uses the inspect.getsource 
function to get the ast from the function object.   This doesn't always 
work, but it's a good start.   

Mark, this is a good thing for you to work on, I think.    Feel free to 
borrow as much as you want from the Pymothoa project and just cite the 
author.    His project looks appropriately licensed.  

Thanks,

-Travis




> 
> As for control flow, I've been wondering whether we really need to
> manually implement SSA manually (however cool), since LLVM's mem2reg
> optimization pass can promote most (or all?) alloca memory accesses to
> registers.

Re: [numba] Things to learn from pymothoa

From:
mark florisson
Date:
2012-07-01 @ 12:45
On 1 July 2012 13:24, Travis Oliphant <travis@continuum.io> wrote:
>
> On Jul 1, 2012, at 5:26 AM, mark florisson wrote:
>
>> On 30 June 2012 23:34, Travis Oliphant <travis@continuum.io> wrote:
>>> I just saw this project announced on LLVMdev.  I've contacted the author
>>> already to see if we can't collaborate together.   But, regardless, we
>>> should learn from what he is doing.   I don't like the way he is spelling
>>> types, but on the other hand that is something that can have multiple
>>> styles.   He is also not handling NumPy arrays directly and I think the
>>> desire to try and write matrix-multiply in Python and hope to beat ATLAS or
>>> MKL is going to be a challenge.
>>>
>>> But, there is a lot to learn from his project.  It's very cool.
>>>
>>> http://code.google.com/p/pymothoa/
>>>
>>> -Travis
>>>
>>
>> Great, I think it would be better to rebase the numba idea on this
>> project, since the current approach is in dire need of an AST, since
>> the bytecode format is too stateless and not easily adaptable to AST
>> transformations (as an example, we handle range()/xrange() rewrites
>> through a delayed state which crosses multiple instructions and
>> finally triggers a for loop code generation at the STORE_FAST
>> instructrion). I think there's definitely code that can be kept and
>> moved over. We could discuss whether the author is open to
>> type-inference which does not allow rebinding of the type for
>> variables.
>
> We should move over code from pymothoa and not the other way around.    
We will need to have more control over what goes into Numba and the 
road-map than will be afforded by piggy-backing on his project.

That's fine with me as well. I was thinking of forking it and adding
stuff to it, and then see if changes can get merged, or go our
separate ways. If the author and Numba have similar goals, this will
also allow the author to contribute. Merging new functionality after
incorporation into numba will be much harder.

> I think we can and should keep the current byte-code based path and 
start another path that uses the AST.    Pymothoa uses the 
inspect.getsource function to get the ast from the function object.   This
doesn't always work, but it's a good start.
>
> Mark, this is a good thing for you to work on, I think.    Feel free to 
borrow as much as you want from the Pymothoa project and just cite the 
author.    His project looks appropriately licensed.

Great, I'm going to work on my dissertation for the next few days, so
I'll start with that Wednesday.

> Thanks,
>
> -Travis
>
>
>
>
>>
>> As for control flow, I've been wondering whether we really need to
>> manually implement SSA manually (however cool), since LLVM's mem2reg
>> optimization pass can promote most (or all?) alloca memory accesses to
>> registers.
>