Re: [kde] KDE should strive for better java support to gain more developers.


-------- Original-Nachricht --------
Datum: Mon, 28 Apr 2008 09:30:38 +0200
Von: Mitch <mitch074@xxxxxxxxx>
An: kde@xxxxxxxxxxxx
Betreff: Re: [kde] KDE should strive for better java support to gain more developers.

[I'm going to cut some older elements of the discussion, it's getting
too fat)


It might be true that interpreted Java is a dozen times slower c++, but
thanks to the hot spot optimization Java code gets compiled to machine code
on the fly in al the important spots. That really makes a huge difference.
A few years ago I implemented the same data mining algorithm on c++ and
java and while c++ was faster, it was so only by a factor of 2.
But you might be right about the ARM chip. Somebody told me once that
the hot spot optimization could not be used these smaller processor. However,
I can't exactly remember what that reason was.

On the spot optimization requires some hefty CPU power and a bunch of
RAM on the first run; something that small CPUs don't have in abundance
(in short, it would delay app startup too much on these). Thing is, with
C++, optimized once, optimized always - the only way to beat it is
assembly (but then, bye bye portability)
Actually, one of the first version of this application was written in a
way that all the heavy computations would be performed as sql statements
inside an oracle database. That, however, turned out to be far to slow which
is why we reimplemented it completely in Java. We even copied the whole
database to the Java heap space and performed all the computations purely in
Java. And that works now really fast.

Databases are worse than pretty much any language: it is not bytecode,
it's script (and even worse, generic script that need to be translated
to the database's own version) - and depending on the database, some
specific operations may get a _thousand_ times slower than another,
equivalent one: for example, under MySQL 5, the speed difference between
a subquery and a left join on a view (with equivalent results) is a
hundredfold; add to that the difference between prepared statements and
direct to execute queries (if the query is long, prepared statements are
a dozen times faster)... Yes, SQL can be REAL slow.
Yes, it really was. I mean we've used Oracle, prepared statements and even tried to give optimization hints. Nothing helped and worse, it was a complete mess. Maybe there was a trick to make it faster, but we havn't found it.


I specifically meant the memory and CPU overhead imposed by java. Of
coarse its important to write clean code, think through the architecture of
your software and chose the right algorithms for your problems. But there are
a lot of bugs that one can cause in c++ that you can completely forego in
Java. The worst ones I remember were those where you access an array
outside its allocated area. Your program would just crash anywhere and you had to
hunt that bug for days. Such things are just a waste of time.

Aaaah, of course, if you hit under the belt... Joke apart, I understand
what you mean; indeed, you need to build your own security measures in
C/C++, where Java hides it away by returning 0 or null when you hit
outside an array...
I don't mean to be blunt, but if you do that in Java, you may end up
with unreferenced memory blocks all over the place that the garbage
collector will have trouble cleaning up; with time, wasted memory builds
up and your app will first slow down, then crash for no apparent reason.
In C++, with stuff like Coverity's products or the latest GCC, you can
very fast have an overview of where your code is weak.
No. If you access an array outside its range, Java will throw an IndexOutOfBoundException and you know exactly what happend and where it happend. Sure, checking the boundaries costs efficiency, but you gain a lot of stability and security. Buffer overflows are just a nightmare.

There's a reason why the most stable software are programmed in C/C++:
it's worth the hassle.

Optimizing your algorithms has to be done independant of the language
you are using. However the more technical details get into the way the harder
it will be to focus on what the algorithm is actually doing.

Or it depends on the way you go at it: some languages deal with hash
tables better, others may enjoy arrays, some others will be more geared
towards handling object properties, yet others will process
multidimensional arrays better... It all depends on the binary code that
is generated on the other end of the compiler;
No, you don't use an array instead of a hash table just because your programing language supports it better. Searching through an array in linear time where a single hash lookup would have done it just doesn't make sense.

if you want maximum
performance, however, remember that in Java, code needs to be in effect
compiled twice.
Yes, but in Eclipse the first compilation happens while you type in your program. It even shows you interactively the compile errors in your program and usually offers you a menu with a number of choices to solve the problem.

So no, you don't optimize your code independantly to the language you
are using: you optimize your code following the language's strenghts. As
in, you do mostly OOP to the max with Java, you mostly use plain ol'
functions in C/C++.
You know what they say about skinning a cat...

Well yes, you optimize your code following the language's strenghts but to understand and optimize an algorithm its important to get as many technical and implementation details out of the way as possiple. That's why scientific publications usually describe algorithms in pseudo code and not in any programming language. Sure you don't always have to go all the way and write the algorithm in pseudo code first, but abstraction really helps to understand an algorithm.


I was talking about the OpenJDK project.
http://developers.slashdot.org/article.pl?sid=08/04/23/2037220

So did I: IcedTea took what was out of the OpenJDK, added stubs or GCJ
bits where needed, and compiled whatever of Java was ready: it runs,
but, well... A bit like Carl Lewis vs. Frankenstein's creature.

Peter

Mitch

I think you should really try it out yourself. Just download Eclipse and the JDK and write a small programm in it. I mean I have used KDevelop and C++ myself for years, but when I was forced to make the switch to Java, it really opened my eyes. There are so many techniques and features that make software development so much easier under Java. Like design by contract. You specifiy in javadoc the contract for every method (what it expects, what it has to return) and verify it with asserts. Or the toString method that can be added to every class and which will be shown in the debugger.

Peter

--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Relevant Pages

  • Re: [kde] KDE should strive for better java support to gain more developers.
    ... Somebody told me once that the hot spot optimization could not be used these smaller processor. ... I don't mean to be blunt, but if you do that in Java, you may end up ... Optimizing your algorithms has to be done independant of the language you are using. ... is generated on the other end of the compiler; ...
    (KDE)
  • Re: Mars Rover Controlled By Java
    ... > optimizer in 1.4 is quite good at numerical codes too. ... > scale computations, my Java codes perform identical to Fortran codes, ... Even if you compile with optimization? ... For any modern compiler of a 3GL language, ...
    (comp.lang.java)
  • Re: Mars Rover Controlled By Java
    ... > optimizer in 1.4 is quite good at numerical codes too. ... > scale computations, my Java codes perform identical to Fortran codes, ... Even if you compile with optimization? ... For any modern compiler of a 3GL language, ...
    (comp.programming)
  • Re: Mars Rover Controlled By Java
    ... > optimizer in 1.4 is quite good at numerical codes too. ... > scale computations, my Java codes perform identical to Fortran codes, ... Even if you compile with optimization? ... For any modern compiler of a 3GL language, ...
    (comp.lang.java.programmer)
  • Re: Mars Rover Controlled By Java
    ... > optimizer in 1.4 is quite good at numerical codes too. ... > scale computations, my Java codes perform identical to Fortran codes, ... Even if you compile with optimization? ... For any modern compiler of a 3GL language, ...
    (comp.theory)