running the test suite of this package might be useful. Laura ------- Forwarded Message Return-Path: python-announce-list-bounces+lac=openend.se@python.org Delivery-Date: Wed Feb 2 00:29:19 2011 Return-Path: <python-announce-list-bounces+lac=openend.se@python.org> Received: from mail.python.org (mail.python.org [82.94.164.166]) by theraft.openend.se (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p11NTCgZ009584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <lac@openend.se>; Wed, 2 Feb 2011 00:29:14 +0100 Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 1089FEE9C0 for <lac@openend.se>; Wed, 2 Feb 2011 00:29:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1296602952; bh=SjeURYFJ0JANVg28+rd+7SNHYu2uW4+khr521TTR24c=; h=MIME-Version:Date:Message-ID:Subject:From:To:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=u3Vd1rser4Yn6sV8mw8GsXc9yRHbfI8ct22qpxaml8r0lxcbKfbHnjjLVdST1kZY3 0MKS5mryz3ElA42r6P3S60hM+tWW0uz4xFk2AVUCrIeWt3+tpHWgYx3oXKHdTtdKRN ZgYWWK3rX3RoCiBOhAKDddtq25GWXs4jg2p75OVc= X-Original-To: python-announce-list@python.org Delivered-To: python-announce-list@mail.python.org Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 51C0CEE9B8 for <python-announce-list@python.org>; Tue, 1 Feb 2011 23:11:46 +0100 (CET) X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'bug': 0.02; 'subject:ANN': 0.02; 'subject:Python': 0.05; '2.x': 0.05; 'implements': 0.05; 'library': 0.06; '3.x': 0.07; 'derivatives': 0.07; 'tracker': 0.07; 'url:googlecode': 0.07; 'python': 0.08; 'url:pypi': 0.08; 'arithmetic': 0.09; 'url:code': 0.15; '0.17': 0.16; 'codebase,': 0.16; 'subject:0.17': 0.16; 'url:changes': 0.16; 'url:issues': 0.16; 'url:svn': 0.16; 'url:trunk': 0.16; 'downloaded': 0.17; 'url:doc': 0.19; '2.4': 0.23; 'version': 0.24; 'url:group': 0.25; 'function': 0.27; 'functions.': 0.28; 'project': 0.29; 'message- id:@mail.gmail.com': 0.29; 'url:)': 0.29; 'thanks': 0.30; 'dropped': 0.30; 'standalone': 0.30; 'all,': 0.30; 'contributed': 0.31; 'requires': 0.33; 'version.': 0.34; 'url:google': 0.34; '2.5': 0.36; 'mathematical': 0.36; 'to:addr:python-announce-list': 0.36; 'used': 0.36; 'set': 0.37; 'list:': 0.37; 'works': 0.38; 'received:209.85': 0.38; 'received:google.com': 0.38; 'zero': 0.38; 'url:org': 0.38; 'subject:: ': 0.39; 'url:python': 0.39; 'to:addr:python.org': 0.40; 'comments': 0.40; 'url:p': 0.60; 'to:2**2': 0.64; 'url:0': 0.64; 'details,': 0.65; 'website:': 0.71; 'to:no real name:2**2': 0.75; 'url:17': 0.76; 'news': 0.78; 'fredrik': 0.91 Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 01 Feb 2011 23:11:46 +0100 Received: from mail-qw0-f46.google.com (mail-qw0-f46.google.com [209.85.216.46]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.python.org (Postfix) with ESMTPS for <python-announce-list@python.org>; Tue, 1 Feb 2011 23:11:45 +0100 (CET) Received: by qwa26 with SMTP id 26so7212791qwa.19 for <python-announce-list@python.org>; Tue, 01 Feb 2011 14:11:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=6yZ49a5xiXwaVsySNvnihUrvwjNRAycqDeQTj98mFN4=; b=TFkhQdC5AeC7EecRVy8bO+ZVjyDOniTJB9u5S4BVnuXSAIAa8U58xnIPqCNAEojT5M 2bA2NizGpC/zHNyQLa/yu92nhY85wb2Wv5FW72QkL9kklUpzkYFZp4/vi4nidCwFoA2R 7qa0fa3fksMnYLpIyfOE5Vv0NeyWrZKmxt/Jc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qdEow0h50/OGUU89qp7muEE5FACELAhcuIpeNUeeV8srLOc4roz/kZHOS7NooIktaG 8lMo4dIEgm6aPAqeAxssYBAiQ5YDk/k0YxSsZovPJFV1incJEWpc9HIuuS9922zQUHeW J9J1GUwfUr/2QjPYed8ZCEQJkzSyAaSvGNFpI= MIME-Version: 1.0 Received: by 10.229.236.134 with SMTP id kk6mr7177714qcb.93.1296598304793; Tue, 01 Feb 2011 14:11:44 -0800 (PST) Received: by 10.229.245.209 with HTTP; Tue, 1 Feb 2011 14:11:44 -0800 (PST) Date: Tue, 1 Feb 2011 23:11:44 +0100 Message-ID: <AANLkTinnjWyQ3U0MYMRn7+dmRVtwUAmpPrZZiz7QDt_=@mail.gmail.com> Subject: ANN: mpmath 0.17 (Python 3 support and more) From: Fredrik Johansson <fredrik.johansson@gmail.com> To: mpmath@googlegroups.com, sympy@googlegroups.com, sage-devel@googlegroups.com, python-announce-list@python.org X-Mailman-Approved-At: Wed, 02 Feb 2011 00:22:14 +0100 X-BeenThere: python-announce-list@python.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: python-list@python.org List-Id: Announcement-only list for the Python programming language <python-announce-list.python.org> List-Unsubscribe: <http://mail.python.org/mailman/options/python-announce-list>, <mailto:python-announce-list-request@python.org?subject=unsubscribe> List-Archive: <http://mail.python.org/pipermail/python-announce-list> List-Post: <mailto:python-announce-list@python.org> List-Help: <mailto:python-announce-list-request@python.org?subject=help> List-Subscribe: <http://mail.python.org/mailman/listinfo/python-announce-list>, <mailto:python-announce-list-request@python.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: python-announce-list-bounces+lac=openend.se@python.org Errors-To: python-announce-list-bounces+lac=openend.se@python.org X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-3.0 (theraft.openend.se [83.140.78.130]); Wed, 02 Feb 2011 00:29:14 +0100 (CET) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Feb 2 00:29:19 2011 X-DSPAM-Confidence: 0.9994 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 1004,4d48974f95865701517258 Hi all, Version 0.17 of mpmath is now available on the project website: http://code.google.com/p/mpmath/ It can also be downloaded from the Python Package Index: http://pypi.python.org/pypi/mpmath/0.17 Mpmath is a pure-Python library for arbitrary-precision floating-point arithmetic that implements an extensive set of mathematical functions. It can be used as a standalone library or via SymPy (http://code.google.com/p/sympy/), and is also available as a standard component of Sage (http://sagemath.org/). The major news in 0.17 is that mpmath now works with Python 3. To support both Python 2.x and 3.x with the same codebase, compatibility with Python 2.4 has been dropped (mpmath now requires 2.5 or higher). New functionality in mpmath 0.17 includes an implementation of the Lerch transcendent, Riemann zeta zero counting, and improved support for evaluating derivatives of the Hurwitz zeta function and related functions. Many thanks to Juan Arias de Reyna and Case Vanhorsen who contributed to this version. For more details, see the changelog: http://mpmath.googlecode.com/svn/tags/0.17/CHANGES Extensive documentation is available at: http://mpmath.googlecode.com/svn/trunk/doc/build/index.html or http://mpmath.googlecode.com/svn/tags/0.17/doc/build/index.html Bug reports and other comments are welcome on the issue tracker at http://code.google.com/p/mpmath/issues/list or the mpmath mailing list: http://groups.google.com/group/mpmath Enjoy, Fredrik Johansson - -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/ ------- End of Forwarded Message
Hi, 2011/2/2 Laura Creighton <lac@openend.se>:
running the test suite of this package might be useful.
Some user already tried it one year ago, this even triggered two bugs in the early version of the JIT: http://codespeak.net/pipermail/pypy-dev/2010q1/005722.html I don't remember how fast is was, though. -- Amaury Forgeot d'Arc
Hello, On Wed, Feb 2, 2011 at 1:02 AM, Amaury Forgeot d'Arc <amauryfa@gmail.com> wrote:
Hi,
2011/2/2 Laura Creighton <lac@openend.se>:
running the test suite of this package might be useful.
Some user already tried it one year ago, this even triggered two bugs in the early version of the JIT: http://codespeak.net/pipermail/pypy-dev/2010q1/005722.html
Indeed (that user was me, and it was nice to see the problem fixed so quickly!). There is one incompatibility left between CPython and PyPy that breaks some functions in mpmath. In CPython, round() and functions in the math module accept (and convert) inputs of any custom type with a __float__ method, whereas they trigger a TypeError in PyPy (1.4).
I don't remember how fast is was, though.
On win32, PyPy 1.4 is about 40% slower than CPython 2.6 for running the entire set of tests. This is probably mostly due to the slowness of longs in PyPy. However, much of the regular floating point code seems to be slower in PyPy as well. Fredrik
2011/2/3 Fredrik Johansson <fredrik.johansson@gmail.com>:
Indeed (that user was me, and it was nice to see the problem fixed so quickly!). There is one incompatibility left between CPython and PyPy that breaks some functions in mpmath. In CPython, round() and functions in the math module accept (and convert) inputs of any custom type with a __float__ method, whereas they trigger a TypeError in PyPy (1.4).
It seems corrected today; the script below indeed fails with pypy-1.4.
class C: .... def __float__(self): return 42.0 .... x = C() import math math.sqrt(x) 6.48074069840786
I don't remember how fast is was, though.
On win32, PyPy 1.4 is about 40% slower than CPython 2.6 for running the entire set of tests. This is probably mostly due to the slowness of longs in PyPy. However, much of the regular floating point code seems to be slower in PyPy as well.
The standard operations, or the math module? It seems that every function in the math module releases the GIL. This may explain some slowness. -- Amaury Forgeot d'Arc
On Thu, Feb 3, 2011 at 00:10, Amaury Forgeot d'Arc <amauryfa@gmail.com> wrote:
2011/2/3 Fredrik Johansson <fredrik.johansson@gmail.com>:
Indeed (that user was me, and it was nice to see the problem fixed so quickly!). There is one incompatibility left between CPython and PyPy that breaks some functions in mpmath. In CPython, round() and functions in the math module accept (and convert) inputs of any custom type with a __float__ method, whereas they trigger a TypeError in PyPy (1.4).
It seems corrected today; the script below indeed fails with pypy-1.4. According to Fredik, the script is supposed to pass. By "corrected" you mean it's fixed on the trunk?
class C: .... def __float__(self): return 42.0 .... x = C() import math math.sqrt(x) 6.48074069840786
I don't remember how fast is was, though.
On win32, PyPy 1.4 is about 40% slower than CPython 2.6 for running the entire set of tests. This is probably mostly due to the slowness of longs in PyPy. However, much of the regular floating point code seems to be slower in PyPy as well.
The standard operations, or the math module?
It seems that every function in the math module releases the GIL. Does that module live in pypy/module/math/? Reading the source doesn't show obvious interactions with the GIL, so I guess that for many other modules the GIL is released automatically, potentially even for other fast functions.
This may explain some slowness. In other words, a simple call to sin()/cos()/ceil() triggers a cache flush (costing around ~100 cycles) because of releasing a lock, if not a system call (costing thousands of cycles), say if the lock was contended? If those functions were lifted to operate on lists they should release the lock for long lists, otherwise it seems a bad idea.
In other words, I'd propose to remove the unlocking/relocking if possible. Can that affect correctness for some weird reason? I'd guess not, but I'm not familiar with the code enough to get fully what happens. Best regards -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/
2011/2/3 Paolo Giarrusso <pgiarrusso@mathematik.uni-marburg.de>:
It seems that every function in the math module releases the GIL. Does that module live in pypy/module/math/? Reading the source doesn't show obvious interactions with the GIL, so I guess that for many other modules the GIL is released automatically, potentially even for other fast functions.
Fortunately, I was wrong, sorry. The functions of the math module don't release the GIL. The low-level operations are in pypy/rpython/lltypesystem/module/ll_math.py, all functions are marked with "sandboxsafe=True" which, according to a comment in rffi.py, ensures that the GIL won't be released. -- Amaury Forgeot d'Arc
On Thu, Feb 3, 2011 at 12:10 AM, Amaury Forgeot d'Arc <amauryfa@gmail.com> wrote:
2011/2/3 Fredrik Johansson <fredrik.johansson@gmail.com>:
Indeed (that user was me, and it was nice to see the problem fixed so quickly!). There is one incompatibility left between CPython and PyPy that breaks some functions in mpmath. In CPython, round() and functions in the math module accept (and convert) inputs of any custom type with a __float__ method, whereas they trigger a TypeError in PyPy (1.4).
It seems corrected today; the script below indeed fails with pypy-1.4.
Ah, that's nice. Does round() work as well?
On win32, PyPy 1.4 is about 40% slower than CPython 2.6 for running the entire set of tests. This is probably mostly due to the slowness of longs in PyPy. However, much of the regular floating point code seems to be slower in PyPy as well.
The standard operations, or the math module? It seems that every function in the math module releases the GIL. This may explain some slowness.
I have only looked at some quick macro level timings. Generally a lot of overhead for function calls and type checking is involved (although I would hope that PyPy can kill precisely some of that eventually). Fredrik
On Wed, Feb 2, 2011 at 6:29 PM, Fredrik Johansson < fredrik.johansson@gmail.com> wrote:
On Thu, Feb 3, 2011 at 12:10 AM, Amaury Forgeot d'Arc <amauryfa@gmail.com> wrote:
2011/2/3 Fredrik Johansson <fredrik.johansson@gmail.com>:
Indeed (that user was me, and it was nice to see the problem fixed so quickly!). There is one incompatibility left between CPython and PyPy that breaks some functions in mpmath. In CPython, round() and functions in the math module accept (and convert) inputs of any custom type with a __float__ method, whereas they trigger a TypeError in PyPy (1.4).
It seems corrected today; the script below indeed fails with pypy-1.4.
Ah, that's nice. Does round() work as well?
On win32, PyPy 1.4 is about 40% slower than CPython 2.6 for running the entire set of tests. This is probably mostly due to the slowness of longs in PyPy. However, much of the regular floating point code seems to be slower in PyPy as well.
The standard operations, or the math module? It seems that every function in the math module releases the GIL. This may explain some slowness.
I have only looked at some quick macro level timings. Generally a lot of overhead for function calls and type checking is involved (although I would hope that PyPy can kill precisely some of that eventually).
Fredrik _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
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. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero
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)) PyPy 1.4 runs this about 2.4 times slower than CPython. Fredrik
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 Other things that speed up both CPython and PyPy: * Put this things into function instead of at global scope * Use list comprehension instead of generator expression. That all should make PyPy 3x faster than CPython.
PyPy 1.4 runs this about 2.4 times slower than CPython.
Fredrik _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
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!
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?
* Use list comprehension instead of generator expression.
I hope PyPy can do more in the future to speed up generator expressions. Fredrik
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
On Thu, Feb 3, 2011 at 11:14 AM, Maciej Fijalkowski <fijall@gmail.com> wrote:
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 :)
Yes, this is perfectly reasonable. You should make PyPy print warnings when it encounters mixed-type classes :) Fredrik
On Thu, Feb 3, 2011 at 12:23 PM, Fredrik Johansson <fredrik.johansson@gmail.com> wrote:
On Thu, Feb 3, 2011 at 11:14 AM, Maciej Fijalkowski <fijall@gmail.com> wrote:
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 :)
Yes, this is perfectly reasonable. You should make PyPy print warnings when it encounters mixed-type classes :)
Fredrik
That's not a bad idea actually. Maybe with something like some -X option?
2011/2/3 Maciej Fijalkowski <fijall@gmail.com>:
You should make PyPy print warnings
when it encounters mixed-type classes :)
That's not a bad idea actually. Maybe with something like some -X option?
If we use the warnings module to emit JitWarnings, the option could be -Wd::JitWarning -- Amaury Forgeot d'Arc
On Thu, Feb 3, 2011 at 2:10 PM, Amaury Forgeot d'Arc <amauryfa@gmail.com> wrote:
2011/2/3 Maciej Fijalkowski <fijall@gmail.com>:
You should make PyPy print warnings
when it encounters mixed-type classes :)
That's not a bad idea actually. Maybe with something like some -X option?
If we use the warnings module to emit JitWarnings, the option could be -Wd::JitWarning
I'm not sure about warnings module. How about --jit warnings=1 ? That would fit with other jit options. I was more thinking about this being optional
-- Amaury Forgeot d'Arc
On 03/02/11 13:13, Maciej Fijalkowski wrote:
I'm not sure about warnings module. How about --jit warnings=1 ?
That would fit with other jit options.
not really. The other jit options really belongs to the JIT engine, while this one is dependent on the Python interpreter ciao, Anto
On Thu, Feb 3, 2011 at 2:21 PM, Antonio Cuni <anto.cuni@gmail.com> wrote:
On 03/02/11 13:13, Maciej Fijalkowski wrote:
I'm not sure about warnings module. How about --jit warnings=1 ?
That would fit with other jit options.
not really. The other jit options really belongs to the JIT engine, while this one is dependent on the Python interpreter
true.
ciao, Anto
Maciej Fijalkowski, 03.02.2011 11:14:
On Thu, Feb 3, 2011 at 11:56 AM, Fredrik Johansson wrote:
On Thu, Feb 3, 2011 at 8:01 AM, Maciej Fijalkowski wrote:
* 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.
Does PyPy generate inlined looping code for them if applicable? (e.g. for any(), all(), sum(), sorted(), ...) Stefan
On Thu, Feb 3, 2011 at 11:15 AM, Stefan Behnel <stefan_ml@behnel.de> wrote:
Maciej Fijalkowski, 03.02.2011 11:14:
On Thu, Feb 3, 2011 at 11:56 AM, Fredrik Johansson wrote:
On Thu, Feb 3, 2011 at 8:01 AM, Maciej Fijalkowski wrote:
* 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.
Does PyPy generate inlined looping code for them if applicable?
(e.g. for any(), all(), sum(), sorted(), ...)
Stefan
_______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
No, it does not (with the exception of map() which has its own JIT, but that code is still not inlined into the caller). Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero
On Thu, Feb 3, 2011 at 6:15 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:
Maciej Fijalkowski, 03.02.2011 11:14:
On Thu, Feb 3, 2011 at 11:56 AM, Fredrik Johansson wrote:
On Thu, Feb 3, 2011 at 8:01 AM, Maciej Fijalkowski wrote:
* 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.
Does PyPy generate inlined looping code for them if applicable?
(e.g. for any(), all(), sum(), sorted(), ...)
We don't inline generator expr. The reason is that it's hard to judge when generator frame escapes. We can probably do something with it, but it's not done yet.
Stefan
_______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
participants (8)
-
Alex Gaynor -
Amaury Forgeot d'Arc -
Antonio Cuni -
Fredrik Johansson -
Laura Creighton -
Maciej Fijalkowski -
Paolo Giarrusso -
Stefan Behnel