[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.
>
> 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.
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; if you want maximum
performance, however, remember that in Java, code needs to be in effect
compiled twice.
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...
>
> 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
___________________________________________________
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.
