[Zope] Zope needs this (and Dynamo has it)

[Alexander Staubo]

> From: Martijn Faassen [mailto:faassen@vet.uu.nl]
> Sent: Tuesday, March 07, 2000 10:40 PM
> To: Zope Mailing List (E-mail)
> Subject: Re: [Zope] Zope needs this (and Dynamo has it)
> 
> 
> Alexander Staubo wrote:
> > I definitely believe that Python is Zope's largest problem 
> right now.
> > It's also, from a technical point of view, one of it's 
> biggest assets --
> > Zope is becoming the killer application of Python, and 
> might eventually
> > become the driving force to evolve Python, which is, I believe,
> > suffering from draught into the contributor department. Skilled
> > developers aren't flocking to Python to make it faster. Not 
> right now,
> > anyway.
> 
> Hm, skilled developers do hack on Python! There's the Python people at
> CRNI, there's Christian Tismer in Germany doing Stackless 
> Python (which
> offers interesting arcane features and a mild performance 
> improvements),
> there's the whole JPython group, there's John Skaller with his Vyper
> project (a Python interpreter/compiler in Ocaml, one of the reasons
> is more speed). Then there's the Python Types-SIG, which I urge you to
> look at if you haven't already.

People are indeed working on Python, but not to the extent of more
popular projects like Linux or even, I believe, Perl.

Compiler/language projects have, historically, not thrived in the
collaborative world of open source software -- for very specific reasons
inherent in the concept itself of languages and compilers. Still, I'm
very impressed with the evolution of next-gen GCC (formerly EGCS).

I consider Skaller's Vyper project a fringe project with limited
applicability, because Ocaml itself is a fringe project -- it's
certainly not what you might call a mainstream, popular language.
There's something icky about an OcamlPython. However, I'd love for it to
succeed. (Unfortunately, Skaller is already out on a limb, implementing
all sorts of stuff he deems interesting -- so true CPython compliance
isn't necessarily on his agenda, and fragmenting Python like this is,
imho, not a good thing.)

Anyway, while I have not been monitoring the Python type/interface SIG,
it seems to be moving quite slowly.
 
> > My hope is that Zope will change this, because Python has 
> possibly one
> > of the slowest interpreters on earth. Python zealots -- and there is
> > such a beast -- will tell you that Python's performance is less of a
> > matter because what you sacrifice in speed you gain in power, ie.
> > computational expressiveness through a high-level, dynamic language.
> 
> It is _less_ of a problem, but most Pythoneers are indeed 
> interested in
> speeding of the language. I haven't heard of zealots who want to hold
> back speedups, as long as it doesn't do away with the power.

I'm not saying they're holding back, but rather they're dismissing speed
and scalability as being a problem. I firmly believe that speed is
Python's number of problem today, and it's keeping Python from being
used in more applications.

Python has plenty of problems, but they're tiny by comparison and imho
they're mostly artifacts of Python's currently somewhat anemic syntax
(eg., only two kinds of loops, no "switch", no protected members, no
constants, no syntax for declaring mutability).

Imho Python's second big problem is what you might call, in lack of a
better term (I'm not wearing my compiler-writer hat right now, sorry),
contractual semantics -- anything from static typing (pass a string to a
function that takes an int and you get either a compilation error or an
exception) to interfaces (the ability to enforce semantic compatibility)
to design-by-contract constructs.
 
> > For an example of a good, Python-like, dynamic language that is also
> > very fast, take a look at Dylan. In current 
> implementations, Dylan is
> > not interpreted but rather compiled to native code, but in 
> theory there
> > is nothing stopping anyone from writing a highly efficient Dylan
> > interpreter. Dylan's magic comes from its use of type 
> hints, a system
> > which I had recognized as likely pivotal to improving Python's
> > interpreter long before I knew of Dylan.
> 
> It'll be pretty difficult to make a beast like Zope exploit 
> type-hints, though,
> I think.

I disagree, but there's only one way to find out -- implement it (or
simulate it very carefully).

>By the way, the Types-SIG is working on type 
> extensions to Python,
> partially for performance (OPT), partially for better error 
> checking (ERR)
> and partially for better documentation (DOC). See:
> 
> http://www.python.org/sigs/types-sig/
> 
> And also see the new compiler SIG:
> 
> http://www.python.org/sigs/compiler-sig/

Very interesting, thanks.

> > Just imagine -- while Zope is running, thousands and 
> thousands of the
> > same little checks are performed continuously, over and over again,
> > amounting to no uncertain overhead.
> 
> That's of course true. I heard Christian Tismer talk about making a 
> register machine interpreter for Python, which could potentially speed
> things up quite a bit. I shall ask him about this idea again 
> sometime. :)

Not potentially. Definitely. I thought about this yesterday, and I got
to thinking that it would probably be pretty simple to create a dynamic
native-code generator that translated bits of bytecode on-the-fly, with
the necessary stubs implemented in a small helper-assembler written in
C. Something like:

  def Halibut():
    ...

  import codegen
  c = codegen.Translate(Halibut)
  c()  # Call native-code function Halibut

and then with whole modules:

  import pickle, codegen
  pickle = codegen.Translate(pickle)

Internally, Translate() would disassemble the bytecode, generating
native assembly language code and pass it to the helper C module, which
would store it in an executable buffer and fix up the necessary
references to the Py* API symbols.

Just a thought.

It would be an interim solution for certain CPU-intensive modules, in
anticipation of such built-in functionality in CPython itself. Possibly.

> > Python's biggest overhead comes from its dynamism -- the 
> dynamic typing,
> > as explained, combined the object allocation system: most 
> things is an
> > object, so a lot of objects are constantly spawned and torn 
> down, often
> > in rapid succession because the compiler/interpreter can 
> make few hard
> > analyses of when stuff is needed. Python also has a high 
> function-call
> > overhead.
> 
> All true. Anyway, the only thing you're wrong about is that 
> Pythoneers aren't
> interested in improving performance. They are, but I grant 
> you they're not
> performance nuts like users of C or C++. :)

Well, I guess they're too busy arguing about whether Python should allow
assignments as expressions so you could do "while line = f.readline():".
;-)

> 
> Regards,
> 
> Martijn
>

-- 
Alexander Staubo         http://alex.mop.no/
"Do not go gentle into that good night/old age should rave and
burn against the close of day/Rage, rage against the dying of
the light." --Dylan Thomas