On Wed, Mar 21, 2012 at 11:27 AM, Ronan Lamy <[email protected]> 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 that Andy is suggesting more local edits - surface
>> level only. Lets just walk through the code and see what
>> simplifications we can make using SymPy that gcc couldn't know about.
>> We'll leave the actual compilation to gcc/gfortran/javac/etc....
>>
> 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 that might fail badly if the programmer actually
> dealt with floating-point pitfalls.
>
> I think we need a real-world use-case to clarify the goals.
>>
>> If we encounter something like a for loop we probably ignore it and
>> just look at what we can do to the expressions inside. We don't need
>> to understand all of the code, we're just trying to improve small
>> pieces of it.
>
> I'd guess that most useful optimisations would require moving stuff in
> and out of for loops.
Exactly. This is where things get interesting. For example, if someone has
for (i = 0; i < k; i++) {
j += i;
}
we can symbolically optimize it if we can convert it to j + Sum(i, (i,
0, k)), because the summation has a closed form, which will be far
more efficient than the loop. That's a simple example, of course, but
we can compute closed forms or partially closed forms of much more
complicated expressions. And it's something that a compiler would not
do.
>>
>> I don't think that code compilation should be a project though, I
>> think that parsing should be. I think that Andy's idea becomes
>> feasible once SymPy can read other code. Andy's idea is only one
>> possible result of this though. A good parsing module could make SymPy
>> useful in a lot of new ways.
>
> There are already lots of parsing libraries. I don't think it's a good
> idea to reinvent the wheel.
>
>> Later today I'll put code parsing on the ideas page (if someone
>> doesn't beat me to it).
>>
>> On Wed, Mar 21, 2012 at 2:26 AM, Joachim Durchholz <[email protected]>
>> wrote:
>> 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 from
>> symbolics to code, it
>> seems easy to do simple things in the other
>> directions.
>>
>>
>> Real (non-toy) code contains extra stuff for handling error
>> conditions, optimizing memory usage, etc.
>> Extracting the real logic from all that sounds like it would
>> be really, really hard.
>>
>> The other question is: what do you want to optimize for?
>> Space? Time? Code size?
>> What's your execution model - number of subroutine calls?
>> Number of operator calls? How do you estimate the number of
>> rounds spent in a loop (or the depth of a recursive call)? How
>> do you estimate the size of data structures created? How do
>> you determine how long some data structure will live?
>>
>> Not all of the questions are relevant for all optimization
>> goals.
>> This is going to be a good GSoC project if a goal is found
>> that does not require answers to the ultra-hard questions. So
>> the project should not be "optimize C functions" (that's a
>> task for multiple lifetimes), but something more specific.
>> With an implementation strategy, and an eye towards why this
>> isn't going to require solving the halting problem or
>> similarly hard things.
>>
>>
>> > I realize
>> this isn't super well formed but after seeing a number
>> of these
>> symbolic executor papers, I think it is probably a
>> good way to go.
>>
>>
>> I haven't seen these papers. If they pick specific things that
>> don't require doing hard stuff, this could be fun.
>> Extra points if it is going to make SymPy more useful.
>>
>>
>>
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
