benchmarks? java vs .net

[King Raz]

The shootout site has benchmarks comparing different languages. It
includes C# Mono vs Java but not C# .NET vs Java. So I went through
all the benchmark on the site ...

http://kingrazi.blogspot.com/2008/05...enchmarks.html

Just to keep the post on topic for my friends at comp.lang.c++, how do
I play default windows sounds with C++?

[Razii]

On Tue, 10 Jun 2008 20:17:08 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:

>If you are claiming that F# is 4 times faster than C# even though both
are running on .NET. then your results are not credible.

For completely different programs?

Your version is slightly slower than C#. Post it again.

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Rudy Velthuis wrote:

Arne Vajhøj wrote:

>>IOW, there are arguments for both approaches. The GC one has the big
advantage that one big cause of errors, all errors regarding memory
use, are more or less completely eliminated. But I doubt I would
call speed one of the main factors to choose a GC.

Actually GC speed is very good.

The problem people complain over is the non deterministic
aspect of it.

People also complained about messaging and the non-linear aspect of it
when they moved from DOS to Windows. I guess, to many, this is a
similar issue, i.e. they sense a loss of control. <g>

That is most certainly something that causes a lot of C++ programmers
going to Java or C# to feel uncomfortable.

Arne

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Jon Harrop wrote:

Arne Vajhøj wrote:

>Jon Harrop wrote:

>>Razii wrote:
On Wed, 04 Jun 2008 20:34:59 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
You are still timing Cygwin's implementation of Unix pipes which has
nothing to do with anything.
I am still waiting for you to verify and demonstrate it has any
effect.
Your inexplicably anomalous results already proved that.

For anyone with just a minimum of understanding of logic: not.

My Cygwin-free results are up to 4x faster than Razii's Cygwin-burdened
results. How else do you explain that?

May I suggest you enroll in a university where they teach science.

The fact that you can not find another explanation does
not prove anything.

Arne

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Jon Harrop wrote:

Arne Vajhøj wrote:

>Or why do you think the Cygwin stuff can explain the difference in the two
tests?

According to Razii, Cygwin is the only significant difference between our
setups. From my results, we know Razii's results for .NET are up to 4x
slower than they should be. Therefore, Cygwin is the only logical
explanation.

And you think that Cygwin slows down .NET x4 but not Java ?

It is possible. But I find it very likely that there is another
explanation.

And if you want to know why, then try and write a time utility
(in any language) that shows that behavior.

Arne

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Jon Harrop wrote:

Arne Vajhøj wrote:

>Jon Harrop wrote:

>>You are ignoring all of the overheads of a GC, like thread
synchronization, stack walking and limitations placed upon the code
generator required to keep the GC happy.

I would expect non-GC solutions to need more thread synchronization
than GC because it will need it many more times.

That is just more unfounded speculation.

Since it contains an argument then you can hardly call it unfounded.

Arne

[=?UTF-8?B?QXJuZSBWYWpow7hq?=]

Lew wrote:

Razii <py******@gmail.comwrote:

>>>situation. Many options are available to tune GC

http://java.sun.com/javase/technolog.../vmoptions.jsp

Jon Skeet [C# MVP] wrote:

>>... and it's rarely the case that it's worth tuning them, in my
experience. There are exceptions, of course, but my initial
instinctive reaction is to leave the defaults as they are.

Mark Thornton wrote:

>It is worthwhile selecting one of the low pause collectors if that is
what you need. If you know you will need a 500MB heap then you can
save a bit of time by setting the minimum size to 500MB (this doesn't
save as much time as it used to).

Likewise it is worthwhile switching to a parallel collector in a
multiprocessor environment.

Jon's experience must be limited. Where I work they tune the GC quite
carefully for their various application suites. They definitely find it
worthwhile, given the high volumes they process.

It should be common knowledge that Jon has quite some Java experience.

But far from all Java developers work with memory tuning.

For Java SE apps it is rarely necessary.

For Java EE apps memory tuning is often done by the server
experts and not by the developers.

Arne

[Jon Harrop]

Arne Vajhøj wrote:

Jon Harrop wrote:

>Arne Vajhøj wrote:

>>Jon Harrop wrote:
You are ignoring all of the overheads of a GC, like thread
synchronization, stack walking and limitations placed upon the code
generator required to keep the GC happy.

I would expect non-GC solutions to need more thread synchronization
than GC because it will need it many more times.

That is just more unfounded speculation.

Since it contains an argument then you can hardly call it unfounded.

If you want to argue that point then you need to explain why you believe
that GC'd programs do less thread synchronization.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

[Jon Skeet [C# MVP]]

Arne Vajh?j <ar**@vajhoej.dkwrote:

Jon's experience must be limited. Where I work they tune the GC quite
carefully for their various application suites. They definitely find it
worthwhile, given the high volumes they process.

It should be common knowledge that Jon has quite some Java experience.

But far from all Java developers work with memory tuning.

For Java SE apps it is rarely necessary.

For Java EE apps memory tuning is often done by the server
experts and not by the developers.

One thing which *does* affect the discussion is which version of Java
you're using - it's been a while since I've used anything before
Java 5, which is when the defaults became significantly better.

--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[Jon Harrop]

Arne Vajhøj wrote:

May I suggest you enroll in a university where they teach science.

http://www.ffconsultancy.com/free/thesis.html

The fact that you can not find another explanation does not prove
anything.

We eventually found an alternative explanation: Razii had been lying about
his results. He had never even managed to compile the optimized .NET
programs I provided, let alone benchmark them.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u