[TriLUG] Re: Managed languages (was .NET development on Linux)

[Rick DeNatale]

On Fri, 2004-06-18 at 08:49 -0400, Christopher L Merrill wrote:
> Brian Henning wrote:
> > Java is slow(er) because it's interpreted---whereas a compiled language such
> > as C gets turned into machine code that the CPU itself understands, Java is
> > compiled into object code that must be translated into machine code at
> > runtime by the JVM.
> 
> I think your information is out-of-date.  While the early JVMs used a
> simple bytecode interpreter, they have grown very sophisticated over
> the past few years - using jit-in-time compilation and on-the-fly
> optimization of bottlenecks.  Since it can observe the run-time
> characteristics of the code (unlike a C++ compiler), it can perform
> optimizations not possible in the compiler (or so I've been told).
> 
> The result is that Java is as fast as C++...and sometimes faster:
>    http://sys-con.com/story/?storyid=45250&DE=1

First, in the interest of disclosure, I've been working for a certain
very large computer company for 30 years and a couple of weeks now. For
at least 20 years of that, I've been involved in Object Oriented
Languages. I went from designing an Objective-C like hybrid C language
(in parallel with and ignorant of Brad Cox's work) and then to being a
Smalltalk user and advocate including acting as the Secretary of the
X3J20 commitee which wrote the Smalltalk standard.

Somewhere back in the late 1980s I was involved in doing a technical due
diligence effort when the aforementioned large computer company was
looking at an alliance with a somewhat smaller personal computer company
which was developing a new software system for the next generation of
their MAChines which was being written as a C++ framework.

Two of the issues they were facing were how to manage memory and
performance. The memory management issues were addressed by developing
project rules to determine which module was responsible for freeing
objects, along with a smart pointer library to implement those rules.

The problem was that there was a substantial performance overhead in
doing  memory management, whether it was with reference counting, or
using copy constructors to get an object to survive a call boundary.

As a fan of dynamic oo languages, I was bemused to observe that they
were paying (at least) the performance penalty of a garbage collector
without getting the benefit of cleaner code.

The technical decisions on the alliance hinged more on which processor
and os kernel was to be used in the new MAChines. The result was that
the framework project was spun off as a jointly owned company which
eventually petered out with the key personnel getting absorbed into the
company I work for, while the new MAChine ended up using one of our
processor architectures.

One of the big benefits of a Virtual Machine based language such as
Smalltalk, or Java is that since features like GC and byte-code
interpretation become clear performance bottlenecks, the performance
improvements from working to optimize those bottlenecks on a system-wide
basis can be impressive.

And performance can be non-intuitive. Even interpretation of byte-codes
can be win in some cases when the larger size of machine code causes
poor virtual memory performance. This was brought home to me when
Digitalk came out with a version of Smalltalk-V which directly compiled
everything to machine code, and found that it actually performed worse
than byte-code interpretation due to the increased working set size.
Multi-levels of interpretation, which reserve code expansion to heavily
used sections of code, something which was done back in later Smalltalk-
80 implementations can be quite effective, and led to the JIT techiques
and other used in Java today. 

> When a GUI seems non-responsive, it's the programmer's fault.  I've
> written a lot of Java GUIs...and they can be very snappy if written
> correctly.  

Yep, I've seen plenty of less than snappy GUIs written in C or C++, and
similar apps written in Perl/TK which are much faster. Performance is
affected by good design, and particularly tuning given a reasonable
design, much more than the choice of language. 

Donald Knuth (am I showing my age?) said that "premature optimization is
the root of all evil." If someone thinks that optimization is done via
the choice of language, a very early step in software development, has
fallen prey to the voice of the devil! <G>

> I don't mean spending hours to optimize each part of the
> GUI -- the programmer simply needs to understand Swing's MVC
> architecture and design accordingly.  It's actually pretty easy.

And Swing ain't necessarily the best choice for a Java GUI
architecture/library. Actually some big pieces of Swing were contributed
by some of the same folks who were working on the C++ framework I
discussed above. 

A progenitor of the Eclipse IDE was written using Swing, one of the lead
Eclipse UI designers is one of the gang of four pattern guys, and a
graduate of the spun-off C++ framework company, who is lesser well known
as a very good Swiss skier.

I'll always remember a presentation on the UI design for the IDE which
he gave about the time the switch was made away from Swing. It included
a slide he took while on a chair lift of a sign on the slope below with
an icon of a skier falling from the chair lift with the words below:

  DON'T SWING