Disgraceful Tradeoffs

Posted Mar 4, 2004 12:47 UTC (Thu) by lmartelli (subscriber, #11755) [Link]

Others arise directly from the language definition, making it impossible to optimize as fully as if source code were available. The language itself interferes with optimization, as well, so that Gcj (which compiles to native code) cannot optimize as well as a good (e.g.) C++ compiler can.

Do you have any pointers explaining precisely why Java cannot be optimized as well as C/C++?

Surely you've noticed that your programs run much more slowly than the equivalent C++ program? Doesn't running half as fast, achieving half as many transactions-per-second, taking twice as long to finish, costing twice as much, or needing twice the processing power, count as crippled?

Should I understand that any program written in a "scripting" language (Perl, Python, PHP, Tcl,...) is equally crippled? Java implementations are currently slower than C/C++ ones. But it gets better every day. And in many situations, being twice as slow to execute is not a problem, as long as its fast enough. Especially if I can cut down developpement time by half by avoiding memory mangement debbuging issues. And not have to care about a whole range of security issues caused by buffer overflows. And in application involving a database, the database can often be the bottleneck, so I'd rather spend a little time optimising the DB rather than a lot more time copping with C/C++'s problems.

Its exception apparatus adds enormously to the textual overhead needed to handle errors, without making programs correspondingly more robust or simple to maintain.

I'm not a bug fan of Java's exception handling and would prefer that almost all exceptions are runtime exceptions so that you don't have to declate them in your interfaces.

Its enforced garbage collection means that you have little control over the memory management, and general resource management, needed to tune performance and compensate for the poor low-level performance of the JVM. The garbage collection interferes with cache locality, so that programs often run from main memory instead of from cache, at an enormous speed penalty.

The analysis also suggests that, as locality becomes ever more important to program performance, programs written in garbage-collected languages may turn out to have significant performance advantage over programs written in more conventional languages.

As implementation techniques improve, the overhead has been reduced substantially, a 10 percent overhead of the overall execution time is reasonable for an well-implemented system [Wilson, 1994]

Surely C/C++/Asm give you more control, but how much do you win and at what cost ? Most programmers are not competent enough to properly and efficiently manage memory in a complex application, so a GC is the best way of doing things for the great majority of programs. Giving the programmer too much low level controls is the best way to obtain a program which cannot be optimized properly by a compiler/VM because it won't be able to know which low level instructions are just an optimization attempt by the programmer and which are a functionnal requirement. Asm gives you even more control than C++, yet is not used anymore. Because we found it was better to let a compiler optimize register allocation rather than have human beings obscuring source code trying to do it by hand. We'd have better programs if all the talented programers who spent some time crafting custom memory allocation schemes for thousands of programs, and debugging them, had dedicated some time improving GC algorithms and implementations.

I do not see how a GC interfers with general resource management.

And what is an enormous speed penalty exactly ?

You still haven't convinced me that Java programs are unavoidably crippled by language-design choices meant to serve proprietary companies' need to distribute closed binaries.