KDE should strive for better java support to gain more developers.

[Peter Qusec]

-------- Original-Nachricht --------
> Datum: Mon, 28 Apr 2008 09:30:38 +0200
> Von: Mitch <mitch074 at gmail.com>
> An: kde at mail.kde.org
> 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.