Re: A 21st Century Apple II?

On Mar 7, 3:11 pm, mdj <mdj....@xxxxxxxxx> wrote:
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

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

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     Java 6 -Xms64m #2       2.89
1.5     C++ GNU g++ #2  4.47
1.7     C++ Intel #2    4.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)  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.

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
.

Relevant Pages

  • Re: Cpp Considered Harmful
    ... >> programming language, the compiler, the IDE, the libraries, etc. ... source file, the implementation shall locate the declaration, (and ... to name one of the defining source files on the command line that initiates ... The counterpart to this in Java is accomplished using the following: ...
    (comp.lang.cpp)
  • Re: wie Array für statische Methoden
    ... > auf gar keinen Fall Java empfehlen;) ... Ich hab mal mit virtuellen Methoden auf einem Microkontroller experimentiert und bin zu dem Schluss gekommen: ... > Es ist ja gerade der Vorteil bei Java einen Compiler ... > Dinge zu optimieren, ...
    (de.comp.lang.java)
  • Re: What is the fastest method of parsing scheme?
    ... These issues can be eliminated by the use of custom memory allocators ... Any other ideas why Scheme would be faster than C++ and Java for heap ... For example, in my compiler, the procedure ) ...
    (comp.lang.scheme)
  • Re: C to Java Byte Code
    ... > Java) cannot do, and you cannot write a compliant Java engine that can ... "I think you would agree with me that a C compiler that directly ... compliant ANSI C compiler are described in MPC's product description." ... these "minor differences" include this requirement: ...
    (comp.programming)
  • Re: HP announces new AlphaServer systems and enhancements to Tru64 UNIX and OpenVMS
    ... > running Linux and using an Intel compiler, the other running HP-UX, ... was more like 30% ahead of the Intel compiler back around the McKinley ... factor for EV7 over the same range, but I specifically referred to scaling ... configuration) SPECfp_rate score is only 8.78x that of the single-processor ...
    (comp.os.vms)