In a message of Tue, 16 Sep 2003 13:46:26 +0200, holger krekel writes:
[Dinu Gherman Tue, Sep 16, 2003 at 01:24:12PM +0200]
I forgot to mention: if you really want EU money, you should, under all circumstances, find a good explanation for how PyPy only can fuel the world's most sophisticated future E-Government platforms!
No joke! Combine this with the mobile devices I mentioned before! ;-)
And here we should mention Zope (and it's speed problems :-). Maybe we/i can get some prominent Zope-developers to state that PyPy could help Zope etc. At least in germany government agencies are using Zope a lot ... What do you think?
cheers,
holger
Good idea. I will ask Paul Everitt as well. Laura
Laura Creighton wrote:
In a message of Tue, 16 Sep 2003 13:46:26 +0200, holger krekel writes:
[Zope speed]
Good idea. I will ask Paul Everitt as well.
Absolutely! Zope would not only become much faster, but could also get rid of *all its C extensions* (which are not too many, btw). -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : 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 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
On Tuesday, Sep 16, 2003, at 09:20 America/New_York, Christian Tismer wrote:
Laura Creighton wrote:
In a message of Tue, 16 Sep 2003 13:46:26 +0200, holger krekel writes:
[Zope speed]
Good idea. I will ask Paul Everitt as well.
Absolutely! Zope would not only become much faster, but could also get rid of *all its C extensions* (which are not too many, btw).
Does Zope really need any C extensions to do what it needs to do (not considering performance) if they were allowed to use new style classes? I was under the impression that the C extension(s) in Zope were developed to get around some of the shortfalls of the old class system, and was part of the reason for type/class unification? -bob
Bob Ippolito wrote:
On Tuesday, Sep 16, 2003, at 09:20 America/New_York, Christian Tismer wrote:
...
Zope would not only become much faster, but could also get rid of *all its C extensions* (which are not too many, btw).
Does Zope really need any C extensions to do what it needs to do (not considering performance) if they were allowed to use new style classes? I was under the impression that the C extension(s) in Zope were developed to get around some of the shortfalls of the old class system, and was part of the reason for type/class unification?
Well, I think they should be able to trash ExtensionClass, but they have a bit more: D:\pypy\trunk\doc\funding>dir D:\Zope-2.7.0-b2\lib\python\*.pyd Datenträger in Laufwerk D: ist Daten Datenträgernummer: 8838-4458 Verzeichnis von D:\Zope-2.7.0-b2\lib\python 26.08.2003 14:36 28,672 Acquisition.pyd 26.08.2003 14:36 28,672 BTree.pyd 26.08.2003 14:36 20,480 ComputedAttribute.pyd 26.08.2003 14:36 61,440 ExtensionClass.pyd 26.08.2003 14:36 28,672 IIBTree.pyd 26.08.2003 14:37 20,480 initgroups.pyd 26.08.2003 14:36 20,480 intSet.pyd 26.08.2003 14:36 28,672 IOBTree.pyd 26.08.2003 14:36 20,480 MethodObject.pyd 26.08.2003 14:36 20,480 Missing.pyd 26.08.2003 14:36 20,480 MultiMapping.pyd 26.08.2003 14:36 28,672 OIBTree.pyd 26.08.2003 14:36 20,480 Record.pyd 26.08.2003 14:36 20,480 ThreadLock.pyd 14 Datei(en) 368,640 Bytes 0 Verzeichnis(se), 267,665,408 Bytes frei ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : 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 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
[Christian Tismer Tue, Sep 16, 2003 at 05:02:24PM +0200]
26.08.2003 14:36 28,672 Acquisition.pyd 26.08.2003 14:36 28,672 BTree.pyd 26.08.2003 14:36 20,480 ComputedAttribute.pyd 26.08.2003 14:36 61,440 ExtensionClass.pyd 26.08.2003 14:36 28,672 IIBTree.pyd 26.08.2003 14:37 20,480 initgroups.pyd 26.08.2003 14:36 20,480 intSet.pyd 26.08.2003 14:36 28,672 IOBTree.pyd 26.08.2003 14:36 20,480 MethodObject.pyd 26.08.2003 14:36 20,480 Missing.pyd 26.08.2003 14:36 20,480 MultiMapping.pyd 26.08.2003 14:36 28,672 OIBTree.pyd 26.08.2003 14:36 20,480 Record.pyd 26.08.2003 14:36 20,480 ThreadLock.pyd
btw, i forgot all about it: this is mainly the Zope-Database (ZODB) which is independent from Zope and has quite some parts written in C, for performance reasons ASFAIK. I'd say they are applying a common technique with high-level-languages: rapidly prototype in Python and reimplement the speed-relevant parts in C (and maintain it). It's rather obvious how PyPy could help here :-) holger
holger krekel wrote:
[Christian Tismer Tue, Sep 16, 2003 at 05:02:24PM +0200]
[many more binaries than expected]
btw, i forgot all about it: this is mainly the Zope-Database (ZODB) which is independent from Zope and has quite some parts written in C, for performance reasons ASFAIK. I'd say they are applying a common technique with high-level-languages: rapidly prototype in Python and reimplement the speed-relevant parts in C (and maintain it). It's rather obvious how PyPy could help here :-)
Absolutely. Zope can reverse its path and move its core back to where it belongs: Python. This is what is going to happen if we really get the project funded, and a few of us might work almost fulltime on PyPy: All C extensions can probably envision their death, sooner or later. And this is such a huge achievement, since the amount of man hours saved in the future is countable infinite. :-) Probably a selling argument which should get into pypy-funding... ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : 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 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
On Tue, 2003-09-16 at 11:46, Christian Tismer wrote:
[many more binaries than expected]
btw, i forgot all about it: this is mainly the Zope-Database (ZODB) which is independent from Zope and has quite some parts written in C, for performance reasons ASFAIK. I'd say they are applying a common technique with high-level-languages: rapidly prototype in Python and reimplement the speed-relevant parts in C (and maintain it). It's rather obvious how PyPy could help here :-)
Absolutely. Zope can reverse its path and move its core back to where it belongs: Python.
In fact, Zope3 started with all Python implements of ZODB. A few parts of it have been rewritten in C over time. Performance is the main goal, but another noteworthy reason to use C is to reduce memory usage. Pure Python objects consume a lot of memory. C extension types can be fairly small. (datetime is a good example.) Does pypy have a plan for memory or is performance the primary goal? Jeremy
[Jeremy Hylton Tue, Sep 23, 2003 at 09:50:59PM -0400]
On Tue, 2003-09-16 at 11:46, Christian Tismer wrote:
[many more binaries than expected]
btw, i forgot all about it: this is mainly the Zope-Database (ZODB) which is independent from Zope and has quite some parts written in C, for performance reasons ASFAIK. I'd say they are applying a common technique with high-level-languages: rapidly prototype in Python and reimplement the speed-relevant parts in C (and maintain it). It's rather obvious how PyPy could help here :-)
Absolutely. Zope can reverse its path and move its core back to where it belongs: Python.
In fact, Zope3 started with all Python implements of ZODB. A few parts of it have been rewritten in C over time. Performance is the main goal, but another noteworthy reason to use C is to reduce memory usage. Pure Python objects consume a lot of memory. C extension types can be fairly small. (datetime is a good example.)
Does pypy have a plan for memory or is performance the primary goal?
allowing to have a small memory footprint is certainly a goal. PyPy aims to make it a lot easier to make decisions regarding space<->time tradeoffs. So Zope3 could e.g. use their own completely compliant python interpreter optimized for memory consumption. Do the parts of Zope3 that got rewritten in C still have a complete python counterpart? Do the unit-tests run on both of them? cheers, holger
On Wed, 2003-09-24 at 02:41, holger krekel wrote:
[Jeremy Hylton Tue, Sep 23, 2003 at 09:50:59PM -0400]
In fact, Zope3 started with all Python implements of ZODB. A few parts of it have been rewritten in C over time. Performance is the main goal, but another noteworthy reason to use C is to reduce memory usage. Pure Python objects consume a lot of memory. C extension types can be fairly small. (datetime is a good example.)
Does pypy have a plan for memory or is performance the primary goal?
allowing to have a small memory footprint is certainly a goal. PyPy aims to make it a lot easier to make decisions regarding space<->time tradeoffs. So Zope3 could e.g. use their own completely compliant python interpreter optimized for memory consumption.
Do the parts of Zope3 that got rewritten in C still have a complete python counterpart? Do the unit-tests run on both of them?
ZODB4 has very little C code and most of it is also available in Python. There is a timestamp that was implemented in C from the get-go, but it would be trivial to rewrite in Python. The tests used to run with only Python code, but no one has run the tests that way for a long time. I think Zope3 has more C code without a Python counterpart. There are several extensions that started in Python, migrated to C, then evolved. So I wouldn't expect Zope to be straightforward, but the ZODB kernel should be. Jeremy
On Thu, 2003-09-25 at 08:20, Paolo Invernizzi wrote:
Jeremy Hylton wrote:
ZODB4 has very little C code and most of it is also available in Python.
*mumble*
Is not ZODB4 development *frozen*?
Yes, and who knows when it will thaw. But it's a better target than ZODB3, at least for now. Jeremy
Bob Ippolito wrote:
Does Zope really need any C extensions to do what it needs to do (not considering performance) if they were allowed to use new style classes? I was under the impression that the C extension(s) in Zope were developed to get around some of the shortfalls of the old class system, and was part of the reason for type/class unification?
In Zope 3 which can use new style classes we still see some C-extensions, but I imagine those are there mostly for performance reasons. I'm not sure about that though; I'll ask around. Regards, Martijn
participants (8)
-
Bob Ippolito -
Christian Tismer -
holger krekel -
Jeremy Hylton -
Jeremy Hylton -
Laura Creighton -
Martijn Faassen -
Paolo Invernizzi