Howdy, studying the differences of PyPy vs. CPython, most seem to be fine; one thing where I an unsure is the __del__ behavior. I am not addressing its delayed call or the number it is called, this is similar to Jython and IronPython. But assigning to __del__ after a class is created, is that so hard to implement? It is clear to me that the existence of a __del__ heavily influences the whole code generation of a class. So as a naive thought, can we just abandon the whole compilation and start over (maybe even less)? The problem that I see is re-generation of already created instances, triggering some re-compilation. I would think of all compiled code always going through some "fuse code" that would trigger re-compilation if an assignment to __del__ happens. For me, this looks like a guard, that exists in other places of the JIT, where existing assumptions must check if they are still true, and otherwise start over. I have not read the current implementation, yet, because my reading is still quite impaired. But from the top of my head: Can it be that such a re-compile as I mentioned is not yet considered because that is not involving the JIT, but an already fixed part of the static compilation chain? I think not, since we are not in RPython, but at the translation of an applevel class, which is completely run-time compiled. So, where is my lack of seeing the problem? Or is it simply a lot of effort? If it is an efficiency concern, then my POV is: Better to be slow in a few cases of re-compilation, than to have to hunt for such delicate existing code. I would instead issue an optional warning to dynamic __del__ assignment instead, in order to let people avoid it in the future. regards, and thanks for correcting me - chris -- Christian Tismer :^)<mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
2011/2/5 Christian Tismer <tismer@stackless.com>:
Howdy,
studying the differences of PyPy vs. CPython, most seem to be fine; one thing where I an unsure is the __del__ behavior.
I am not addressing its delayed call or the number it is called, this is similar to Jython and IronPython.
But assigning to __del__ after a class is created, is that so hard to implement?
It's not a JIT problem rather a RPython/gc one. All the RPython classes with finalizers must be known at translation time. __del__ is expensive in the for gc. To implement user level __del__, a different underlying interp class is used which has its own __del__ which the gc will call. -- Regards, Benjamin
On 2/5/11 11:47 PM, Benjamin Peterson wrote:
2011/2/5 Christian Tismer<tismer@stackless.com>:
Howdy,
studying the differences of PyPy vs. CPython, most seem to be fine; one thing where I an unsure is the __del__ behavior.
I am not addressing its delayed call or the number it is called, this is similar to Jython and IronPython.
But assigning to __del__ after a class is created, is that so hard to implement? It's not a JIT problem rather a RPython/gc one. All the RPython classes with finalizers must be known at translation time. __del__ is expensive in the for gc. To implement user level __del__, a different underlying interp class is used which has its own __del__ which the gc will call.
I understand. Then having a __del__ is always expensive, I guess? I mean, does it involve overhead to have a __del__ at all, runtime or compile time? How feasible would it be to generate always two versions of the RPython class with a stub __del__ method, which calls a yet non-existing function? sorry if that is non-sense, but maybe something can be done to isolate these bad spots, without simply silently not calling them. cheers - chris -- Christian Tismer :^)<mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
2011/2/5 Christian Tismer <tismer@stackless.com>:
On 2/5/11 11:47 PM, Benjamin Peterson wrote:
2011/2/5 Christian Tismer<tismer@stackless.com>:
Howdy,
studying the differences of PyPy vs. CPython, most seem to be fine; one thing where I an unsure is the __del__ behavior.
I am not addressing its delayed call or the number it is called, this is similar to Jython and IronPython.
But assigning to __del__ after a class is created, is that so hard to implement?
It's not a JIT problem rather a RPython/gc one. All the RPython classes with finalizers must be known at translation time. __del__ is expensive in the for gc. To implement user level __del__, a different underlying interp class is used which has its own __del__ which the gc will call.
I understand. Then having a __del__ is always expensive, I guess? I mean, does it involve overhead to have a __del__ at all, runtime or compile time?
It just means there's a lot of runtime bookkeeping in the GC for objects with __del__.
How feasible would it be to generate always two versions of the RPython class with a stub __del__ method, which calls a yet non-existing function?
sorry if that is non-sense, but maybe something can be done to isolate these bad spots, without simply silently not calling them.
Well, you do at least get a nice warning. I don't think this is too hard to work around in apps. There's also weakrefs.
cheers - chris
-- Regards, Benjamin
On 2/6/11 12:25 AM, Benjamin Peterson wrote:
2011/2/5 Christian Tismer<tismer@stackless.com>:
On 2/5/11 11:47 PM, Benjamin Peterson wrote:
2011/2/5 Christian Tismer<tismer@stackless.com>:
Howdy,
studying the differences of PyPy vs. CPython, most seem to be fine; one thing where I an unsure is the __del__ behavior.
I am not addressing its delayed call or the number it is called, this is similar to Jython and IronPython.
But assigning to __del__ after a class is created, is that so hard to implement? It's not a JIT problem rather a RPython/gc one. All the RPython classes with finalizers must be known at translation time. __del__ is expensive in the for gc. To implement user level __del__, a different underlying interp class is used which has its own __del__ which the gc will call. I understand. Then having a __del__ is always expensive, I guess? I mean, does it involve overhead to have a __del__ at all, runtime or compile time? It just means there's a lot of runtime bookkeeping in the GC for objects with __del__.
How feasible would it be to generate always two versions of the RPython class with a stub __del__ method, which calls a yet non-existing function?
sorry if that is non-sense, but maybe something can be done to isolate these bad spots, without simply silently not calling them. Well, you do at least get a nice warning. I don't think this is too hard to work around in apps. There's also weakrefs.
Ah, we do get a warning, that is good, did not know. Anyway, the concept of RPython is pretty old, since we needed something that is treatable. And RPython is a good compromise for most things. Meanwhile, a lot of evolution has happened, most of it in the JIT area, and maybe some things can be generated more lazily and taken over by the JIT, since dynamic changes like the sudden appearance of a method could probably be handled differently than it is right now. I will shut up, this is becoming a more general topic. ciao - chris -- Christian Tismer :^)<mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
On Saturday, February 5, 2011, Christian Tismer <tismer@stackless.com> wrote:
Ah, we do get a warning, that is good, did not know.
Anyway, the concept of RPython is pretty old, since we needed something that is treatable. And RPython is a good compromise for most things.
Meanwhile, a lot of evolution has happened, most of it in the JIT area, and maybe some things can be generated more lazily and taken over by the JIT, since dynamic changes like the sudden appearance of a method could probably be handled differently than it is right now.
This is not really a JIT thing at all. The GC needs to do a lot of work for every object with a del at every collection. So giving a del to all objects would need a very different approach in the GC. Cheers, Carl Friedrich
Christianwrote:
Howdy,
studying the differences of PyPy vs. CPython, most seem to be fine; one thing where I an unsure is the __del__ behavior.
I am not addressing its delayed call or the number it is called, this is similar to Jython and IronPython.
But assigning to __del__ after a class is created, is that so hard to implement?
IronPython also doesn't handle assigning to __del__ after the class is created, and I'd be surprised if Jython did as well. To make this work we'd need to maintain a weak reference for every object of a user defined type and I think most users would rather not pay that expense for such a corner case. I've also never actually heard of this breaking compatibility anywhere. I'd say if this was really important to you then start off w/ a nop __del__. Then you can change __del_ to whatever you want later. I'm not certain that would work w/ PyPy but I'd be surprised if it didn't - it will work w/ IronPython.
On Sun, Feb 6, 2011 at 12:04 AM, Dino Viehland <dinov@microsoft.com> wrote:
Christianwrote:
Howdy,
studying the differences of PyPy vs. CPython, most seem to be fine; one thing where I an unsure is the __del__ behavior.
I am not addressing its delayed call or the number it is called, this is similar to Jython and IronPython.
But assigning to __del__ after a class is created, is that so hard to implement?
IronPython also doesn't handle assigning to __del__ after the class is created, and I'd be surprised if Jython did as well. To make this work we'd need to maintain a weak reference for every object of a user defined type and I think most users would rather not pay that expense for such a corner case. I've also never actually heard of this breaking compatibility anywhere.
I'd say if this was really important to you then start off w/ a nop __del__. Then you can change __del_ to whatever you want later. I'm not certain that would work w/ PyPy but I'd be surprised if it didn't - it will work w/ IronPython. _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
I think it'll work with pypy, *and* still trigger the warning, but that's from memory. 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
Hi Alex, On Sun, Feb 6, 2011 at 6:26 AM, Alex Gaynor <alex.gaynor@gmail.com> wrote:
Then you can change __del_ to whatever you want later.
I think it'll work with pypy, *and* still trigger the warning, but that's from memory.
Just try it out then :-) The answer is no. You get a warning only if a '__del__' entry is put in a class which didn't have one so far. Armin
participants (6)
-
Alex Gaynor -
Armin Rigo -
Benjamin Peterson -
Carl Friedrich Bolz -
Christian Tismer -
Dino Viehland