Re: A 21st Century Apple II?

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

On Mar 7, 10:51 pm, apple2fr...@gmail.com wrote:
> On Mar 7, 3:11 pm, mdj <mdj....@gmail.com> wrote:> 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
>
> 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.

By that reasoning, a better indication of C++ performance could be had
by running the compiler in debug mode, rather than optimising mode.
The options you mention aren't alternative versions, but options for
controlling the behavior of the JVM. Yes, this does have a dramatic
impact on execution speed, just as optimisation options do in any
programming language.

You'll find that shipping Java programs make extensive use of such
switches to tailor the VM's behavior to the programs domain. I my view
this is an excellent progression, since many esoteric optimisations
can be left out of code, making it more readable and thus
maintainable.

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

The only point you've made is that one environment with the optimiser
turned on can beat another with the optimiser turned off.

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

My selection metric was simple: display all the results, and pick the
best result for each language, and use that as the basis for
comparision. Fairly obviously, if it's performance we want to compare,
this is the only useful metric.

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

No, you have not shown that at all. Choosing results from a non-
optimised configuration does not illustrate anything useful to
"performance sensitive applications" whatsoever.

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

And that's exactly it. If you do the math and compare the best results
of the two languages you'll see that your entire conclusion is based
upon such a statistical anomaly.

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

I think I'm just going to let the fact that you challenged those
assertions stand as its own evidence.

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

I tend to find that threads that become large and develop digressions
are good indicators of the level of interest in the original point and
don't find it particularly bothersome to filter out that which I
consider "noise". And whilst it may be considered an unwanted by some
the fact remains that if you stand on a public soapbox, you are going
to be heckled by the crowd. For future reference you might find it
easier to simply retract a fallacious remark then to continue to argue
it, particularly in light of your "most programmers today are crap"
position.

Over the last two weekends, I have replaced ceilings in two rooms of
our house, using the traditional hardwood tongue and groove materials.
Everything was done to period, but using pneumatic nail guns and power
saws, resorting only to hand tools when they would produce a superior
result. Whilst we could have insisted on cutting every miter with a
tenon saw, and hammering in every nail the old fashioned way, doing so
would not have improved the final outcome at all, but added
considerably to the time and effort.

To me, this comparison of C++ to Java is just like this, and whilst
picking one or the other might make the process more 'enjoyable'
depending on your prejudices, to me it's most important to focus on
the quality of the deliverable, not the process.

Of course, I too share the desire to enjoy the process, but that's
what my Apple II's are for. Applying this thinking to two "modern"
tools isn't going to benefit me, or my customers, and will ultimately
detract greatly from the level of professionalism that working in
"modern" environments demands.

Matt