CPython vs. Jython/JPython

Chris Gehlker gehlker at fastq.com
Sun Nov 5 00:47:05 EST 2000


On 11/4/00 1:16 PM, in article
N8_M5.51390$E85.1371556 at news1.sttls1.wa.home.com, "Greg Jorgensen"
<gregj at pobox.com> wrote:

> "Ingo Adler" <ingo.adler at synacon.ch> wrote in message
> news:39FF4663.A7B5E81E at 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.



-----= 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! =-----



More information about the Python-list mailing list