On Mar 6, 2:11=A0pm, mdj  wrote:
> On Mar 6, 4:17=A0pm, apple2fr...{at}gmail.com wrote:
>
> > If you bother to visit the site and compare, for example, the Java 6
> > client (with JIT compiler) to C++ Intel, you will note the following:
>
> > For all 17 benchmarks, Java is never faster than C++, and up to 10x
> > slower.
>
> You mean like in the binary tree benchmark (number is CPU time):
>
> 1.0 =A0 =A0 Java 6 -Xms64m #2 =A0 =A0 =A0 2.89
> 1.5 =A0 =A0 C++ GNU g++ #2 =A04.47
>
> Or the sum-file benchmark:
>
> 1.5 =A0 =A0 Java 6 -server #4 =A0 =A0 =A0 4.10
> 1.5 =A0 =A0 Java 6 -Xms64m #4 =A0 =A0 =A0 4.11
> 2.2 =A0 =A0 C++ Intel #2 =A0 =A06.12
> 2.4 =A0 =A0 C++ GNU g++ #2 =A06.47
>
> Or spectral norm:
>
> 1.0 =A0 =A0 C++ GNU g++ =A0 =A0 23.84
> 1.0 =A0 =A0 Java 6 -Xms64m =A024.01
>
> OK, C++ won that one, and by a whopping 1% too.
>
How about this:

Partial-Sums  9.50s (Java 6 client)
Partial-Sums  1.58s (C++ Intel)

That represents a 501% speed increase

Spectral-Norm  61.22s (Java 6 client)
Spectral-Norm  26.32s (C++ Intel)

That represents a 133% speed increase.

Mandelbrot  4.98s (Java 6 client)
Mandelbrot  3.09s (C++ Intel)

That represents a 61% speed increase.

I could go on, but you get the point.

Conversely, you'll be hard-pressed to find a benchmark where Java
comes out ahead by more than a few percentage points.

> Such is the way with language speed - never assume you're correct,
> always check the numbers.
>
See above.

I have many years of professional programming experience using both C+
+ and Java.  I have run into many skeptics about Java's performance
relative to C++ over the years, but in nearly every case they changed
their minds after benchmarking various piece of code themselves.  Your
best bet here is to point out that this isn't a big deal with today's
processors and memory sizes because the facts don't support your
claims that they are equivalent.

> I'll also facetiously point out that the two benchmarks listed where
> Java wins comprehensively are the only two that do either memory de-
> allocation or disk I/O. parallel non-blocking memory deallocation will
> always beat serialised deallocation for CPU time.
>
You mean like the Partial-Sums benchmark above which does no memory
allocation or disk I/O yet still outperforms the Java version by 501%?

Don't forget to use the Intel C++ compiler if you want to compare
results on an Intel CPU.

> > Here I believe you are wrong. =A0I just loaded up Pages 2008 (Apple's
> > version of MS Word) on my (Intel) Mac. =A0It has a RSS of 77 megabytes,
> > and is, I believe, implemented in Objective C (which is more-or-less
> > equivalent to C++). =A0Next, I loaded up OpenOffice 3.0 (which is
> > implemented in Java) and selected the word processor. =A0It has a RSS o=
f
> > 130 megabytes, which is 69% larger. =A0Both pieces of software implemen=
t
> > approximately equivalent sets of functionality. =A0This is far from the
> > few percent as you suggest.
>
> I wasn't aware OpenOffice was rewritten from its original C++ to
> Java ? It certainly does use Java to implement some extensions, so you
> would get a memory increase from having the JVM loaded, but the lions
> share of the codebase is C++
>
OK, OpenOffice appears to by a hybrid of C++ and Java, so I admit that
this comparison was wrong.  The memory footprints of the benchmarks
still stand, however.

I'm searching for a larger piece of code implemented in both C++ and
Java to make the point.

> Also, how is Objective-C equivalent to C++? In the same way Smalltalk
> is equivalent to Python ?
>
Well, sort of irrelevant give the above, but let me count the ways:

1)  Both were originally implemented as a front end to the C compiler
2)  Both are supersets of the C language
3)  Both support Object Oriented Programming

Where they are different, the difference usually results in Objective
C running slower and using more memory than an equivalent C++ program
(again, see the benchmarks which illustrate this point).

> > > That about runs us out of commercial reasons to prefer C++ over Java.
> > > Of course, for personal projects there's always aesthetics, and it's
> > > pretty obvious we have some different ideas there ;-)
>
> > Language selection will always be a religious issue. =A0C++ has
> > advantages in some areas, and Java in others (especially from a
> > management point of view).
>
> I prefer utilitarian perspectives rather than religious ones for
> language selection, which is to say I believe the problem domain (and
> the existing environment the solution must live in) will provide all
> the necessary metrics to make an informed choice, without having to
> resort to my personal prejudices.
>
Everyone says this, but they pick and choose the data points they look
at which best illustrate their particular conviction.

> > I prefer languages that were designed by programmers for programmers,
> > and are not infected with ideas from committees or management.
> > Ultimately, however, any halfway decent programmer should be able to
> > program in any computer language given a few days to come up to speed
> > with it. =A0Sadly, such a yardstick probably rules out more than 90% of
> > people who call themselves programmers today.
>
> All very true. I don't believe it's any worse than any other industry,
> just another fact of modern life :-S
>
Wasn't true until programming caught on as a profession in the 1980s
or so.

I agree that it's a fact of modern life, and I'm not complaining about
it, just pointing it out because it creates a significant demand for
simple programming languages.

In the end, quantity always seems to win out over quality in the
marketplace.  :|

--
Apple2Freak
--- SBBSecho 2.12-Win32