Am 20.03.2012 18:35, schrieb Andy Ray Terrel:
Well I was thinking more of taking a piece of c code, but it could be
take a python function, grab the code object and manipulate that.
What I really want is to play around with symbolic code optimizations
and since we have quite a few tools to go
I think you're right that rebuilding everything that goes into a compiler
is far too much work for a GSoC student (or really this whole community). I
think that Andy is suggesting more local edits - surface level only. Lets
just walk through the code and see what simplifications we can make using
Le mercredi 21 mars 2012 à 08:36 -0700, Matthew Rocklin a écrit :
I think you're right that rebuilding everything that goes into a
compiler is far too much work for a GSoC student (or really this whole
community). I think that Andy is suggesting more local edits - surface
level only. Lets just
I doubt there's much that can be done while strictly preserving the
semantics of the language (addition and multiplication of floats aren't
associative). OTOH, if we assume that the programmer wanted to use
infinite-precision real numbers, we can probably do some useful
transformations, but
On Wed, Mar 21, 2012 at 11:27 AM, Ronan Lamy ronan.l...@gmail.com wrote:
Le mercredi 21 mars 2012 à 08:36 -0700, Matthew Rocklin a écrit :
I think you're right that rebuilding everything that goes into a
compiler is far too much work for a GSoC student (or really this whole
community). I think
I wonder if we can take advantage of the low-level interpretation from
a compiler to make the parsing easier, for example, LLVM's
intermediate language. I haven't really studied that much, so I don't
know if it would really be useful or not.
Aaron Meurer
On Wed, Mar 21, 2012 at 9:36 AM, Matthew
I would like to play more with the LLVM implementation. Check out
https://github.com/ContinuumIO/numba
Some points I see coming up:
* REAL codes are layered and have hot loops in them. I would only
target the small hot loops that get run a lot. (Such as a ufunc for
numpy.)
* In general, we
On Wed, Mar 21, 2012 at 3:10 PM, Andy Ray Terrel andy.ter...@gmail.com wrote:
I would like to play more with the LLVM implementation. Check out
https://github.com/ContinuumIO/numba
Cool. Is that related to the unladen swallow project?
Aaron Meurer
Some points I see coming up:
* REAL
On Wed, Mar 21, 2012 at 4:32 PM, Aaron Meurer asmeu...@gmail.com wrote:
On Wed, Mar 21, 2012 at 3:10 PM, Andy Ray Terrel andy.ter...@gmail.com
wrote:
I would like to play more with the LLVM implementation. Check out
https://github.com/ContinuumIO/numba
Cool. Is that related to the unladen
We have code printer's it would be nice to take a function and turn it
into a symbolic expression. This would allow for symbolically
exploring optimizations. Lots of publishing on this, I can find a
reference or two (John Gunnels thesis is certainly a good read).
AFAIK this is how John optimizes
I'm confused.
Are you talking about turning a python function into a sympy expression,
optimizing the sympy expression and then going back?
What's an example use case?
-Matt
On Tue, Mar 20, 2012 at 7:52 AM, Andy Ray Terrel andy.ter...@gmail.comwrote:
We have code printer's it would be nice
Isn't this just a matter of turning some variables into Symbols and
wrapping your literals in sympify() calls, so that everything comes
out symbolically?
Aaron Meurer
On Tue, Mar 20, 2012 at 9:44 AM, Matthew Rocklin mrock...@gmail.com wrote:
I'm confused.
Are you talking about turning a
The idea is interesting. You would have to consider side-effects and
other similar complications that make optimization hard for the C
compiler in the first place. For example, '*x += *y; *x += *y;' is
different from '*x += 2 * (*y)' if x and y point to the same thing.
On 03/20/2012 01:55 PM,
Yeah the idea for a first pass is to only support Static Single
Assignment codes and then iterate upon that.
-- Andy
On Tue, Mar 20, 2012 at 2:47 PM, Nikhilesh Sigatapu
s.nikhil...@gmail.com wrote:
The idea is interesting. You would have to consider side-effects and other
similar complications
Another thing to think about: how do we simplify expressions to make them
optimal for code? This is not necessarily the same as making them look
simple, which is what we currently tend to aim for in simplification
functions There's also the question of putting expressions in a form that
is
15 matches
Mail list logo