CPython vs. Jython/JPython
D-Man
Hi.
This isn't to start a flame war, but to clarify some confusion I have.
I am wondering why there are two separate python interpreters being developed (the one in C, the other in Java). Wouldn't it be more productive if both teams worked together on one interpreter? Another thought I had was that it would be easier to make python cross-platform if it was written in Java and let the Java developers worry about the C-level platform dependencies. Isn't it also possible to write Java extensions in C? (read: ... python extensions in C (using the Java interpreter))
I thank all in advance for your insight into this matter.
-D
Tyler Eaves
than C.
---
Tyler Eaves
Visit Ultra Coaster Central!
The internet's largest repository
of Ultra Coaster Tracks!
http://www.ultracoastercentral.com
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Delaney, Timothy
dismissing it out of hand).
1. Need for a Java Virtual Machine.
The CPython interpreter is *much* smaller than the JVM, both in install size
and resource usage. The disparity is even greater when using Stackless
CPython.
2. Speed.
The CPython interpreter is much faster than J(P)ython. Whilst this could be
offset somewhat by doing everything through JNI, this has a few other
problems:
Harder to use a single source tree for all platforms.
It will still be *many* times slower than CPython due to the
overhead of JNI.
3. Compatibility
In addition to the need for JNI (and the incompatibilities introduced by
that) Python would *only* be available on those platforms which had a
well-behaving implementation of the correct version of the JVM. As an
example - I doubt there would be an Amiga version of Python if Python only
ran on top of the JVM.
4. Stackless.
If Python was written in Java, I highly doubt we would *ever* have seen the
wonderful Stackless implementation come about. Since it has been done people
are looking at how the Stackless extensions could be mapped onto J(P)ython,
but it appears that everything would have to be done with Java Threads -
which will slow Stackless down to a crawl.
Personally, I can't think of any advantages of having the reference
implementation in Java which Python doesn't already have.
I'll let others come up with other reasons for and against.
Tim Delaney
PIP
> -----Original Message-----
> From: D-Man [mailto:dsh...@rit.edu]
> Sent: Monday, 30 October 2000 3:28 PM
> To: pytho...@python.org
> Subject: CPython vs. Jython/JPython
>
>
>
> Hi.
>
> This isn't to start a flame war, but to clarify some confusion I have.
>
> I am wondering why there are two separate python interpreters
> being developed (the one in C, the other in Java). Wouldn't
> it be more productive if both teams worked together on one
> interpreter? Another thought I had was that it would be
> easier to make python cross-platform if it was written in
> Java and let the Java developers worry about the C-level
> platform dependencies. Isn't it also possible to write Java
> extensions in C? (read: ... python extensions in C (using
> the Java interpreter))
>
> I thank all in advance for your insight into this matter.
>
> -D
>
>
> --
Courageous
> It will still be *many* times slower than CPython due to the
> overhead of JNI.
I'm not sure if I follow; IIRC, the JNI is faster than CPython's
native dispatch.
> If Python was written in Java, I highly doubt we would *ever* have seen the
> wonderful Stackless implementation come about.
You wouldn't be able to do a proper stackless environment in Java
without Sun's cooperation, because true stacklessness would require
alterations to the JVM.
> Personally, I can't think of any advantages of having the reference
> implementation in Java which Python doesn't already have.
I agree. Indeed Java is not the second coming of Jesus. Please
do not treat it this way.
C//
Moshe Zadka
>
> Hi.
>
> This isn't to start a flame war, but to clarify some confusion I have.
>
> I am wondering why there are two separate python interpreters being
> developed (the one in C, the other in Java).
Well, the truth of the matter that Barry and Guido aren't on speaking
terms ever since Guido couldn't force Barry to say that IDLE is better
then python-mode for editing Python. Since then, Barry decided to hijack
Jim H's interpreter in Java, and maintain it, just to let Guido know
he isn't afraid of him.
Well, either that or the fact that each interpreter has different
advantages and disadvantages: the C interpreter is much easier to extend
in C (JNI is *hard*), and takes much better advantage of platform quirks.
The Java interpreter is X-platform for "free", is able to run inside
browsers and is easier to experiment with, and is quite a bit slower, and
quite a bit harder to install, since it depends on installing Java.
> Wouldn't it be more productive if both teams worked together on one
> interpreter?
Well, both interpreters are developed in tandem, and are kept carefully
in sync by Guido and Barry. (I think Jeremy has agreed to be a neutral
mediator).
> Another thought I had was that it would be easier to make
> python cross-platform if it was written in Java
You don't really buy that "Java is portable" propaganda from Sun, do you?
> Isn't it also
> possible to write Java extensions in C? (read: ... python extensions in
> C (using the Java interpreter))
possible != easy
--
Moshe Zadka <mos...@math.huji.ac.il> -- 95855124
http://advogato.org/person/moshez
Delaney, Timothy
> > overhead of JNI.
>
> I'm not sure if I follow; IIRC, the JNI is faster than CPython's
> native dispatch.
Ah - but if you're trying to speed up a *Java* version of Python ... you're
going to be constantly switching between JNI-called code and Java code.
In CPython, there is no need for *this* context switch. Others yes ... but
they would also need to be done in J(P)ython, *plus* the JNI overhead.
Tim Delaney
Avaya Australia
entropia
D-Man escribió:
> Hi.
>
> This isn't to start a flame war, but to clarify some confusion I have.
>
Tom
implementation)?
"Tyler Eaves" <ty...@tylereaves.com> wrote in message
news:o7vpvss3u2lrokgde...@4ax.com...
D-Man
Java isn't necessarily slower than C. (I should expand that a little: Java *apps* aren't necessarily slower than C *apps*) There was an article published in the October 2000 edition of IEEE Computer magazine giving an experimental, quantitative analysis of 7 programming languages. A number of the Java implementations (of the solution) were faster than some of the C implementations. (BTW, there were 24 Java implementations and only 5 C implementations) As far as memory usage goes, the Java programs were much higher than everything else.
I am unfamiliar with JNI so I'll have to take your word for it.
I did read an article on Stackless (C)Python and it looked very interesting. If it can't be implemented in Java, that would be a good reason to stick with C.
My other question still stands, however:
Wouldn't it be more productive if both teams worked together on the same interpreter?
Thanks for the response.
-D
On Sun, 29 Oct 2000 23:50:56 "Delaney, Timothy" wrote:
> There are a number of things against this suggestion (note - I'm not
> dismissing it out of hand).
>
> 1. Need for a Java Virtual Machine.
>
> The CPython interpreter is *much* smaller than the JVM, both in install size
> and resource usage. The disparity is even greater when using Stackless
> CPython.
>
> 2. Speed.
>
> The CPython interpreter is much faster than J(P)ython. Whilst this could be
> offset somewhat by doing everything through JNI, this has a few other
> problems:
>
> Harder to use a single source tree for all platforms.
> It will still be *many* times slower than CPython due to the
> overhead of JNI.
>
> 3. Compatibility
>
> In addition to the need for JNI (and the incompatibilities introduced by
> that) Python would *only* be available on those platforms which had a
> well-behaving implementation of the correct version of the JVM. As an
> example - I doubt there would be an Amiga version of Python if Python only
> ran on top of the JVM.
>
> 4. Stackless.
>
> If Python was written in Java, I highly doubt we would *ever* have seen the
> wonderful Stackless implementation come about. Since it has been done people
> are looking at how the Stackless extensions could be mapped onto J(P)ython,
> but it appears that everything would have to be done with Java Threads -
> which will slow Stackless down to a crawl.
>
> Personally, I can't think of any advantages of having the reference
> implementation in Java which Python doesn't already have.
>
D-Man
Java's implementation (from Sun) is proprietary. However, you can get a compiled version for free.
There are also other implementations (gcj allows compiling to native machine code, kaffe provides a bytecode compiler and VM -- for Linux at least
BTW [OT]: I can't remember how to create bytecode with gcj. Would anyone like to refresh my memory?
D-Man
BTW, I posted my other message before I saw the rest of the replies at the bottom of the folder :-)
> > Personally, I can't think of any advantages of having the reference
> > implementation in Java which Python doesn't already have.
>
> I agree. Indeed Java is not the second coming of Jesus. Please
> do not treat it this way.
I'm not treating it that way any more than calling a python script portable does. Python claims the same portability that Sun claims of Java. I have heard of a few problems Java had in being portable, but the goal is there and will hopefully be reached in the near future. Java is nicer than C in some respects, but doesn't provide the low-level access needed for system programming/device drivers.
-D
Stephen Coursen
>
>Java's implementation (from Sun) is proprietary. However, you can get a
>compiled version for free.
>
>There are also other implementations (gcj allows compiling to native
>machine code, kaffe provides a bytecode compiler and VM -- for Linux at
>
>BTW [OT]: I can't remember how to create bytecode with gcj. Would
>anyone like to refresh my memory?
>
gcj -C some_file.java
HTH,
Steve Coursen
>On Mon, 30 Oct 2000 09:29:25 Tom wrote:
>> And isn't Java a proprietary language/platform (ie. how would you like a VB
>> implementation)?
>>
>
>
>
--
--
Stephen Coursen ta...@coursen.tempestnetworks.net
Linux is your friend. Trust the penguin.
"May the forces of evil become confused on the way to your house."
-- George Carlin
Cameron Laird
D-Man <dsh...@rit.edu> wrote:
.
.
.
>I have heard of a few problems Java had in being portable, but the goal is there and will hopefully be reached in the near future.
.
.
I remember often saying the same thing myself.
I'm not sure the goal is still there. I know
the result seems no closer than it did a couple
of years ago.
I've stopped using "near" when I talk about Java.
--
Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Chris Gehlker
D-Man wrote:
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
Alex Martelli
news:mailman.972916946...@python.org...
>
> Java isn't necessarily slower than C. (I should expand that a little:
Java *apps*
> aren't necessarily slower than C *apps*) There was an article published
in the
Right. I can write a C app which spins a million times between each
pair of real operations, thus getting it to be just as slow as I like
("My lord, with you at the helm, we cannot lose!" -- "well, we COULD
if we WANTED to" -- quoted from memory from "Black Adder" episode 1).
Apparently, not a few programmers manage to do that (or the equivalent)
even without trying...
> October 2000 edition of IEEE Computer magazine giving an experimental,
quantitative
> analysis of 7 programming languages. A number of the Java implementations
(of the
> solution) were faster than some of the C implementations. (BTW, there
were 24 Java
> implementations and only 5 C implementations) As far as memory usage
goes, the
It's Lutz Prechelt's study, already often quoted on this group -- see:
http://wwwipd.ira.uka.de/~prechelt/Biblio/
for this and many other studies; a more complete account than the one
published in 'Computer' is, in particular, at:
http://wwwipd.ira.uka.de/~prechelt/Biblio/jccpprtTR.pdf
Basically, he has empirically proved that the individual programmer's
ability is more important than language-choice; *median* execution
times are optimal for C (but the sample is small, so statistical
significance is suspect), second-best for Perl and Python ex aequo
(no statistically significant difference between them), with Java
_and_ C++ having slower medians (!).
Looking only at the _best_ program in each language (presumably
more representative of the language's actual possibilities, when
used by somebody who doesn't insert delay loops on purposes:-),
C was fastest, C++ second, with Java/Perl/Python third ex aequo
within statistical significance (and Tcl and Rexx out in the
left field, but that's another issue; unfortunately for most
other measurements Tcl and Rexx were averaged with Python and
Perl, thus somewhat obscuring the truly excellent performances
of the P-languages compared to strictly-statically typed ones).
Alex
Delaney, Timothy
> a little: Java *apps* aren't necessarily slower than C
Oh - I know that. I've pushed Java for that very reason at some contracts.
However, it is a fact that JPython is considerably slower than CPython on
the same platform (don't have any stats to back me up here though ...).
Jython is at the moment probably fairly similar.
Tim Delaney
Avaya Australia
Rodrigo Senra
>
> Java's implementation (from Sun) is proprietary. However, you can get a compiled version for free.
>
> There are also other implementations (gcj allows compiling to native machine code, kaffe provides a bytecode compiler and VM -- for Linux at least
>
In addition to the excellent arguments already presented, CPython
can be built on solid ground (C is *stable*). A exclusively
Python implementation over non-proprietary JVM (like kaffe,
gcj,etc) could mean builting it over moving sands. I stress
my respect for those efforts, nevertheless they are miles away
from C's stability. IMHO, such a decision (strict Python/Java impl.)
could force us to stop developing Python itself to work *hard*
in the underground.
,/\/\/\p
BTW : To whom this might interest, some brazilian snakes names
for you to name your python projects:
(sucuri,coral,anaconda,gibóia,cascavel... last but not least
píton)
;o)
--
Rodrigo Senra Home Page: http://www.ic.unicamp.br/~921234
rods...@correionet.com.br (OU|or) Rodrig...@ic.unicamp.br
Engenheiro de Computação @ GPr Sistemas Ltda http://www.gpr.com.br
Mestrando (MSc Student) IC - UNICAMP Tema: Reflexão Computacional
Guido van Rossum
The key difference between CPython and JPython is not speed, but
available extensions. CPython is useful as a glue language for C/C++
library code. There are lots of examples, e.g. NumPy, Tkinter, PIL,
and so on. JPython is useful as a glue language for Java library
code, e.g. Swing, JavaBeans, Jave 2 Enterprise Edition APIs, and so
on.
If only CPython existed, linking to Java code would be very
cumbersome: you'd have to wrap a JVM in a CPython extension and take
it from there. If only JPython existed, linking to C/C++ code would
be impossible (in situations where JNI is not available) or at best
cumbersome (wrapping C/C++ code in JNI is much more painful than
writing Python wrappers, because of the JVM's garbage collector).
It's sometimes possible to use C/C++ code from JPython (e.g. Finn Bock
did a wrapper for _tkinter) but rarely convenient. I haven't heard of
anyone linking to a JVM from CPython.
Of course, the fact that there are two different implementations means
that an app that requires the use of both a library written in C/C++
and one written in Java is out of luck. Fortunately, most of the
standard extensions (e.g. regular expressions) are available in both
CPython and JPython.
In the rare case where you need two non-standard extensions, you could
write your program as two communicating processes, one using JPython,
one using CPython.
--Guido van Rossum (home page: http://www.python.org/~guido/)
Delaney, Timothy
The real question which was posed I guess is "why can't they be maintained
by the same people?" To which the answer would have to be that the CPython
people have a limited amount of time, the two projects require different
areas of expertise, and that the source trees really cannot share
*anything*.
Tim Delaney
Avaya Australia
> The key difference between CPython and JPython is not speed, but
> available extensions. CPython is useful as a glue language for C/C++
...
D-Man
Ok, if viewing python as a glue language, then the 2 different implementations of the interpreter is reasonable. I was viewing python as a standalone application language.
Thanks for the response.
-D
BTW, the question wasn't why didn't the same people make both interpreters, but why effort was duplicated in making 2 interpreters
Moshe Zadka
> The BDFL has spoken :)
>
> The real question which was posed I guess is "why can't they be maintained
> by the same people?" To which the answer would have to be that the CPython
> people have a limited amount of time, the two projects require different
> areas of expertise, and that the source trees really cannot share
> *anything*.
Ummmm.....as my last sarcastic answer should have hinted, they are. Barry
and Guido have worked in the same company for quite a few years, and IIRC
Jim H, when he wrote JPython, worked at CNRI, which was then the Python
development center. Barry is a respected CPython developer (for example,
he's responsible for a lot of the i18n in Python 2.0). The two "teams",
as far as they can be called that, work so close together it hurts <wink>.
Tom
>
> Java's implementation (from Sun) is proprietary. However, you can get a
compiled version for free.
>
> There are also other implementations (gcj allows compiling to native
machine code, kaffe provides a bytecode compiler and VM -- > for Linux at
least
Yes, but if you write a program in Java, and then compile it for Linux with
DCJ, then it is still written in (and must be maintained in) a proprietary
language controlled in every way by one company - no better than VB.
Tom.
Courageous
> The two "teams", as far as they can be called that,
> work so close together it hurts <wink>.
So, ah, Barry and Guido are "friends," then?
*blink blink*
C//
Bill de hÓra
I am wondering why there are two separate python interpreters being
developed (the one in C, the other in Java). Wouldn't it be more productive
if both teams worked together on one interpreter? Another thought I had was
that it would be easier to make python cross-platform if it was written in
Java and let the Java developers worry about the C-level platform
dependencies. Isn't it also possible to write Java extensions in C? (read:
... python extensions in C (using the Java interpreter))
>>
ANSI C is very possibly more portable than Java. Java Virtual machines are
not implemented consistently, and the meaning and expected behaviour of the
Java threading and memory model is largely a mystery, even to the people
that designed it. Java is also non-portable when a) you've got more than one
thread, b) want to lock a file c) want non-blocking io operations (this last
will be fixed though).
Raw C written by a good programmer is typically more efficient in space and
time than anything the same programmer will write in Java. That's why it's
used to implement high level language interpreters and compilers.
Java is owned by a company, you have to pay Sun Microsystems a tribute to
sell Java code. Your C code is royalty free.
Java is a far nicer language to program in, but that's about it.
-Bill de hÓra
Bill de hÓra
"Bill de hÓra" <bi...@dehora.fsnet.co.uk> wrote in message
news:8tn36u$r8m$1...@news5.svr.pol.co.uk...
: >>
: I am wondering why there are two separate python interpreters being
Or, to sadly follow myself up, why have:
Python -> Java -> C
when you can have:
Python -> C
and we can say with some certainty that a:) Python library support is
sufficient that we don't need the JDK, and b) Python is more respectful of
developer time than either Java or C.
BTW I write Java code every day. I really like it. But not as a compiler
language.
-Bill de hÓra
Ingo Adler
> ANSI C is very possibly more portable than Java.
Really? What are the #ifdefs for in "ANSI C" - Python?
> Raw C written by a good programmer is typically more efficient in space ...
There are benchmarks that show the opposite.
> Java is owned by a company, you have to pay Sun Microsystems a tribute to
> sell Java code.
Is this really true?
I think, Guido made the point in this thread: JPython is used as glue for
Java-Apps and CPython is used as glue in C++-Apps. It's not possible to replace
one with the other (easily) for this purpose .
Ingo
D-Man
That's a very different coding style and sounds very interesting. Writning a project in multiple languages, but using each one naturally.
BTW, can stackless python be implemented in Java? I don't have any real experience but from reading the paper on it it seems that stackless python simply creates it's own python stack (on the C heap). Then the interpreter creates python frames and pushes them on the python stack, then returns from the C frames. It then executes the python frames independent of the C stack.
-D
On Wed, 01 Nov 2000 18:46:57 Arnold de Vos wrote:
| I don't post to the group much but I *have* to chime in here with a bouquet
| for JPython/Jython. The Java/Python synergy is unique, I know of nothing
| like it anywhere else. You just have to experience it.
|
| In the past, we've implemented a big app in CPython with C extensions and
| found it a very fast way to develop clean and reliable software. We will do
| more of that.
|
| But the mixed Java/Python environment is something quite different that I've
| never seen before. You don't write "java extensions" and "Python glue".
| You literally mix the two languages on a per-class or per-package basis.
|
| I wonder if this is approximately what Python 3000 could look like where
| type-safe and "dynamic-mode" modules are mixed?
|
| - Arnold
|
| ---
| Arnold deVos
| Langdale Consultants
| a...@langdale.com.au
|
|
|
| Guido van Rossum <gu...@beopen.com> wrote in message
| news:cpd7gij...@cj20424-a.reston1.va.home.com...
| --
| http://www.python.org/mailman/listinfo/python-list
|
Jaroslav Gergic
> Or, to sadly follow myself up, why have:
>
> Python -> Java -> C
>
> when you can have:
>
> Python -> C
>
But what about this:
Python source --(Python JIT)--> Java bytecode --> JVM + JIT --> C
Meaning: instead of Python interpreter written in Java to
have Python JIT (or ahead of time compiler) (written in Java) generating
directly Java bytecode and use JVM.
(in case of ahead of time compiler it can be written in C)
Regards
Gergi
Jaroslav Gergic
Jan Dries
>
> Bill de hÓra wrote:
>
> > ANSI C is very possibly more portable than Java.
>
> Really? What are the #ifdefs for in "ANSI C" - Python?
As Bjarne Stroustoup sais in his FAQ answer to the question how Java
compares to C++: Java isn't really platform independent! Java is a
platform. A virtual platform that can be superimposed on many other
hardware/OS platforms, but a platform nonetheless. The only platform
independent piece of Java is the JVM, which, by the way, is written in
C, and I expect it to have just as many #ifdefs as does the Python
interpreter.
The question of portability is not whether Java source of even byte code
is portable across java interpreters, because it by definition is (or
should be, if everybody, MS included, stuck to the JVM spec). The
question of portability is how portable the Java platform itself (i.e.
the JVM) really is.
And it remains a fact that (today at least) the Python platform is
available on several hardware/OS combinations where there's no Java
platform available today.
>
> > Raw C written by a good programmer is typically more efficient in space ...
>
> There are benchmarks that show the opposite.
Could you give a pointer to these benchmarks?
>
Regards,
Jan
Bill de hÓra
"Ingo Adler" <ingo....@synacon.ch> wrote in message
news:39FF4663...@synacon.ch...
: Bill de hÓra wrote:
:
: > ANSI C is very possibly more portable than Java.
:
: Really?
Really.
>What are the #ifdefs for in "ANSI C" - Python?
They're for portability :-)
: > Raw C written by a good programmer is typically more efficient in space
...
:
: There are benchmarks that show the opposite.
:
Evidence please.
: > Java is owned by a company, you have to pay Sun Microsystems a tribute
to
: > sell Java code.
:
: Is this really true?
Yep.
: I think, Guido made the point in this thread: JPython is used as glue for
: Java-Apps and CPython is used as glue in C++-Apps. It's not possible to
replace
: one with the other (easily) for this purpose .
I think Guido is underselling Python and its libraries. Just use Python, it
doesn't need any glue.
-Bill de hÓra
Arnold de Vos
for JPython/Jython. The Java/Python synergy is unique, I know of nothing
like it anywhere else. You just have to experience it.
In the past, we've implemented a big app in CPython with C extensions and
found it a very fast way to develop clean and reliable software. We will do
more of that.
But the mixed Java/Python environment is something quite different that I've
never seen before. You don't write "java extensions" and "Python glue".
You literally mix the two languages on a per-class or per-package basis.
I wonder if this is approximately what Python 3000 could look like where
type-safe and "dynamic-mode" modules are mixed?
- Arnold
---
Arnold deVos
Langdale Consultants
a...@langdale.com.au
Guido van Rossum <gu...@beopen.com> wrote in message
news:cpd7gij...@cj20424-a.reston1.va.home.com...
Timothy O'Malley
I admit I haven't been following this discussion closely. Is there
someplace I can go to find a summary of the current state of affairs?
Guido van Rossum <gu...@beopen.com> wrote:
> Of course, the fact that there are two different implementations means
> that an app that requires the use of both a library written in C/C++
> and one written in Java is out of luck. Fortunately, most of the
> standard extensions (e.g. regular expressions) are available in both
> CPython and JPython.
Does this mean Python will (officially) permit libraries that only
exist for one platform?
If yes, does this mean that I can dare hope for Stackless to be
included in CPython? Perhaps, Stackless is not a "library", and
therefore does not count?
[In truth, I really want uthreads. I'm not so interested in Stackless
by itself. Sorry, Christian. :-) ]
thanx.
Moshe Zadka
>
> > The two "teams", as far as they can be called that,
> > work so close together it hurts <wink>.
>
> So, ah, Barry and Guido are "friends," then?
Ummmmm.....they have a relationship that goes back a long time.
I will not try to analyze it.
leaving-implications-for-the-future-ly y'rs, Z.
Greg Jorgensen
news:39FF4663...@synacon.ch...
> Bill de hÓra wrote:
>
...
>
> There are benchmarks that show the opposite.
Benchmarks may show a lot of things, but they can't show that Java can be
MORE efficient than ANSI C, controlling for other variables. That would be
equivalent to asserting that Michael Jordan with a 50 pound weight on his
back can play better than Michael Jordan without the weight. You don't need
benchmarks to understand that the weighted Jordan can't possibly be FASTER
or take up LESS space than the unweighted Jordan. It would be easy to
demonstrate that even the weighted Michael Jordan could beat me in a game,
though. That's what the benchmarks you are referring to show.
There is no way that a Java program can be faster than the equivalent C
program, on the same computer, if the best practices and idioms of each
language are followed. Of course a skilled programmer using Java (or Visual
Basic, for that matter) can write more efficient code than a bad C
programmer, but that's comparing programmers, not languages.
C is often described as a portable macro assembler. Well-written C programs
can be almost as efficient as hand-written assembly, but never MORE
efficient (again, think of ideal C and assembly programmers, not the average
programmer who barely knows how to read assembly). By the same token, Java
compilers, JVMs, and libraries are usually implemented in C, so Java is in a
sense a portable "macro" C. The runtime support required to interpret (or
compile "just in time") and execute a Java programmer can never be MORE
efficient than not having that runtime support at all: the JVM and bytecode
interpreter/compiler always uses some amount of memory and CPU cycles that
the C program doesn't have to give up.
By the same argument Java can't be MORE portable than ANSI C. The current
state of JVMs demonstrates the difficulty of achieving "write once, run
everywhere." Perhaps this will improve over time, but as long as Java is
proprietary it is going to be a vendor battlefield.
Java is a higher-level language than C, and the language protects the
programmer from the headaches of C (memory management, pointers, abuse of
type conversions). Programmer time and maintenance effort should be given at
least as much weight--and probably more weight--than runtime efficiency.
--
Greg Jorgensen
Deschooling Society
Portland, Oregon, USA
gr...@pobox.com
Thomas Wouters
> Benchmarks may show a lot of things, but they can't show that Java can be
> MORE efficient than ANSI C, controlling for other variables. That would be
Actually, Perl, which is written in C (unsure if it's ANSI or K&R style, but
that doesn't matter,) can be faster than 'normal' C code. Perl apparently
uses 'tricks', directly modifies FILE structures, etc, on platforms that it
knows enough about to do such things. Yes, you can do this in your own C
program, but noone does it. Why ? Because it would be a hell to maintain.
Because it's hard to figure out what is 'optimum' usage for your system. The
Perl code is already tuned for it, and you get that extra performance for
free.
The same way Java can be faster than the 'equivalent' C. You get to
piggyback your code on the speed optimizations of professional programmers
who thought long and hard about how to optimize certain Java operations. 'C
speed' isn't an absolute, it's a question of how you write that code, what
library calls you use, how large the buffers are that you use, etc.
--
Thomas Wouters <tho...@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Chris Gehlker
N8_M5.51390$E85.1...@news1.sttls1.wa.home.com, "Greg Jorgensen"
<gr...@pobox.com> wrote:
> "Ingo Adler" <ingo....@synacon.ch> wrote in message
> news:39FF4663...@synacon.ch...
>> Bill de hÓra wrote:
>>
>>> Raw C written by a good programmer is typically more efficient in space
> ...
>>
>> There are benchmarks that show the opposite.
>
> Benchmarks may show a lot of things, but they can't show that Java can be
> MORE efficient than ANSI C, controlling for other variables. That would be
> equivalent to asserting that Michael Jordan with a 50 pound weight on his
> back can play better than Michael Jordan without the weight. You don't need
> benchmarks to understand that the weighted Jordan can't possibly be FASTER
> or take up LESS space than the unweighted Jordan. It would be easy to
> demonstrate that even the weighted Michael Jordan could beat me in a game,
> though. That's what the benchmarks you are referring to show.
>
> There is no way that a Java program can be faster than the equivalent C
> program, on the same computer, if the best practices and idioms of each
> language are followed. Of course a skilled programmer using Java (or Visual
> Basic, for that matter) can write more efficient code than a bad C
> programmer, but that's comparing programmers, not languages.
>
> C is often described as a portable macro assembler. Well-written C programs
> can be almost as efficient as hand-written assembly, but never MORE
> efficient (again, think of ideal C and assembly programmers, not the average
> programmer who barely knows how to read assembly).
While I agree with the thrust of this post, I have to pick a nit here. On
many platforms C will always beat assembler because C will reorder
instructions to keep the pipelines in the processor full. While in theory a
human could do this as well, in practice, it's just too laborious. One would
have to go though the program line by line with a table of all the
instruction timings and rearrange it. That what the compiler does on full
opt.
By the same token, Java
> compilers, JVMs, and libraries are usually implemented in C, so Java is in a
> sense a portable "macro" C. The runtime support required to interpret (or
> compile "just in time") and execute a Java programmer can never be MORE
> efficient than not having that runtime support at all: the JVM and bytecode
> interpreter/compiler always uses some amount of memory and CPU cycles that
> the C program doesn't have to give up.
>
> By the same argument Java can't be MORE portable than ANSI C. The current
> state of JVMs demonstrates the difficulty of achieving "write once, run
> everywhere." Perhaps this will improve over time, but as long as Java is
> proprietary it is going to be a vendor battlefield.
>
> Java is a higher-level language than C, and the language protects the
> programmer from the headaches of C (memory management, pointers, abuse of
> type conversions). Programmer time and maintenance effort should be given at
> least as much weight--and probably more weight--than runtime efficiency.
If you write a significant amount of Java, you will find that the memory
management is a joke. The garbage collection runs at too low a priority to
really be effective in an application of any size. You have to take over
memory management yourself. Sun has said as much in their developer
mailings.
Rodrigo Senra
>
> "Ingo Adler" <ingo....@synacon.ch> wrote in message
> news:39FF4663...@synacon.ch...
> > Bill de hÓra wrote:
> >
> ...
> >
> > There are benchmarks that show the opposite.
>
>
> program, on the same computer, if the best practices and idioms of each
> language are followed. Of course a skilled programmer using Java (or Visual
> Basic, for that matter) can write more efficient code than a bad C
> programmer, but that's comparing programmers, not languages.
Point taken, though I think the heart of the matter is that Java takes
less effort on the part of the programmer than C.
>That would be equivalent to asserting that Michael Jordan
>with a 50 pound weight on his back can play better than
>Michael Jordan without the weight.
Well, it is no help at jumping definetely, but probably won't
affect his shooting and might improve his *body blocking* ;o)
Sometimes-if-code-is-overhead-or-run-time-lib-is-a-matter-of-perspective-ly
yr's
--
Rodrigo Senra
Computer Engineer (GPr Sistemas Ltda) rods...@correionet.com.br
MSc Student of Reflection (IC- UNICAMP) Rodrig...@ic.unicamp.br
http://www.ic.unicamp.br/~921234 (see also http://www.gpr.com.br)
Mike Coffin
> There is no way that a Java program can be faster than the equivalent C
> program, on the same computer, if the best practices and idioms of each
> language are followed.
Why? Speed depends, first, on how much effort is put into the
compiler and run-time system, and, second, on the semantics of the
language---issues like aliasing, garbage collection, run-time
checking, etc. As far as effort goes, there is a lot going into Java
compilers; more than C compilers I would guess. Techniques like
dynamic optimization, which are almost never applied to C, are common
for Java. As far as language semantics goes, it's a mixed bag: Java
has some features that make life harder and some that make life
easier. Mandated run-time checks make Java compilers a little harder.
The absence of pointer arithmetic and function pointers, and the
aliasing that comes with it, make things a lot easier. Garbage
collection can cut either way, depending on the program.
So I ask again: why is there "no way"?
-mike
Courageous
>> There is no way that a Java program can be faster than the equivalent C
>> program, on the same computer, if the best practices and idioms of each
>> language are followed.
>
I think this poster was referring to the fact that most JVMs are
written in C, necessarily creating a bit of a chicken and the egg
problem. Which isn't to rule out all sorts of other possibilities,
of course. :)
C//
Mike Coffin
> >> There is no way that a Java program can be faster than the equivalent C
> >> program, on the same computer, if the best practices and idioms of each
> >> language are followed.
> >
> >Why?
>
> I think this poster was referring to the fact that most JVMs are
> written in C, necessarily creating a bit of a chicken and the egg
> problem. Which isn't to rule out all sorts of other possibilities,
> of course. :)
Maybe I came in late and missed something, but the statement I quoted
doesn't seem to be talking about which came first. The fact that C
came first and is used to write JVM's has nothing to do with their
relative speed.
It's perfectly possible to write a compiler that generates much faster
code than the code the compiler itself is running. E.g., there is
nothing to prevent someone from writing a very good C compiler in
Python. It might generate such good code that recompiling Python with
it would speed up the original compiler.
-mike
Delaney, Timothy
> Benchmarks may show a lot of things, but they can't show that
> Java can be
> MORE efficient than ANSI C, controlling for other variables.
[Michael Jordan analogy, 50 pound weight]
This really is not a correct analogy. Source code can be massaged into
better forms. Michael Jordan is already in about the best form a human can
be in ;)
> There is no way that a Java program can be faster than the
> equivalent C
> program, on the same computer, if the best practices and
> idioms of each
> language are followed. Of course a skilled programmer using
> Java (or Visual
> Basic, for that matter) can write more efficient code than a bad C
> programmer, but that's comparing programmers, not languages.
Well, yes and no. When you get to comparing the best programmers of C and
Java, it comes down less to the programmer, and more the the programmer of
the *compiler/virtual machine*.
Quite simply, a higher-level language provides more opportunities for
optimisations. These are often optimisations which are *only* available at
*runtime*. In a statically-compiled language, these optimisations are not
available. Doesn't matter how aggressively a compiler optimises, it can't
see the runtime characteristics of the program. In some (usually quite rare
cases) these runtime optimisations are sufficient for a Java program in a
*very* good VM to beat a C program. Programmer optimisations actually
restrict the capabilities for the compiler/VM to to the same thing in a
better way when the better way is available on a particular platform. Take
for example the following code ...
for i = 1 to 10000
do something
A simple way of partially unrolling this loop would be
for i = 1 to 1000
do something
do something
do something
do something
do something
do something
do something
do something
do something
do something
No problems - this should be faster because we don't need to increment the
loop counter, right?
Now consider a hypothetical architecture which can deal with simple loops
*very* efficiently. Perhaps any loop with a simple counter and of no less
than a certain size (say 5 lines of the above pseudocode) can be loaded into
a dedicated part of memory and run over extremely quickly.
Bang. Your optimisation (partial unrolling) just killed the possibility of
using that optimisation that you didn't know about.
Tim Delaney
Avaya Australia
+61 2 9532 9079
Suchandra Thapa
>
>>> There is no way that a Java program can be faster than the equivalent C
>>> program, on the same computer, if the best practices and idioms of each
>>> language are followed.
>>
>
>I think this poster was referring to the fact that most JVMs are
>written in C, necessarily creating a bit of a chicken and the egg
>problem. Which isn't to rule out all sorts of other possibilities,
>of course. :)
The original poster seems to miss the possibility that JVMs can
make optimizations based on the runtime behaviour of programs. It may
be possible to get Java apps faster than an equivalent C app by
adding dynamic optimizations to the JVM. I believe HP's experiments
with dynamo, their dynamic optimization program, yielded something like
up to 20% faster execution times. I'm not sure about this but I believe
that using dynamo is pretty common on the pa risc systems since it
gives good performance increases even though it was intended to be a way
of running binaries from an earlier architecture on new pa risc machines.
--
------------------------------------------------------------------
|
Suchandra Thapa | "There are only two kinds of math books.
s-th...@SPAMuchicago.edu | Those you cannot read beyond the first
| sentence, and those you cannot read
| beyond the first page."
| -C.N. Yang
------------------------------------------------------------------
Courageous
>> I think this poster was referring to the fact that most JVMs are
>> written in C, necessarily creating a bit of a chicken and the egg
>> problem. Which isn't to rule out all sorts of other possibilities,
>> of course. :)
>
>doesn't seem to be talking about which came first.
Um. I really don't know the posters original intent, but most arguments
of this sort allude to general tendency of Java users to execute their
java byte codes on a JVM. This JVM is usually written in C. Ergo it
is "impossible" to have faster Java than C, because it's really C which
is doing the execution.
This is forgetting native compilers, and the like, course. This is also
forgetting various advantages one might not use given standard normal
practices in one language and not the other.
It really depends on where you're coming from, I'm sure.
C//
Mike Coffin
It's also forgetting that a JVM contains a compiler. It *isn't*
really C doing the execution. If the JVM is written in C, it is C
doing the compilation. The quality of the code coming out of a
compiler has very little to do with what language the compiler is
written in.
-mike