Re: A 21st Century Apple II?

On Mar 6, 9:48 pm, apple2fr...@xxxxxxxxx wrote:

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

That represents a 133% speed increase.

Actually, as I posted above, the results for this bench were:

1.0 Java 6 -Xms64m #2 2.89
1.5 C++ GNU g++ #2 4.47

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

That represents a 61% speed increase.

And this:

C++ Intel #4 2.54
Java 6 -server #3 3.24
Java 6 -server 3.25

I could go on, but you get the point.

Well sure, if you don't actually *read* the benchmarks and see what
the results are you can pretend they say whatever you like ;-)

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

See partial sums above, which you ignored when I posted it, then went
and looked for worse numbers that illustrated your point.

But whatever. Believe what you like :-)

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 didn't claim they were equivalent. I challenged your assertion that C
++ is always faster, provided evidence to the contrary, and showed
that the difference is not significant enough in most cases to use
performance as a selection criteria.

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.

Why? I'm sure in some cases the GNU compiler produces better results.
That's just faith based reasoning.

Let's look at the binary tree benchmark from above (again) :

1.0 Java 6 -Xms64m #2 2.89
1.5 C++ GNU g++ #2 4.47
1.7 C++ Intel #2 4.87

So here we have a comprehensive victory for Java, and the Intel
compiler being outperformed by the GNU compiler on Intel hardware.

Seriously, did you actually *read* these tests before posting them?

Here I believe you are wrong.  I just loaded up Pages 2008 (Apple's
version of MS Word) on my (Intel) Mac.  It has a RSS of 77 megabytes,
and is, I believe, implemented in Objective C (which is more-or-less
equivalent to C++).  Next, I loaded up OpenOffice 3.0 (which is
implemented in Java) and selected the word processor.  It has a RSS of
130 megabytes, which is 69% larger.  Both pieces of software implement
approximately equivalent sets of functionality.  This 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

Point 2) here is false, and point 3) is an oversimplification.

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).

And of course, this is supported by Pages being smaller and faster
than Open Office :-P

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.

Well, one of us clearly does :-)

Matt
.

Relevant Pages

  • Re: forth and virtual memory
    ... too, maybe even the same order, so ordering the blocks by allocation ... on systems with too little memory ... What Java is known for, and what it actually does, are two distinct ... My measurements indicate that some of the benchmarks (from SpecJVM98, ...
    (comp.lang.forth)
  • Re: A 21st Century Apple II?
    ... For all 17 benchmarks, Java is never faster than C++, and up to 10x ... Java wins comprehensively are the only two that do either memory de- ... Language selection will always be a religious issue. ...
    (comp.sys.apple2)
  • Re: Is Borland QA *really* lacking?
    ... I have run Delphi/Java benchmarks with some people. ... sometimes Delphi was faster, sometimes Java, sometimes roughly equivalent. ... > but memory is cheap these days. ...
    (borland.public.delphi.non-technical)
  • Re: A 21st Century Apple II?
    ... across one that showed Java being faster than C or C++? ... To the extent that these benchmarks demonstrate anything useful (which ... Java uses from 4 to 35 times more memory than ... As a selection criteria, it's also useless. ...
    (comp.sys.apple2)
  • Re: Choice of two boards and CPUs
    ... In terms of memory driving capabilities at stock speeds, the Intel ... of memory on the Intel will cause fewer headaches than on the Athlon64. ... There are plenty of benchmarks around the net. ...
    (alt.comp.periphs.mainboard.asus)