Re: [Jython-users] jython to java?

[D-Man <ds...@ri...>]

On Fri, Mar 09, 2001 at 06:40:38AM -0800, John Mudd wrote:
| I tried CPython first and I was thrilled to get 2-3 times better
| performance.  But it doesn't support multi-threading.  (Unless I
| completely misunderstand which is possible.)  My impression is that
| CPython threads serially take turns using the interpreter.  

CPython does support multi-threading.  I don't know to what extent it
does time slicing, but you can use threads with it.  (I haven't
written a threaded python app yet)

Java doesn't specify how the VM time slices.  At school with a
particular Sun jdk (I don't remember the version) on Solaris 8 the VM
did no time slicing.  The only way for a different thread to become the current
one is for the current thread to share nicely (ie Thread.wait() or
Thread.sleep()).

| That was a dead end for me.  That plus the need to use Jython (Java)
| classlibs to access our CORBA orb.  Plus the push in our group for
| Java.

You need to use a particular Java library.  Ok that's a good reason to
use Java instead of a different language.  Does that orb have bindings
for other languages?  If it has C or C++ bindings it might not be too
difficult to create a Python wrapper using SWIG.  Just a thought.

Since you wrote this in Python to start with I'll assume you like
python and are convinced of its merits.  It would probably be
advantageous for you to determine why your group is pushing for Java.
If it is because of simpler coding, portability, etc, then maybe you
could present Python as an alternative.  If you can manage to get
Python bindings for your CORBA orb that would help as well.  (BTW,
ORBit has Python bindings,  it's the free open source orb that GNOME
uses)

| Convert to C or C++.  My impression is that I can only expect about 50%
| better performance than using Java.  Plus my code now has reached the

In my experiences Java has been quite slow for involved applications.
For example, JBuilder InstallAnywhere and NetBeans.  All use Java +
Swing.  At times the GUI is quite unresponsive.  On a Win2k box, PIII
~400 MHz, 128MB RAM it takes a while for JBuilder to redraw the screen
if it has been minimized for a while.  On the other hand, if Java's
higher level of coding allows the developer's to create the app faster
and more correctly IMO the performance hit is not a big deal.
(Otherwise I would use machine code and not python ;-))

Someone else replied to me similarly saying the C/C++ doesn't give a
large performance improvement, but "java implementations will continue
to get better".  Sun has been touting this excuse for poor
implementations for years.  Of course it is getting better (we hope
;-)), but so is everything else.  Besides, unless the VM's do some
real intelligent runtime optimizations it can't be as fast as C.  It
is implemented in C.  Every Java instruction takes several C
instructions to execute.  IMO Java was released WAY before it was
mature enough, and then got marketed like a silver bullet.  

| limits of the hardware and so, in that respect, there is no room for
| further improvement.  Although I agree that it would still be better to
| put less stress on the machine that I have to share with many other
| processes.  A more efficient program would help in that respect but...

Hmm, if you're at the hardware's limits I don't think there is much
you can do except try and reduce the resource requirements of the
program.

| Recode in C?? The app is tooo complicated.  By design, 'C' doesn't
| afford implementing such deep abstraction.

I don't know about that.  Sure, it might (will) not be as easy as
Python, but the GTK+ developers use C to create a highly OO and
polymorphic toolkit.

| C++ was an early attempt to solve this fundamental problem with OOP but
| I consider it the 286 (the predecessor to Intel's 386 processor) of OOP
| languages.  A necessary step but I'm proud to have never coded in it
| the same way I'm proud to have never owned a 286 PC.

I think this is a fairly accurate statement.  From my understanding
C++ was originally created with 2 main design goals : speed (in OO)
and compatibility with the large amount of existing C code.  OO
languages like Smalltalk and Modula were around, but didn't have the
performance of C.

I don't know very much about the 286's architecture other than it is
very different from the 386.  One of the reasons Linux needs at least
a 386 to run.  I do know a bit about the x86 architecture (pre-Pentium
at least) and how it compares to the M68K architecture.


If you want to read a good article comparing several languages and
their performance vs. code size, check IEEE Computer magazine from a
few months ago.  It compared C, C++, Java, Python, Perl, Tcl, and
Rexx.  The conclusion is basically this:  well-written C and C++ is
faster than anything else.  It also takes less memory.  HOWEVER it is
still possible (even easy IMO) to write poor quality C/C++ that has
terrible performance, memory leaks, etc.  The speed difference between
traditional compiled languages and newer interpreted langauges is not
an issue except when it is (for example your case where
experimentation shows a performance boost is necessary).  The article
did _not_ compare the design of the language and the readability of
the code.  It did give measurements of LOC for each language and
LOC/hour of the developers.  Those numbers are, of course, approximate
and can vary greatly depending on developer skill and motivation.


The other replier said:
"""Sure you could use CPython but who wants to write c extensions when
you can whip them out in java!!"""

I don't find Java to be particularly cool, but I do find Jython's
seamless integration of Python and Java to be very cool.  I've never
written a C extension to Python so I don't know how painful it may be,
but writting Java extensions to Jython seems to be extremely easy.


The key to remember is that performance is the least significant
factor when choosing a language.  Language design and its ease of use
are far more important.  In John's case, however, he has determined
that his current implementation doesn't meet the performance criteria
that he has and must rework it.  That's fine since he took the proper
perspective on saving performance considerations for last.

-D