[pypy-dev] Question on the future of RPython

[René Dudfield]

Hi,

on the topic of optimizations, since I should get these out of my
brain, but you probably don't want them in yours... but I'll write
them anyway.

Considered Duffs device for loop unwinding?  For dividing the number
of loop counter ++ calls by 8 times or more:
http://en.wikipedia.org/wiki/Duff%27s_Device  I'm guessing pypy
already does this or something better.

Outputting gcc extensions, and pragmas, for example using
__builtin_expect to help branch prediction:
#define likely(x)       __builtin_expect((x),1)
#define unlikely(x)     __builtin_expect((x),0)

As well as rectrict to tell it about pointer aliasing?
http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Restricted-Pointers.html


Also, have you considered using PREFETCH* (or gccs __builtin_prefetch)
instructions when you are iterating over sequences?  It might be a win
If you know there is some memory coming, and can slip in some of these
instructions, it's usually a win.
    http://gcc.gnu.org/projects/prefetch.html

__builtin_constant_p for constant detection?

SSE2 optimized hash functions?  It seems this is a big speedup for
interpreters when the hash function is sped up... I guess pypy already
uses an inline cache, but I hope it would still speed things up.



... almost deleted this email, since I hate suggesting things that
people might like to work on... but I didn't. oops, sorry.



On Thu, Sep 30, 2010 at 1:01 PM, Armin Rigo <arigo at tunes.org> wrote:
>
> Hi Paolo,
>
> On Thu, Sep 30, 2010 at 8:33 AM, Paolo Giarrusso <p.giarrusso at gmail.com> wrote:
> > My proposal, here, would be a "virtual guard", (...)
>
> Yes, this proposal makes sense.  It's an optimization that is
> definitely done in regular JITs, and we have a "to-do" task about it
> in http://codespeak.net/svn/pypy/extradoc/planning/jit.txt (where they
> are called "out-of-line guards").
>
>
> Armin.
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev