Re: Help me!! Why java is so popular

On Feb 11, 4:25 pm, Arne Vajhøj <a...@xxxxxxxxxx> wrote:
Chris Uppal wrote:
Arne Vajhøj wrote:
We are impressed by your argumentation technique.

You are basically arguing that "Java is slow because it is slow".

I don't think he is, you know.

He is arguing that Java performance is less than C/C++
performance based on an assumption that the JIT compilation
runtime overhead is bigger than the JIT over AOT gain.

No, I'm assuming it takes longer to translate a thing and run it, than
it does to skip translation and just run it. I think that's a fair
assumption.

BTW, this is not a C/C++ vs Java competition. I'd write something in
native assembler taking advantage of every facet of the hardware if
that's what I needed to do. The fact is I code in Java, C, C++, Perl
and a smidgeon of other things (COBOL, Shell script, and visual basic
to name a few) these days. I like them all for certain things, and
they each have drawbacks for other things.

Just wanted to make sure I was clear on where I stand.


To me that is basing the conclusion on an assumption that
is equivalent to the conclusion.

Arne

If you want to be 100% accurate, what I said was if you have to
translate code to run it, then eliminating the translation step would
cause the code to run faster.

Java has to be translated before you run it.

I believe these two statements are true. You can ding me and say you
translate Java once and then it can be cached or wathever, and that's
fine, but at load time it has to be translated. Byte code != native
instruction set.

An assertion was made that late binding can take advantages of the
environment to supply more efficient instructions. That's a theory.
What if the non-translated program is alread optimized for the
environment? Does someone want to suggest a JVM can translate a
program and then perform some magic to make the ALU run faster? Of
course not. Late binding only helps in circumstances where there's an
opportunity to improve by substituting a more efficient set of
instructions. As long as we're comparing apples to oranges then sure,
we can say there's an opportunity for a difference. If we're
comparing apples to apples, adding a translation step is going to be
slower.

Let me put it another way.

Java class abc is invoked for the first time -- we fire up and load
the JVM, abc gets translated to native code and executed -- Java class
abc is invoked again, only this time it's sitting in cache and is
ready to go so it's executed -- which instance of abc's execution ran
faster? I'm claiming the 2nd -- does someone want to argue the 1st
execution is faster? That firing up the JVM, translating the program,
then executing it is faster than just executing it, or just reading it
off disk and executing it?

This is what I'm saying. If these were 2 distinct programs, the 2nd
should win every time (ignoring interrupts, system activity, etc)
because we're comparing apples to apples.

FWIW, some of the late-binding advantage can be simulated with
reasonably simple code in any language. For instance an installation
script could check installed hardware and deploy the best from several
versions, or I could build a run-time hardware checker/loader to pull
code from a different DLL based on environments. I have created code
to do these kinds of things. It's not out of the box functionality,
but it's not very difficult either.

Also, a JVM can pay attention to usage, provide caching, adapt at run
time, etc., but such a service requires space and processing cycles to
supply. That means *potentially* it could make a single processing
unit it serves run faster or maybe not, but the service's computations
come at the expense of the operating environment as a whole. Most
comparisons focus on a single program's execution, but the resources
consumed by the JVM to look for runtime optimizations are resources
unavailable to other processes in the operating environment. How much
I don't know, but computational knowledge requires memory to store and
processor cycles to access. I do know large Java apps running on my
workstation will "blackout" (eg become unresponsive to mouse clicks),
and I don't experience the same from my C, C++ or Perl scripts -- I
presumed garbage collection was running, but maybe it's the JVM
looking for ways to run its apps and classes faster. 8-)

One other thing that I believe hurts Java's runtime environment is the
built-in unicode support. I have no use for unicode in my
applications, but Java stores everything as unicode, right? So that
means twice as much memory, and the need to convert from ASCII or
EBCDIC into and out of unicode, over and over again, and for nothing.
Is there are really good reason for mandatory unicode support? This
hurts Java's runtime model, IMO, and it's pointless if you don't need
it.

Anyway, this is a really interesting discussion to me. I think the
fact there's a discussion at all is a very big compliment to the
software engineers constructing the JVMs. They're obviously good.

.

Relevant Pages

  • Re: Java 1.5-5 and System.getProperty("user.home")
    ... System.getPropertyand JVM returns 'DEFAULT'! ... $ java "Home" ... Will use interpreter. ... The content of SYS$LOGIN may not translate as expected, ...
    (comp.os.vms)
  • Re: Help me!! Why java is so popular
    ... I think Arne may have taken my language as ... negative towards Java. ... loading the JVM so that I can turn around and do a recursive tree ... assuming it takes longer to translate a thing and run it, ...
    (comp.lang.java.programmer)
  • Re: Repost: Cancel stored procedure using JDBC
    ... I have a Java application that spawns 4 different threads. ... the database stops execution and replies with an error message. ... When JDBC does not receive an IOException, Oracle Net may eventually time out ... The server-side internal driver runs in the ...
    (comp.lang.java.programmer)
  • Re: JVM vs. EXE comaprison
    ... >> Startup time is added to the benchmark, and as such isnt measuring Java ... > The benchmark clearly is measuring Java execution performance. ...
    (comp.lang.java.programmer)
  • Re: Why FC4 using the Jpackage 1.4.2 Java?
    ... No open source JVM currently exists. ... You can register with Sun and go to Sun's Java sight and freely ... run the Java code optimally on the specific platform. ...
    (Fedora)