Re: Some Thoughts

Seb:

Thank you for summarizing and making explicit all the issues quite 
succinctly.  I can see this gleam of mine is a dead-end issue for the 
"*current*" Zope core as you put it.  I do know others have shown 
interest before, but I do not feel I have the whatever-it-takes to pull 
it off myself.

Nevertheless, I have some curiosity to satisfy about the reaction(s) to 
my proposal and some for-the-record clarifications in my reply below.

On Wednesday, February 5, 2003, at 06:17  AM, seb bacon wrote:
> I'm afraid you are unlikely to find much support for your java-zope 
> campaign among most core developers ;-)

Believe it or not (:-) you are not the first person to tell me that 
(even almost to the same words).  Almost deja vu!  I'm willing to 
believe it but consider it a shame.

Before this thread, I believed Zope core had something against Java 
(which I would like to understand so I can avoid it in the future).  I 
think religion (or something?) can get in the way of progress.  I have 
experienced quite a bit of inexplicable (to me) and unabashed hostility 
on (and off) this thread.

Now I am beginning to believe the hostility is not necessarily 
originating from Zope (as I initially hypothesized) but rather from 
Python, i.e., it's more general than I even understood.  Could anyone 
explain this hostility toward Java, because I don't understand it and 
would like to avoid/defuse it in the future.

To me it's like having a toolbox where the hammer (python, general 
purpose tool) dislikes the screwdriver and all its bits (another 
general purpose toolset).  Nonsense to me.  Both tools are incredibly 
powerful given the correct circumstances.  I don't think there's such 
hostility from the Java camp for Python, but maybe I've lived a 
sheltered life and just don't know.

> The performance argument is really a dead-end.

Interesting.

> There is possibly a case for Java in terms of winning over more 
> developers from the Java world, but I don't believe that increasing 
> Zope mindshare is a goal of the Zope2 -> 3 migration.  Zope 3 is about 
> doing things the Right Way, and the migration is about convincing 
> people that it is a Good Thing.

That rings true to me too --- "build a better mousebox".  I would just 
want to avoid any insinuation that Zope/JVM is necessarily not a "Right 
Way [...] Good Thing" way as a platform for Zope.  I do not know if 
that was an insinuation, but I'd like explicitly to disagree with such 
a notion.  If there was no such notion implied, I apologize.

> Some notes re. performance follow.

I think your notes warrant clarification from my end, but as you've 
pointed out, there isn't enough interest to warrant much discussion (on 
this list).

So, briefly, without being the definitive expert on all these things, 
I'll chime in with my view.  Feel free to respond by email to spare the 
list any more chatter.

[Warning: feel free to stop reading now, unless you want to hear 
details about java and any Zope/JVM proposal.]

Clarifications:

>  - jython is not faster than python in arbitrary pystone-based
>    benchmarks; it is roughly equivalent

I believe you're being generous.  As I recall from someone's informal 
benchmarks, current jython is even slower than (30-50% speed) CPython.  
I could be wrong, but we're agreed that current jython is not a 
speedster.  Jython's current focus is of necessity on functionality, 
not speed, right now and does not have the developmental maturity and 
support network CPython obviously has.

>  - jython/java performance varies massively depending on the JVM used

Yes, the old JVMs are much slower.  The HotSpot JVM is considerably 
faster by design and by a considerable margin than the old JVM's.

>  - I believe that using JITs is not recommended with jython, which will
>    cause a significant decrease in performance

I have not heard that.

The interesting JVM is the HotSpot which should handle jython just fine 
(and that's the JVM that matters for enterprise/web servers).  HotSpot 
can bring Java to within 25% speed of C (sometimes even faster 
depending on application).  Most people who think Java is slow are 
thinking of old Java JVM's.  That's a common misperception these days 
about Java/JVM technology.

Also, to be explicit, Java is not all about performance.  It has a 
valuable safe programming model and powerful security model as well 
which have evolved and matured over time as well.

>  - pystone benchmarks are one thing; real-world apps are another.  We
>    won't know how well Zope will perform under jython until it is
>    implementated in jython.

We agree.

> There is absolutely no reason to believe that a jython version of Zope 
> would be any faster, or easy to implement.

Those are strong words.  ;-)

