On Mar 7, 3:11=A0pm, mdj  wrote:
> On Mar 6, 9:48=A0pm, apple2fr...{at}gmail.com wrote:
>
> > Spectral-Norm =A061.22s (Java 6 client)
> > Spectral-Norm =A026.32s (C++ Intel)
>
> > That represents a 133% speed increase.
>
> Actually, as I posted above, the results for this bench were:
>
> 1.0 =A0 =A0 Java 6 -Xms64m #2 =A0 =A0 =A0 2.89
> 1.5 =A0 =A0 C++ GNU g++ #2 =A04.47
>
Actually, if you use the Java 6 server, with an initial heap size of
64 megabytes, the results are:

Java 6 -Xms64m  24.00s

Which is actually 9.6% better than the C++ Intel compiler.

However, not only is this running the Java server version, as opposed
to the much more ubiquitous client version, but it also involves
passing a hint to the JVM telling to to preallocate 64 megabytes of
memory.  Is this a fair comparison?  It all depends on your point of
view.  I used the Java 6 client without any hints as the basis for my
comparisons, and in that case, the C++ intel compiler generally
significantly outperformed it.

> Well sure, if you don't actually *read* the benchmarks and see what
> the results are you can pretend they say whatever you like ;-)
>
Now you're getting a little testy here.  I did in fact read the
benchmarks which you specifically picked to illustrate your point.  I
responded with specific benchmarks using the Java 6 client because I
think that is much more representative of what the average person will
use in order to run Java programs.  And the benchmarks I picked
illustrate my point quite clearly.

> > 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 :-)
>
Exactly.  And you are just as guilty of this as I am, despite your
belief otherwise.

> > I have many years of professional programming experience using both C+
> > + and Java. =A0I 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. =A0You=
r
> > 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.
>
And I rebuked your assertion, provided evidence to support my
refutation, and showed that the difference is often significant enough
to rule Java out in performance sensitive applications.

> > 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.
>
Not at all.

Guess which platform Sun MIcrosystems has spent the most time
optimizing Java for?  Common sense dictates it is the ubiquitous Intel
platform, and a friend at Sun confirms this.

Why would Intel make a C/C++ compiler for their hardware if the GNU
compiler was already good enough?  Again, common sense dictates that
they would only produce one if it could significantly outperform the
GNU compiler, which it generally does.

> Let's look at the binary tree benchmark from above (again) :
>
> 1.0 =A0 =A0 Java 6 -Xms64m #2 =A0 =A0 =A0 2.89
> 1.5 =A0 =A0 C++ GNU g++ #2 =A04.47
> 1.7 =A0 =A0 C++ Intel #2 =A0 =A04.87
>
If you want to compare the performance of the GNU compiler versus the
Intel compiler, then look at the average performance across all
benchmarks for the GNU compiler and the Intel compiler.  If you do the
math, you'll see that the Intel compiler is significantly faster.
Congratulations, you have located a statistical anomaly above.

> 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?
>
Yes, as I pointed out above.

> > > 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) =A0Both were originally implemented as a front end to the C compiler
> > 2) =A0Both are supersets of the C language
> > 3) =A0Both support Object Oriented Programming
>
> Point 2) here is false, and point 3) is an oversimplification.
>
You asserted that point 2 is false, but provided no evidence to
support your assertion.

You claim that point 3 is an oversimplification, but do not state how
that affects my claim that Objective C is slower and less memory
efficient than C++.

> > 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
>
Open Office is a hybrid of C++ and Java.  Pages is Objective C.  My
comparison was invalid, and as soon as I realized that Open Office was
a hybrid, I admitted this and retracted my claims related to it.  Why
do you insist on continuing to bring it up?

> > > 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 :-)
>
Indeed.  Whether one or both of us does this is left as an exercise to
the reader.

Unfortunately, Google does not allow me to set the followups for this
post, so it persists on csa2 despite the fact that it is completely
off-topic.  Moreover, it detracts from the original point of the
thread which was to solicit ideas for a 21st century Apple II.
Therefore, please feel free to get in the last word on the subject if
that is what you desire and then I hope you will have the common
courtesy to drop it.

--
Apple2Freak
--- SBBSecho 2.12-Win32