[NTLUG:Discuss] Transport tool - opinions

[Stephen Davidson]

Greg Edwards wrote:
> Stephen Davidson wrote:
> 
> 
> Sorry Stephen but that dog won't hunt!
> 
> I don't want to start a religious war here but, no Java is NOT in the 
> performance league that C is in.  Yes Java is well ahead of Perl and 
> Tcl/Tk but I'm not sure on Python or Ruby.  Java is closer to C++ in 
> performance but that's because their both Object Oriented languages.
No offense taken.  But there are some errors of information that I would like to correct.  The errors in question are more to do with out-dated information than any actual intent to cause conflict.

> 
> I read that article and the testing was skewed toward a major weakness 
> in C involving dynamic memory.  Java (and other OOP languages) do 
> internal heap management while C relies on the OS.  C does not give you 
> dynamic memory management automatically because that is a tool not a 
> feature.  The advantage to the C approach is that if you don't need it 
> then your program is not burdened with the overhead.  The disadvantage 
> is that if you do need it you have to write it, or use one you've 
> already written.
I thought I mentioned that this was an older article, relavant only to JDK 1.3, which in general was slower than C (sorry for the confusion).  Any articles on performance predating 2002 (and early 
2002), do not relate to JDK 1.4, only the earlier Java Versions.  I don't immediately have the links for the up-to-date performance analysises, although one of them was over at www.sys-con.com, I 
believe.  And I will readily agree that the older the Java version, the slower it ran.  I will even go so far as to agree that except in special cases (like the one you just mentioned), C was always 
faster than Java.

> 
> Java has two major issues that cannot be overcome when compared to C. 
> First Java is OO and C is not.  Second Java is interpreted and C is not. 
>  Even compiled Java is interpreted at some levels.  Any language that 
> does data type binding and/or operand overload binding at run time is by 
> default interpreted.  Any OO language will have the disadvantage of an 
> expanded stack for function calls.  Passing call by value objects (OO's 
> default) is simply more expensive than call by reference.
That is why the early versions of Java was slow.
What many non-Java programmers do not realize is that Java is now (and has been for some time) compiling its byte-codes down to machine executable native to the platform that it is running on.  And on 
some platforms, storing the compiled binaries on Harddisk (not Sun JVM, unfortunately, but some of the IBM JVMs do this).  Furthermore, the byte-code compilation to machine code is being optimized by 
the JVM for the specific platform in question.
And a new feature (that many Java Programmer's are only now starting to learn about), is the Runtime Profiler.  By default, it takes about 50 passes over a block of code before it kicks in, but then 
it examines what has been going on with that block of code, and starts optimizing.  Some of the "tricks" that it pulls are the removal of security access checks, bypassing of data-type checks, coding 
in the specific operand (so as not to deal with the overloaded operand issues, just uses the specific one), function inlining when possible, just to name a few.  A visit to Sun's website if your 
interested in more details would be recommended.  And if possible, check out the slides from last year's JavaOne.  There were several presentations on this topic.
As for passing call values, Java does EVERYTHING by reference.  The only values that it passes internal are the dozen or so "Primitive" types, like int, float, long, boolean.  The only time it does by 
value is when you are doing RMI (Remote Method Invocation), at which point, you start Serializing objects, and yes, that IS expensive (although steps have been taken to speed that up as well).

The end result of all of this is that unless you are a top notch C-Coder that knows all the optimizing tricks, and WHEN TO USE THEM, the Java code will be at least as fast at the C code.  And as many 
people are aware, optimizing source code does nasty things to the code's readibilty, which does not help debugging or enhancements down the line.  (If you are such a person, than yes, your C-code will 
  always be faster than any Java code - special cases excluded).

> 
> Yes object oriented languages have advantages over procedural languages 
> but the first price paid for those advantages is program performance. 
> The same type of performance issues exist in the debate between 
> assembler and C.  If you really want the best program performance 
> Assembler is a better choice than C which is better than C++ which is 
> better than Java which is better than .......  For pure number crunching 
> Fortran is better than C and APL is better than Fortran for matrix work.
In general, agreed.
> 
> Don't get me wrong I think OOP has it's place and is a very valuable 
> tool.  But Java is NOT the single solution that many want to see.  Sorry 
> but the single language solution is a pipe dream that will not happen. 
> Java may well be the correct single language internet browser client 
> side solution but that is only one piece of a very big puzzle.
> 
I believe that Chris Cox addressed this point quite well in an earlier email on this thread.  For quick jobs, or small to medium jobs, Java does have a fair amount of overhead.  It is Multi-Threaded, 
which takes up some overhead.  Both the JIT and the Runtime Profiler take up resources as well, and there are finite limits as to how much they can optimize the executing code.  Obviously, the smaller 
the project, the less they can affect it.  But conversely, the larger the project, the more impact they would have.

There are other places where Java would be inappropriate as well(having spent the last 7 months writing Java-C interfaces, I really have to say that!).  For instance, unless a micro-device or 
controller-board is Java Based, you would need to use a native interface to talk to it.  (Its the controller-board instance I have been dealing with for the last several months).

But for larger projects, or especially GUI projects, I would seriously consider looking at Java.  While the initial AWT Graphics library was horrid (I don't think you will find any java programmers 
that say its excellent), the newer Swing Graphics library has many nice and easy to use widgets(generally, there are a few nasty exceptions, but I would not even want to think about how to code some 
of them in C).  And, as Chris mentioned, Java scales very well.

And another point to consider, and many companies are now looking at this so hard that vendors are starting to make this move;
When you write code in C, or Fortran, or any other compiled language, your binaries are limited to the platform that you compiled them for, and in many cases, designed them on.  Many programs written 
for Linux won't run on anything but Linux, and most won't run on any other platform (including in many cases, Linux distros that they were not compiled on), without a recompile.  In many cases, you 
even need to modify the code in order to get it to compile on a completely different platform (M$, AS400, AIX for a few).
Currently, at will, I switch between developing on my Linux laptop and a Win2K workstation.  Binaries (should really call them Object files, I suppose, since they are not normally run as they are 
except when debugging) produced on one are perfectly executable on the other.  I don't need to worry about which Window's version the code is going for, or if it is even a Windows platform.  The only 
thing I do need to worry about is if the platform specific device controller libraries that this particular application uses are present.  In the past, I have written code on a Win98 box that has, 
without a recompile, run on WinNT, AS400, HPUnix, Unisys R4, RedHat Linux, and SCO UnixWare.

Many people when they think about Java miss this last point.  One code base, multiple platforms.  How nice it would be if Quake or Unreal would run on all platforms, instead of just some versions of 
Windows and Mac.  And as of JDK 1.4 (which also includes the ability to directly access OpenGL, as well as something about direct access to Video Ram), first person shooters are now possible in Java.

Regards
Steve

-- 
Java/J2EE Developer/Integrator
214-724-7741
Looking for a new opportunity