Re: [pypy-dev] Support for __getitem__ in rpython?
Hi Hakan, On Mon, Dec 15, 2008 at 08:47:26PM +0100, Hakan Ardo wrote: cannot yet handle that the methods return NotImplemented. Would it be possible to handle that in a similar manner to how None is handled? Not easily. The annotation framework of PyPy was never meant to handle the full Python language, but only a subset reasonable for writing interpreters. Anyway, None-or-integer is not supported either, simply because there is no way to represent that in a single machine word. A bientot, Armin. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Support for __getitem__ in rpython?
On Tue, Dec 23, 2008 at 12:23, Armin Rigo ar...@tunes.org wrote: Hi Hakan, On Mon, Dec 15, 2008 at 08:47:26PM +0100, Hakan Ardo wrote: cannot yet handle that the methods return NotImplemented. Would it be possible to handle that in a similar manner to how None is handled? Not easily. The annotation framework of PyPy was never meant to handle the full Python language, but only a subset reasonable for writing interpreters. Anyway, None-or-integer is not supported either, simply because there is no way to represent that in a single machine word. There are at least two ways, once you have a singleton (maybe static) None object around: - box all integers and use only pointers - the slow one; - tagged integers/pointers that you already use elsewhere. So integers of up to 31/63 bits get represented directly, while the other ones are through pointers. -- Paolo Giarrusso ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Support for __getitem__ in rpython?
Hi Paolo, On Tue, Dec 23, 2008 at 12:29:01PM +0100, Paolo Giarrusso wrote: There are at least two ways, once you have a singleton (maybe static) None object around: - box all integers and use only pointers - the slow one; - tagged integers/pointers that you already use elsewhere. So integers of up to 31/63 bits get represented directly, while the other ones are through pointers. Yes, we're using both ways, but for app-level integers, not for regular RPython-level integers. That would be a major slow-down. A bientot, Armin. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Threaded interpretation (was: Re: compiler optimizations: collecting ideas)
Hi Paolo, Just a quick note as an answer to your long and detailed e-mail (thanks for it, btw). On the whole you're making quite some efforts to get Python fast, starting with a subset of Python and adding feature after feature until it is more or less complete, while benchmarking at every step. This is not a new approach: it has been tried before for Python. Usually, this kind of project ends up being not used and forgotten, because it's only 80% or 90% compatible but not 99% -- and people care much more, on average, about 99% compatibility than about 50% performance improvement. PyPy on the other hand starts from the path of 99% compatibility and then tries to improve performance (which started as 1 times slower... and is now roughly 1.5 or 2 times slower). Just saying that the approach is completely different... And I have not much interest in it -- because you change the language and have to start again from scratch. A strong point of PyPy is that you don't have to; e.g. we have, in addition to the Python interpreter, a JavaScript, a Smalltalk, etc... A bientot, Armin. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Support for __getitem__ in rpython?
Paolo Giarrusso wrote: There are at least two ways, once you have a singleton (maybe static) None object around: - box all integers and use only pointers - the slow one; - tagged integers/pointers that you already use elsewhere. So integers of up to 31/63 bits get represented directly, while the other ones are through pointers. I think you are confusing level: here we are talking about RPython, i.e. the language which our Python interpreter is implemented in. Hence, RPython ints are really like C ints, and you don't want to manipulate C ints as tagged pointer, do you? ciao, Anto ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
