On Thu, Feb 3, 2011 at 11:56 AM, Fredrik Johansson <fredrik.johansson@gmail.com> wrote:
On Thu, Feb 3, 2011 at 8:01 AM, Maciej Fijalkowski <fijall@gmail.com> wrote:
On Thu, Feb 3, 2011 at 1:43 AM, Fredrik Johansson <fredrik.johansson@gmail.com> wrote:
On Thu, Feb 3, 2011 at 12:32 AM, Alex Gaynor <alex.gaynor@gmail.com> wrote:
If you have any benchmarks where we are slower that don't involve longs that'd be great, since for float operations we really should be able to beat up on CPython.
A simple example: mpmath.fp.fsum(mpmath.fp.sqrt(k) for k in xrange(1000000))
A brief follow up.
* PyPy trunk is faster (by quite a bit).
* I noticed that you happily use mixture of old and new style classes. As of now this is a really bad case for PyPy. Example:
[isinstance(i, type) for i in mpmath.fp.__class__.__mro__] [True, True, True, True, False, False, True, True, False, True, True, True, True, True, True]
when I replace it with newstyle classes it runs much faster
Interesting. The mixture of old and new style classes is a mistake, of course. I'm going to add a test to make sure this doesn't happen. Thanks for pointing it out.
In fact this speeds up another benchmark I did -- [fp.lambertw(k) for k in xrange(50000)]-- by 10x, which is quite a ridiculous ratio!
Mixture of old and new style classes is not only preventing us from doing optimizations but also hits a bad case of tradeoffs. However, we decided we don't care that much. You should use new style classes anyway :)
Other things that speed up both CPython and PyPy:
* Put this things into function instead of at global scope
Do you mean in the benchmark or did you have some other code you saw in mind?
The benchmark.
* Use list comprehension instead of generator expression.
I hope PyPy can do more in the future to speed up generator expressions.
It doesn't speed up things by much. Yeah, I can imagine we can improve on this, but it's also a bit hard.
Fredrik