I believe future Jython has great potential to be faster than CPython 
for running python code.  In particular, there are two ways (as you 
know) to make python faster.  Zope uses one of them.  One is to write 
python code in C (i.e., it's not python code anymore), and the other is 
to make the python execution engine faster.  Zope uses C code to get 
speed in lieu of pure python code.

I consider the C code solution inferior to any solution which makes 
python code, itself, faster.  I think the reason is obvious but just to 
be explicit:  when I program or support python code, I do so due to the 
merits of python (and do not want to be saddled with C code).

This dichotomous nature of CPython/C is the crux of this issue.  C is a 
speed crutch for CPython (modulo functionality derived from C libraries 
for convenience).

To me, the "Right Way [...] Good Thing" approach to this issue is to 
speed up the python code without having to shift gears to C (or any 
other language) code.

How to do that?

Hypothetically...
according to an old-time python developer (Jim Hugunin?) presented at a 
conference with a gleam in his eye  (and now it's stuck in mine) some 
years ago...
take the following ingredients and mix them as desired;

1.  Python evolves into a not-perfectly-backward-compatible Python3000 
(at the time, now apparently mothballed) with language changes which 
lend themselves to high-performance JVM implementation of python native 
types --- resulting in near Java speed of Python in JVM.  This is why I 
keep mentioning Python3000.  Current jython is no faster than CPython, 
but an evolved jython3000 could be a magnitude faster (if I understood 
and recall the presentation properly).

2.  Jython evolves into Jython3000 to implement (hypothetical) 
Python3000 as above for near Java speed execution of python3000 code on 
HotSpot JVM.

3.  Zope converts to (hypothetical) Python3000 (compatible with 
hypothetical CPython3000 and Jython3000).

4.  Zope goes pure python enough to host on Jython3000.  At this point, 
I think Zope/JVM would be faster than Zope/CPython even though it would 
be pure python!  I think this is an optimal solution for Zope since C 
code loses much of the value of python code (obviously), and a pure 
python Zope most desirable.

Previously, I do not think I sufficiently explained this issue since I 
did not realize python3000 was (rather than at a more advanced stage of 
development) mothballed/retired/put out to pasture.  Also, I was 
surprised by the java resistance issues in this forum (whether Zope or 
Python originated, I do not understand their source) and do not really 
know how to address those.  However, the above is my explicit thinking 
and understanding of the issues.  I hope I'm not misrepresenting the 
Python3000/JVM promise, but that's my understanding of the potential 
future for python for radical speedup (and general language cleanup).

>> Python dovetails virtually perfectly with the jvm object model.
>
> Hmm, multiple inheritance?  Interfaces?  Operator overloading?
>
> Other incompatibilies:

Java is not the JVM.  The JVM is a general purpose machine.  The JVM is 
quite capable of handling python already.  As for dovetailing with Java 
itself, python users should not care if java is more restrictive than 
python.  IOW, as long as python is more general purpose than java, 
python users should be happy, and that's the case.

Jython is a remarkably, surprisingly smooth built-in for java.  Jython 
and java share their objects seamlessly.  Both use garbage collection 
approach (though (C)Python's current implementation of gc is not as 
advanced which causes a few issues).  Jython begs the question of what 
exactly is Python?  Is it CPython as implemented, or is it something 
beyond CPython?  Are some of python's "features" merely artifacts of 
CPython implementation rather than inherent in Python language?  I 
believe those are open questions and subject to python evolution.

For contrast jython, PyObjc (the python to objective-c bridge) is a 
hairy engineering challenge by comparison (though also becoming an 
engineering marvel thanks to the core developers who are doing amazing 
things to bridge the two object models).    On the surface, obj-c is 
more dynamic and more compatible than Java with python.  However, in 
this case, the devil is in the details.  The Java JVM is much more 
flexible and versatile than Java, so it hosts Python very well, whereas 
objc has all sorts of dark corners and secrets which cause bridging 
issues (even though the object models are similarly dynamic).  
Furthermore, the philosophies of the two languages in terms of 
programming safety and cleanliness of design work in the Python/Java 
union favor surprisingly well.  I think Java's puritanical 
idiosyncracies (safety is high priority) work in Jython's favor as 
fewer issues crop up from the Java side.  Other than that, I can't 
really explain why jython works so well except to say, I wish 
JavaScript had been python/jython (and not some newfangled scripting 
language).

>  - jython doesn't have a restricted execution mode.

jython is not currently python feature complete.  It's on python2.1 
right now and struggling to get to 2.2.  I am no expert but have no 
reason to believe such a mode would present any obstacles to 
implementing.  Would it?

>  - jython doesn't support the same introspection interfaces as python

I'm not familiar with this issue.  Insurmountable?  Necessary for Zope3?

> > All of a sudden the code would be running at JVM speed which is
> > (debates aside) nearly C/C++ speed for typical code
>
> I don't understand.

I think my explanation(s) above should clarify this issue.

>  - JVMs are implemented partly in C.

Could be, but that's irrelevant.

 From a purely python-centric perspective.  Here's a new (identical) 
proposal:

What would it take to upgrade the CPython runtime to use the most 
advanced runtime available?  It would be (reportedly) written in C, 
just like the CPython runtime.  It already has support on more 
platforms than the CPython runtime and continues to grow.  It has huge 
bucks behind it for support.  And it's available now.

How about changing the python language to take advantage of the full 
speed of this new runtime (and other similar runtimes)?  If the 
language evolved to run at native speed on this runtime by dropping 
some of its pure OO heritage, would it be worth it for a 5-10x speedup? 
  IOW, if integers became native int's (a la C) instead of OO integers, 
would that be worth a 5-10x speedup?

Now, take that new python (e.g., Python3000) and run it on that new 
runtime (e.g., HotSpot JVM).  Does running a scripting language at near 
compiled language speed sound interesting?  To me, if it's python, it 
seems like a dream.

I realize speed is not everything, but 5-10x is more than just speed, 
it would bring python to a whole new level of utility and power.  (At 
the risk of alienating java haters) I would love to have java and 
python in my toolbox and choose the appropriate tool due to the nature 
of the problem (without any real tradeoff of speed).  That would be 
really interesting and pleasurable.  Furthermore, that would be an 
incredibly powerful pairing of tools for a huge range of problems, 
especially since they could talk nearly seamlessly using a shared 
object model, garbage collection, libraries, etc..

So, yes, CPython is in C, and reportedly JVM is written in C.  In some 
sense, they're distant cousins.  They both are capable of hosting 
python.  Python should not care which one it runs on.  It just needs 
the fasted runtime machine available.  That's what the HotSpot JVM 
offers.

>  - A hardware JVM might compare favourably.  A Microsoft JVM is a bit
>    faster than the Sun JVM.  All software JVMs are an extra execution
>    layer on top of the hardware.  There is no useful or meaningful
>    comparison you can make between "JVM speed" and "C speed", beyond
>    that C is *much* faster.

Special hardware is not necessary.  With a (hypothetical) python3000, 
the HotSpot JVM has enough secret sauce to do the trick.

>  - Java and python are both slower than C by several orders of 
> magnitude

Not so for Java.  That is a common misperception based on earlier 
JVM's.  Java is probably 25% slower (if that) overall in HotSpot 
execution than C.  Python is currently scripting language slow, but 
need not necessarily be so (if I understood Jim Hugunin's Python3000 
innuendo properly) as described above.

That's about it for me.  Feel free to follow up in email as desired as 
this topic has little traction for this forum.

Cheers,

= Joe =