Re: A 21st Century Apple II?

[mdj <mdj.mdj@gmail.com>]

On Mar 6, 9:48 pm, apple2fr...@gmail.com 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