× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



So how many people actually "tweak" their code? Or what are they talking
about when they say "tweak"? Do they want you to start programming to the
platform/OS you are on? If so, there goes your platform independence.

Aaron Bartell
http://mowyourlawn.com

-----Original Message-----
From: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On
Behalf Of Thorbjørn Ravn Andersen
Sent: Thursday, December 06, 2007 11:45 AM
To: Websphere Development Studio Client for iSeries
Subject: Re: [WDSCI-L] WDSC on Mac

Aaron Bartell skrev den 06-12-2007 17:38:
Before bashing Java on its speed, you need to measure ;-) There is

nothing preventing a Java implementation from having reasonable
performance.


I am not entirely following you here, or rather, don't want to drawn the
conclusion spinning in my head.

While we all know Java has gained some excellent performance in recent
releases (I remember hearing of some big ones in 1.5) I don't think it can
hold a candle to a same process written in a lower level language,
correct?
Sure, you can beef up your hardware to appease the Java gods running apps
on
your machine, but wouldn't the equivalent piece of C/C++ more often than
not
run much faster?

Very short: Modern Java implementations is comparable with C and C++ in
terms of speed.

Jacob Marner researched the subject in 2002 and wrote a report named
"Evaluating Java for Game Development" (Google knows where to find the
PDF) where he discuss the state back then (Java 1.4 with HotSpot is
included).

His conclusion was:
==
"In contrary to popular belief Java applications are in fact not much
slower than C++ applications when they have been tuned for performance.
A rough estimate based on the various benchmarks would say that tweaked
Java code is a little slower than C++, typically 20-50% on the average,
but this is hard to tell for certain because of the large variations in
the speed seen in the benchmarks. The slowdown is less in 3D
applications where performance mostly depends on the performance of the
3D hardware and not on the programming language used.

For untweaked code Java is much slower than C++, often a factor of
three and four. This makes it vital to tweak the performance critical
sections of Java code.

Java increases the overall productivity of a software project with about
30% and the productivity of the code phase with about 65%. This is
quite a significant increase."
==

I believe that many of the issues that needs to be tweaked has been
improved in the last 5 years, as they were issues in HotSpot.

There is still the warmup time which should be dealt with similar to the
way that the classic OS/400 JVM do - namely by storing the result for
the next runs.

Memory usage is quite another chapter - perhaps this will shrink
dramatically if Hotspot is only needed once when changing and not for
additional runs.



When all the above is said and done, it makes MY life much easier that I
do not explicitly have to deal with memory. I just create objects when
needed, and set the variables to null when done with them, and they
magically get cleaned.



Only problem is that it is not trivial to port good C to good Java.


Couldn't they just port the C? I would guess that would be much less
work,
but I could be wrong.

They probably could, but that turns the problem into maintaining some C
code on numerous platforms instead of just the Java code.

Given the choice I know what I prefer. Besides - IBM probably has a
C->Java compiler hidden in the labs somewhere anyway :)

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.