-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Parrot 0.1.2 was released a couple of weeks ago. According to the release notes, there's now "better python support, separated into dynaclasses".
Unfortunately, I haven't really managed to keep up with the Parrot project, but I think it quite possibly represents the strategic future of Zope.
An obvious benefit is the genuine concurrency it offers over GIL on SMP hardware. Anyone running an enterprise Zope or Plone installation would desire to take advantage of this.
I know a year or so ago, someone received a pie in the face at a conference because Parrot still wasn't as fast as the native Python interpreter, but maybe this too has changed with this release.
I'm very interested to know if anyone is investigating Parrot.
Alan
On Mar 18, 2005, at 9:18 PM, Alan Milligan wrote:
I know a year or so ago, someone received a pie in the face at a conference because Parrot still wasn't as fast as the native Python interpreter, but maybe this too has changed with this release.
I wouldn't say that Dan got his pie because it wasn't fast enough. It was more that it wasn't complete enough. At the time, Parrot could only run four out of the seven tests that Dan and Guido agreed on.
Of the four tests that ran, Parrot was faster at three, and twice as slow on the fourth.
http://www.sidhe.org/~dan/blog/archives/000371.html
(I guess if you consider "didn't run" as "took an infinitely long time to run, Parrot averaged as being slower.)
I'm very interested to know if anyone is investigating Parrot.
In http://mail.zope.org/pipermail/zope/2004-August/152678.html Tim Peters said "Zope plays in Python's dark corners like few other apps dare" and describes some bugs in Python 2.3.3 that were fixed in 2.3.4 because the bug was found when trying to run Zope. I haven't tried the latest version of Parrot, but I'd think that Zope would be the last thing that will run successfully.
On Mon, 21 Mar 2005 10:54:11 -0500, Andrew Langmead alangmead@boston.com wrote:
I haven't tried the latest version of Parrot, but I'd think that Zope would be the last thing that will run successfully.
I don't know that Parrot tries to emulate Python's C API either, and Zope definately contains several C extensions. These would need to be re-written in Python or to use Parrot's API. So I suspect there's a good bit of work to do to really make it run.
-Fred
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Fred Drake wrote: | | I don't know that Parrot tries to emulate Python's C API either, and | Zope definately contains several C extensions. These would need to be | re-written in Python or to use Parrot's API. So I suspect there's a | good bit of work to do to really make it run. |
I'm not sure that it's necessarily this difficult. Perhaps it's simply a matter of implementing Python's import/dlopen semantics and running this C natively on the VM.
Perl was quite revolutionary in it's use of dynamic loading and the entire autoload concept is native to the language. I've not actually tried, but I expect you could run up a Z2 using inline::Python.
Of course, I haven't been so closely following Perl6 and they are taking a different approach to XS than Perl5 which could perhaps mean it's not as featureful as we'd require - but then again one shouldn't discount the Larry/Damian factor ...
Alan
On Mar 21, 2005, at 11:59 AM, Alan Milligan wrote:
I'm not sure that it's necessarily this difficult. Perhaps it's simply a matter of implementing Python's import/dlopen semantics and running this C natively on the VM.
Take a look at something like
Zope-{version}/lib/Components/ExtensionClass/src
and look at the "Py{mumble}" functions that get called. To get Zope to work under Python, either those classes will need to be written, or compatible versions of those that interact with parrot. (which is what Fred was asking about whether Parrot supported Python's C API) So faced with the choice of re-writing things like ExtensionClass or emulating enough of the Python C API to support them, I'd start with writing a conversion library.
Some of the replacements would be easy. For example having a Py_None global that can fetch the None object. Things like PyArg_ParseTuple look like they map fairly well to <http://search.cpan.org/~ltoetsch/parrot-0.1.2/docs/pdds/ pdd16_native_call.pod> Some of them (lets say PyModule_GetDict) might be more difficult. The amount of glue code needed to convert ExtensionClass's idea of what the cPython interpreter provides into the functionality that the Parrot VM provides will start increasing. (does a Parrot module have the equivalent of an embedded dictionary object?)
None of this is a show stopper, but it would take some time to get it to work.
Alan Milligan wrote:
An obvious benefit is the genuine concurrency it offers over GIL on SMP hardware. Anyone running an enterprise Zope or Plone installation would desire to take advantage of this.
ZEO, multiple clients and processor affinity settings already offer this, and with no extra development needed...
Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Chris Withers wrote:
| ZEO, multiple clients and processor affinity settings already offer | this, and with no extra development needed... | What userland tools are you using to implement processor affinity??
Alan
Alan Milligan wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Chris Withers wrote:
| ZEO, multiple clients and processor affinity settings already offer | this, and with no extra development needed... | What userland tools are you using to implement processor affinity??
Alan
schedutils. See recent thread on the zope-list for a brief discussion on the topic.
/dario
-
Alan Milligan -
Andrew Langmead -
Chris Withers -
Dario Lopez-Kästen -
Fred Drake