[gameprogrammer] Re: Fast development over multiple platforms, which language?

  • From: Bob Pendleton <bob@xxxxxxxxxxxxx>
  • To: Gameprogrammer Mailing List <gameprogrammer@xxxxxxxxxxxxx>
  • Date: Tue, 08 Mar 2005 11:13:00 -0600

On Tue, 2005-03-08 at 10:28 +0200, Szasz Pal wrote:
> > First, last I heard was that "Java is slower than C++" is a rumor, and 
> > the only ACTUAL experiment performed showed that they're the same 
> > speed-wise in most things (Java did better in some areas, C++ better in 
> > others, but only by small amounts each time).
> Sorry, I don't want to start a flame about it, but can you give us a 
> link to that only experiment, and can you tell me where was Java faster 
> then C++?
> 
> I read all your posts about hotspots, and runtime compiling to native 
> code, but do you really believe that a code which is fist compiled to 
> byte tocode to some straneg stack-machine, and then compiled again to 
> the native processor CAN be faster then one compiled directly to that 
> native processor??? 

Well yeah. I do believe that. When you compile byte code to native code
you basically treat the byte code as an RPN (Reverse Polish Notation)
intermediate form. So the "compiler" in this case is essentially the
same as the back end of any other compiler. All things being equal code
generated by a Java byte code compiler should be just as fast as code
generated by a direct to native code compiler.

But, (big but here), all compilers are not equal. I am sure that if I
hunted around I could find a pair of compilers, one a direct to native C
++ compiler and the other a Java byte code compiler, for which the Java
compiler generated faster native code than the C++ compiler did for 80%
to 90% of test programs. I am equally as sure that I can find another
pair of compilers such that the C++ compiler generated code that ran
faster than the Java byte code compiler 80% to 90% of the time.

In another life I used to write compilers and one thing I learned is
that you can not look at a language specification and make predictions
about the performance of the language. It really twisted my poor little
mind when I ran across a LISP compiler that consistently generated
floating point numeric code that was faster than the same code generated
by a commercial FORTRAN compiler. I wound up reading that LISP compiler
line for line. It turns out that the guys who wrote that compiler knew a
lot more about compilers than the guys who wrote the FORTRAN compiler.
And, it turns out the LISP is a better language for writing compilers
than assembler (which the FORTRAN compiler was written in).

So yeah, I believe what you asked. But, I don't believe it is the result
of anything inherent in the design of Java or C++.

> And even if Java can be that fast than C++, whil I 
> cannot see any big game written in Java? Everybody is claiming that Java 
> is much easier to work in, then C++, due to the lack of pointers. So if 
> Java is SIMPLER and FASTER, or at least FAST ENOUGH than C++, why there 
> aren't so much java games?

Cause all the game programmers learned C++ in school and when people
asked them what language they used they said C++ and so all the people
who wanted to be game programmers learned C++. Nothing to do with the
language, every thing to do with fashion.

Look, I heard exactly the same arguments from old programmers who were
being forced to move from assembly language to FORTRAN. And I heard them
again when software development on PCs moved from assembly to C. And I
heard them again when C++ came out. And I am still hearing the same
arguments. And they still don't mean a damn thing.

> 
> And also, even if java vm can compile to native code, that means the 
> java vm have to be much bigger, in fact it has to be something like and 
> SDK to compile and run the game :-)

Yes and now. It is just the back end of a compiler, not a large piece of
code and the run time libraries. The run time takes up memory no matter
what language you use. The additional space is just not that big.

> 
> I worked a lot with java also, and c++ also. Nowadays I HAVE to work 
> with java, and I can see how bad it can be, mostly due to it's 
> implementations (I'm talking about mobile phones right now).

Yeah... the jvm that is shipping with a lot of cell phones is optimized
for size, not for speed, and the code runs pretty slowly, not to mention
that it is running on slow processors to begin with. OTOH, phones with
hardware java processors (JVM in hardware) are either out now or soon
will be. Phones with a Java chip and the new ATI mobile 3D chip should
rock.

                Bob Pendleton

> 



---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html

Other related posts:

  1. Home
  2. gameprogrammer
  3. Archive
  4. 03-2005