[PEAK] Fwd: Adding C generation to bytecode assembler

[Michel Pelletier]

On 8/20/06, Phillip J. Eby <pje at telecommunity.com> wrote:

>My initial crude benchmark results are good, simple loops with math ops
> >have a 2x increase in speed, with nested loops gaining even more.  This
> is
> >without any stack movement reduction yet, so once I implement that I
> think
> >the performance will jump even more.
>
> I'm impressed, but also very surprised.  I'd really like to see what it is
> that you're doing, because given the goals and steps that you laid out, I
> wouldn't have expected such a big improvement in performance without at
> least some inlining or type inference.  In fact, I'm impressed that you
> got
> any improvements at all; the C interpreter has previously been shown not
> to
> really *have* that much overhead.  If you're doing this while generating
> reasonably readable C code (i.e. at least as good as Pyrex's) then I'm in
> absolute awe.


I think my loop with a few math ops is sufficiently contrived enough that it
can't be considered a very reliable benchmark of what's to come or much
insperation for awe. ;)  I actually expect a speedup benefit to happen only
in certain cases, I suspect most functions would not benefit enough or at
all to even bother.  But I'm suprised you don't think the inner interpreter
or the stack movement has much overhead, that seems to be pretty low hanging
fruit to me but the future could prove me dead wrong. I remember one or two
threads specifically on this subject on python-dev, but I don't remember
much actual measurement being conclusively shown at the time to prove it one
way or another.

I've not studied a lot of Pyrex's output, but some through a few trials.  I
would be suprised and suspect of my own results if Pyrex didn't generate
faster code than I have here, although I don't think Pyrex is as readable,
it's certainly more mature and probably the closest project in terms of
goals.  I think my experiment is much simpler than Pyrex though, not having
to maintain a language parser or complex code generator or deal with some of
the restrictions Pyrex has.  One of my main goals is to maintain 100%
interpreter compatibility.

-Michel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eby-sarna.com/pipermail/peak/attachments/20060820/628f1286/attachment.html