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++?
Jun 27 '08
318  10712 
Mark Thornton <mt*******@optrak.co.ukwrote:
The VM spec is also separate from the language spec, which is a good
thing. It's just a shame that the name "Java" applies to the platform,
the runtime, and the language.
And at times several other things with no obvious relationship at the
whim of Sun's marketing department. I seem to recall that the meaning of
.NET has had a few iterations as well.
Oh yes indeed :) It's now mostly stabilised - although *exactly* what
LINQ means has taken over as the "less well defined" term in my view :)
--
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
On Wed, 4 Jun 2008 21:41:50 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
>I love the way you go straight from "most likely" to an absolute
assertion that the speed *is* at the cost of correctness.
That's pretty good assumption given that C# gets the wrong answer for
1e7, 1e10, 1e15
On Wed, 4 Jun 2008 21:56:00 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
>Fair enough. One interesting point I've found is that if you tell
InputStreamReader to use UTF-8, it works *much* more slowly than if you
use the default encoding (on my box, anyway).
On the other hand, if you tell InputStreamReader "ISO-8859-1" it gets
slightly faster
sumcol < sum.txt
10500000
Time: 5033
Jon Skeet wrote:
My previous experiences with Cygwin have been far from great - I'd
rather not install it at all.
I'm not addressing Razzi, as I don't see his posts anymore, but I do
want to pipe up about Cygwin.
Cygwin works very well as long as you treat it almost like a terminal to
another operating system. Using the command-line utilities in a console
window running cmd.exe is usually a waste of time. Running bash in rxvt,
with an appropriately-configured ~/.bash{rc,_profile} etc. and
~/.Xdefaults (for rxvt settings), and it's a pleasure - so long as you
enjoy the Unix experience and want to replicate it on Windows.
With an appropriately constructed user/profile directory, you can get
almost identical shell experiences across most OSes.
-- Barry
-- http://barrkel.blogspot.com/
Razii wrote:
I love the way you go straight from "most likely" to an absolute
assertion that the speed is at the cost of correctness.
That's pretty good assumption given that C# gets the wrong answer for
1e7, 1e10, 1e15
Anything using input values like that for sines is bound to get
inaccurate answers. Anyone understanding a bit about floating point
values knows that it is simply foolish to try to find the sine of such
values and still expect any accuracy.
I also wonder why one would want to do this. It doesn't make any sense.
--
Rudy Velthuis http://rvelthuis.de
"A fast word about oral contraception. I asked a girl to go to
bed with me, she said 'no'." -- Woody Allen
Mark Thornton <mt*******@optrak.co.ukwrote:
Fair enough. One interesting point I've found is that if you tell
InputStreamReader to use UTF-8, it works *much* more slowly than if you
use the default encoding (on my box, anyway).
That isn't too surprising as you are most likely using a single byte
encoding by default. Decoding these is rather trivial.
Indeed - although decoding UTF-8 is fairly easy when all the characters
happen to be ASCII. Still an extra branch, mind you.
I should have posted what surprised me: forcing .NET to use a single
byte encoding when reading the file doesn't improve the speed by much.
Trying to change the encoding for stdin with .NET is slightly trickier
- instead of using Console.In, you need to use
Console.OpenStandardInput to get a stream, then wrap that.
However, your post prompted me to do precisely that - and funnily
enough, that then means the reader via stdin is roughly as fast as
reading directly from the file; significantly faster than using
Console.In. I wonder what Console.In is doing to slow it down...
(Another nail in the coffin of the claim that ".NET is twice as slow as
Java" though, and a handy thing to know should I ever be in the
unlikely situation of dealing with large amounts of data piped through
stdin.)
--
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 Skeet [C# MVP] wrote:
This is probably why .NET went the "quick" route - because no-one
realistically should be dealing with radian values that large in the
first place.
Indeed.
--
Rudy Velthuis http://rvelthuis.de
"There are only two ways to live your life. One is as though
nothing is a miracle. The other is as though everything is a
miracle." -- Albert Einstein (1879-1955)
On Wed, 04 Jun 2008 14:17:27 -0700, "Rudy Velthuis"
<ne********@rvelthuis.dewrote:
>I also wonder why one would want to do this. It doesn't make any sense.
How about
Console.WriteLine(Math.Sin (Math.PI));
The value of sine for the floating-point number Math.PI is around
1.2246467991473532E-16 (should be)
1.22460635382238E-16 (C#)
Jon Skeet [C# MVP] wrote:
Mark Thornton <mt*******@optrak.co.ukwrote:
>>Fair enough. One interesting point I've found is that if you tell
However, your post prompted me to do precisely that - and funnily
enough, that then means the reader via stdin is roughly as fast as
reading directly from the file; significantly faster than using
Console.In. I wonder what Console.In is doing to slow it down...
Possibly some form of cooked mode --- synchronization with Console.out.
>
(Another nail in the coffin of the claim that ".NET is twice as slow as
Java" though,
I don't see much in these benchmarks of the sort of code where the more
mature HotSpot JIT could be expected to outshine .NET.
Mark Thornton
On Wed, 4 Jun 2008 22:21:31 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
>(Another nail in the coffin of the claim that ".NET is twice as slow as
Java" though, and a handy thing to know should I ever be in the
unlikely situation of dealing with large amounts of data piped through
stdin.)
It's is much slower if using
StreamTokenizer lineTokenizer = new StreamTokenizer(System.in);
Post the version that makes it faster....
What about binarytrees? http://shootout.alioth.debian.org/gp...ng=csharp&id=0 http://shootout.alioth.debian.org/gp...ng=javaxx&id=2
Use the command line
java -server -Xms64m binarytrees 20 \NULL
C# is twice slower.
Rudy Velthuis wrote:
Razii wrote:
>>I love the way you go straight from "most likely" to an absolute
assertion that the speed is at the cost of correctness.
That's pretty good assumption given that C# gets the wrong answer for
1e7, 1e10, 1e15
Anything using input values like that for sines is bound to get
inaccurate answers. Anyone understanding a bit about floating point
values knows that it is simply foolish to try to find the sine of such
values and still expect any accuracy.
I also wonder why one would want to do this. It doesn't make any sense.
While I agree that it is unlikely to have any application in physics or
engineering, sometimes mathematicians do find good reasons for computing
apparently unlikely values. After all there was once a time when
computations on 500+ bit integers would have been considered of no
practical use. Now our security depends on such work.
Before Java, the accuracy of many trig libraries was rather
underspecified. Java's specification may be too strict, but at least it
has one.
Mark Thornton
On Wed, 04 Jun 2008 14:24:07 -0700, "Rudy Velthuis"
<ne********@rvelthuis.dewrote:
>This is probably why .NET went the "quick" route - because no-one
realistically should be dealing with radian values that large in the
first place.
Indeed.
Skeet is wrong. It's not just limited to large values. C# just uses
the hardware fsin/fcos values. The value of sine for the
floating-point number Math.PI is around
1.2246467991473532E-16
1.22460635382238E-16 (C# -- same answer as returned by fsin)
Are you telling us that C# is a bad choice for software that must be
platform independent? On different hardware the answer would be
different if you are using C#.
Mark Thornton <mt*******@optrak.co.ukwrote:
(Another nail in the coffin of the claim that ".NET is twice as slow as
Java" though,
I don't see much in these benchmarks of the sort of code where the more
mature HotSpot JIT could be expected to outshine .NET.
Indeed. As I said before, it's pretty easy to construct code where Java
*does* outperform C#:
VirtualTest.cs:
using System;
using System.Diagnostics;
public class VirtualTest
{
const int Iterations = 1000000000;
static void Main()
{
Stopwatch sw = Stopwatch.StartNew();
VirtualTest t = new VirtualTest();
int sum=0;
for (int i=0; i < Iterations; i++)
{
sum += t.GetNumber();
}
Console.WriteLine(sw.ElapsedMilliseconds);
}
public virtual int GetNumber()
{
return 1;
}
}
VirtualTest.java:
public class VirtualTest
{
private static final int Iterations = 1000000000;
public static void main(String[] args)
{
long start = System.currentTimeMillis();
VirtualTest t = new VirtualTest();
int sum=0;
for (int i=0; i < Iterations; i++)
{
sum += t.GetNumber();
}
long end = System.currentTimeMillis();
System.out.println(end-start);
}
public int GetNumber()
{
return 1;
}
}
As it is, Java outperforms .NET (on my box) by about 3:1.
Making GetNumber non-virtual, and .NET outperforms Java (on my box)
about about 2:1.
Pointless benchmark, of course, other than to show the inlining
capabilities of Hotspot in the face of a virtual method which hasn't
been overridden.
--
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
On Wed, 04 Jun 2008 22:13:49 +0100, Barry Kelly
<ba***********@gmail.comwrote:
>I'm not addressing Razzi, as I don't see his posts anymore, but I do
want to pipe up about Cygwin.
You definitely see my posts because my email changes with every post.
Stop lying.
Razii <ni****@mail.comwrote:
On Wed, 4 Jun 2008 22:21:31 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
(Another nail in the coffin of the claim that ".NET is twice as slow as
Java" though, and a handy thing to know should I ever be in the
unlikely situation of dealing with large amounts of data piped through
stdin.)
It's is much slower if using
StreamTokenizer lineTokenizer = new StreamTokenizer(System.in);
That was the version I originally had in Java though - and on my box
that runs at about the same speed as the C# version using
Console.OpenStandardInput() instead of Console.In.
What about binarytrees?
http://shootout.alioth.debian.org/gp...ng=csharp&id=0
http://shootout.alioth.debian.org/gp...ng=javaxx&id=2
I haven't looked at it yet - one step at a time. Let's try to conclude
sumcol before moving on.
You still haven't posted your results when loading files rather than
reading via the console.
--
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
Mark Thornton <mt*******@optrak.co.ukwrote:
I also wonder why one would want to do this. It doesn't make any sense.
While I agree that it is unlikely to have any application in physics or
engineering, sometimes mathematicians do find good reasons for computing
apparently unlikely values. After all there was once a time when
computations on 500+ bit integers would have been considered of no
practical use. Now our security depends on such work.
True. I think there's a significant difference between integer
arithmetic and floating point - but I agree it's hard to predict the
future.
Before Java, the accuracy of many trig libraries was rather
underspecified. Java's specification may be too strict, but at least it
has one.
Oh indeed. The fact that there's both Math and StrictMath is
particularly nice. It would be interesting to see a port of StrictMath
for .NET.
--
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
Razii <ni*********@mail.comwrote:
This is probably why .NET went the "quick" route - because no-one
realistically should be dealing with radian values that large in the
first place.
Indeed.
Skeet is wrong. It's not just limited to large values. C# just uses
the hardware fsin/fcos values. The value of sine for the
floating-point number Math.PI is around
1.2246467991473532E-16
1.22460635382238E-16 (C# -- same answer as returned by fsin)
Are you telling us that C# is a bad choice for software that must be
platform independent? On different hardware the answer would be
different if you are using C#.
If you need bit-for-bit reproducability for all calculations, then I
certainly agree that C# is unsuitable. Aside from the Math library
calls, the CLI spec allows for a runtime to use higher precision for
arithmetic where it wishes to. See section 12.1.3 of ECMA-335 for more
information and a rationale.
--
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
On Wed, 4 Jun 2008 23:03:59 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
>You still haven't posted your results when loading files rather than
reading via the console.
Changing the lines to :
BufferedInputStream in = new BufferedInputStream (new FileInputStream
("sum.txt"));
StreamTokenizer lineTokenizer = new StreamTokenizer(in);
I get 4.519s which is slightly slower than using System.in: 4.224s
Razii <ni*******@mail.comwrote:
On Wed, 04 Jun 2008 22:13:49 +0100, Barry Kelly
<ba***********@gmail.comwrote:
I'm not addressing Razzi, as I don't see his posts anymore, but I do
want to pipe up about Cygwin.
You definitely see my posts because my email changes with every post.
And it's completely inconceivable to you that a newsreader could filter
just on name, and not on email address?
Forte Agent, the newsreader Barry uses (by his headers, at least) has
precisely this capability. I've just tried it, and verified that it
filters out all of your posts.
Now, of course you *could* change your name as well as your email
address for every post - but there's really no legitimate reason for
doing that, and no point in irritating people just for the sake of it.
Heck, why do you even change email address each time?
--
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
Razii <ni*********@mail.comwrote:
On Wed, 4 Jun 2008 23:03:59 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
You still haven't posted your results when loading files rather than
reading via the console.
Changing the lines to :
BufferedInputStream in = new BufferedInputStream (new FileInputStream
("sum.txt"));
StreamTokenizer lineTokenizer = new StreamTokenizer(in);
I get 4.519s which is slightly slower than using System.in: 4.224s
That's changing the Java code. Now what about the C# code - and is that
with the big file, or the original benchmark way of creating thousands
of processes?
--
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
On Wed, 4 Jun 2008 23:07:29 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
>Oh indeed. The fact that there's both Math and StrictMath is
particularly nice. It would be interesting to see a port of StrictMath
for .NET.
Since 1.4 Math just calls StrictMath for sin and cos. That's how sin
and cos got slower since 1.4. However, there is solution to it. http://pastebin.com/f126f0c27
Mark Thornton wrote:
I also wonder why one would want to do this. It doesn't make any
sense.
While I agree that it is unlikely to have any application in physics
or engineering, sometimes mathematicians do find good reasons for
computing apparently unlikely values.
No doubt. But any mathematician knowing anything how floating point
numbers are implemented would think twice before doing that using
"double precision", i.e. 8 byte floating point values.
--
Rudy Velthuis http://rvelthuis.de
"There are only two tragedies in life: one is not getting what
one wants, and the other is getting it."
-- Oscar Wilde (1854-1900)
Razii wrote:
Skeet is wrong. It's not just limited to large values. C# just uses
the hardware fsin/fcos values. The value of sine for the
floating-point number Math.PI is around
1.2246467991473532E-16
1.22460635382238E-16 (C# -- same answer as returned by fsin)
Are you telling us that C# is a bad choice for software that must be
platform independent?
I am telling that the combination of double precision (8 byte, with 52
bits for the mantissa) floating point values with such large values is
simply a bad one.
Of course .NET uses the hardware FPU on an x86 or x64 system.
Since the error you see for Pi is ~1e-16, which is in 52nd bit of the
mantissa (before normalization), that is excellent. Since for values
close to 0 one can say that sin(x) = x, this means the error is as
small as can be, using a mantissa of 52 bits. IOW, a more accurate
result is impossible with a mantissa of 52 bits.
If you want higher precision, don't use the builtin routines. These
were not designed for that, just like the builtin math routines for
most languages I know. I'm sure C, C++, Delphi etc. would give you
similar results, on an x86.
I just tried with C++, and indeed, I get the same result.
--
Rudy Velthuis http://rvelthuis.de
"Wit makes its own welcome and levels all distinctions."
-- Ralph Waldo Emerson (1803-1882)
"Razii" <ni*******@mail.comwrote in message
news:j9********************************@4ax.com...
On Wed, 04 Jun 2008 22:13:49 +0100, Barry Kelly
<ba***********@gmail.comwrote:
>>I'm not addressing Razzi, as I don't see his posts anymore, but I do
want to pipe up about Cygwin.
You definitely see my posts because my email changes with every post.
Stop lying.
Voila , Ratboy , The definitive troll...
.... hmm... apologies.. I interrupted the battle of the trolls.. Ok...trolls
.... please feel free to continue...
regards
Andy Little
On Wed, 4 Jun 2008 23:25:27 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
>That's changing the Java code. Now what about the C# code - and is that
with the big file, or the original benchmark way of creating thousands
of processes?
The original benchmark uses this file http://shootout.alioth.debian.org/do...mcol-input.txt
made 21,000 times bigger. Basically, concatenate the above file 21,000
times, and you have the same file that I and shootout site do.
As for C# using file, post the changes.
On Wed, 04 Jun 2008 15:56:46 -0700, "Rudy Velthuis"
<ne********@rvelthuis.dewrote:
>If you want higher precision, don't use the builtin routines.
That was not the point. The point was that you get different answers
on different hardware. So the speed in this case comes at the cost
that software may behave differently on different hardware. True or
false? It may not make difference in most cases, but still the answer
is inconsistent. Furthermore, Java version can be made 2x faster by
using custom FastMath class as I showed.
So we are done with this partialsums benchmark; this was the only case
where C# was significantly faster.
Razii wrote:
On Wed, 04 Jun 2008 15:56:46 -0700, "Rudy Velthuis"
<ne********@rvelthuis.dewrote:
If you want higher precision, don't use the builtin routines.
That was not the point. The point was that you get different answers
on different hardware. So the speed in this case comes at the cost
that software may behave differently on different hardware.
That is the cost of using the available FPU, indeed. The alternative is
using a library that does everything in code. Not feasible for many
applications, I'd guess. Note that C and C++ also use the available
hardware.
--
Rudy Velthuis http://rvelthuis.de
"The nourishment is palatable" -- Emily Dickinson, dying words
On Wed, 04 Jun 2008 21:01:56 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>>>revcomp:
C#: 1.2s
Java: 1.5s
Post the link to the code.
That was C# directly from the shootout.
Earlier you said that revcomp was slower and you need to look at it.
How did it become faster if it's directly from the site? If you added
a buffer, keep in mind the rule is that you can't read more than 82
bytes/chars at a time. If you made the buffer larger than that, then
change this line
byte[] line = new byte[82]
to something like byte[] line = new byte[18432]
Razii wrote:
On Wed, 04 Jun 2008 21:01:56 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>>Actually I don't need to because the existing F# code is already fast:
F#: 2.7s
Java: 2.4s
Did you use -server -Xms64m flag?
Yes.
.NET is twice slower.
No.
--
Dr Jon D Harrop, Flying Frog Consultancy http://www.ffconsultancy.com/products/?u
Razii wrote:
On Wed, 04 Jun 2008 21:01:56 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>>>>revcomp:
C#: 1.2s
Java: 1.5s
Post the link to the code.
That was C# directly from the shootout.
Earlier you said that revcomp was slower and you need to look at it.
That is not true.
--
Dr Jon D Harrop, Flying Frog Consultancy http://www.ffconsultancy.com/products/?u
Jon Skeet [C# MVP] wrote:
Mark Thornton <mt*******@optrak.co.ukwrote:
(Another nail in the coffin of the claim that ".NET is twice as slow as
Java" though,
I don't see much in these benchmarks of the sort of code where the more
mature HotSpot JIT could be expected to outshine .NET.
Indeed. As I said before, it's pretty easy to construct code where Java
*does* outperform C#:
...
As it is, Java outperforms .NET...
That is Java outperforming C#, not .NET.
--
Dr Jon D Harrop, Flying Frog Consultancy http://www.ffconsultancy.com/products/?u
On Thu, 05 Jun 2008 01:53:41 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote
>.NET is twice slower.
No.
It is twice slower on my computer, and, in this case, since there is
no input-file, Cygwin is invalid excuse. Also, in this case, you did
say several times that .NET is slower, but the benchmark is flawed.
You just changed your claim suddenly.
On Thu, 05 Jun 2008 01:57:11 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>There is no significant performance difference between the F# and Java.
Post the code and tell me how to compile.
On Thu, 05 Jun 2008 01:56:10 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>C# is twice slower.
Use F#.
You haven't posted anything for me to comment.
Razii <ni*********@mail.comwrote:
On Wed, 4 Jun 2008 23:25:27 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
That's changing the Java code. Now what about the C# code - and is that
with the big file, or the original benchmark way of creating thousands
of processes?
The original benchmark uses this file
http://shootout.alioth.debian.org/do...mcol-input.txt
made 21,000 times bigger. Basically, concatenate the above file 21,000
times, and you have the same file that I and shootout site do.
As for C# using file, post the changes.
I did, early yesterday evening. I posted both a Java *and* a C# program
which allowed you to either pipe input to the program *or* provide a
filename.
I also posted the results of running said code - C# was slower than
Java when reading from stdin (at the time using Console.In - using
OpenStandardInput narrows the gap) and about the same as Java when
reading directly from a file.
--
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 <jo*@ffconsultancy.comwrote:
Jon Skeet [C# MVP] wrote:
Mark Thornton <mt*******@optrak.co.ukwrote:
(Another nail in the coffin of the claim that ".NET is twice as slow as
Java" though,
I don't see much in these benchmarks of the sort of code where the more
mature HotSpot JIT could be expected to outshine .NET.
Indeed. As I said before, it's pretty easy to construct code where Java
*does* outperform C#:
...
As it is, Java outperforms .NET...
That is Java outperforming C#, not .NET.
No, it's Java outperforming .NET calling a virtual method. It has
nothing to do with the code that the IL is generated in: if you have a
virtual method which isn't overridden, the .NET CLR will not inline
calls to it. The Hotspot VM will inline it until it first sees the
method being overridden. The difference here is in the jitting model,
not in the language.
Try it in F#, ensuring that the method is virtual and actually called
each time (consider that the method might be one which has side-
effects). I can't see how it would possibly have a different result.
--
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
Razii <ni*******@mail.comwrote:
<snip>
So we are done with this partialsums benchmark; this was the only case
where C# was significantly faster.
And I for one have never been claiming that .NET or C# is significantly
faster than Java overall. (If any benchmarks made custom calls to
native code, that would be interesting. I really have no idea how JNI
compares with P/Invoke in terms of speed. I know which is more pleasant
to use, mind you :)
Given how similar their overall approach is, and how both of them have
had a lot of time and money spent optimising their VMs (with more work
to be done, for sure) it's unsurprising that they're pretty much a tie.
My conclusion: don't choose between Java and .NET on performance
grounds. There are far better reasons to choose one or the other,
depending on other criteria.
--
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
Razii wrote:
So we are done with this partialsums benchmark; this was the only case
where C# was significantly faster.
And Mersenne Twister, where F# is also 2x faster than Java.
--
Dr Jon D Harrop, Flying Frog Consultancy http://www.ffconsultancy.com/products/?u
Razii wrote:
On Thu, 05 Jun 2008 01:53:41 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote
>>.NET is twice slower.
No.
It is twice slower on my computer, and, in this case, since there is
no input-file, Cygwin is invalid excuse.
This benchmark (revcomp) is completely IO bound and running it within Cygwin
with emulated Unix pipes will certainly affect performance.
Also, in this case, you did say several times that .NET is slower, but the
benchmark is flawed. You just changed your claim suddenly.
..NET is 13% slower not 2x slower.
I think we have been over the same thing enough times now. There is no
longer any evidence that Java is significantly faster. There are now no
benchmarks where Java is even 2x faster than .NET. All you had to do was
optimize the .NET code and run it properly (without emulation).
--
Dr Jon D Harrop, Flying Frog Consultancy http://www.ffconsultancy.com/products/?u
Razii wrote:
On Thu, 05 Jun 2008 01:56:10 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>>C# is twice slower.
Use F#.
You haven't posted anything for me to comment.
The fast .NET code is already on the shootout site (again).
--
Dr Jon D Harrop, Flying Frog Consultancy http://www.ffconsultancy.com/products/?u
Razii wrote:
On Thu, 05 Jun 2008 01:57:11 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>>There is no significant performance difference between the F# and Java.
Post the code and tell me how to compile.
Again, the fast .NET code (and compilation instructions) are already on the
shootout site. There is nothing for me to do (except tell you the same
thing over and over).
--
Dr Jon D Harrop, Flying Frog Consultancy http://www.ffconsultancy.com/products/?u
Jon Skeet [C# MVP] wrote:
Jon Harrop <jo*@ffconsultancy.comwrote:
>That is Java outperforming C#, not .NET.
No, it's Java outperforming .NET calling a virtual method. It has
nothing to do with the code that the IL is generated in: if you have a
virtual method which isn't overridden, the .NET CLR will not inline
calls to it. The Hotspot VM will inline it until it first sees the
method being overridden. The difference here is in the jitting model,
not in the language.
Try it in F#, ensuring that the method is virtual and actually called
each time (consider that the method might be one which has side-
effects). I can't see how it would possibly have a different result.
This optimization can obviously be done statically by the compiler. There is
no assurance that F# will also fail to optimize this, particularly if you
write a functional equivalent:
let iters = 1000000000
let main f =
let mutable sum = 0
for i=0 to iters-1 do
sum <- sum + f()
do
time main (fun () -1)
If F# does fail to optimize it, mark "main" as "inline".
--
Dr Jon D Harrop, Flying Frog Consultancy http://www.ffconsultancy.com/products/?u
Jon Harrop wrote:
Jon Skeet [C# MVP] wrote:
Jon Harrop <jo*@ffconsultancy.comwrote:
That is Java outperforming C#, not .NET.
No, it's Java outperforming .NET calling a virtual method. It has
nothing to do with the code that the IL is generated in: if you have a
virtual method which isn't overridden, the .NET CLR will not inline
calls to it. The Hotspot VM will inline it until it first sees the
method being overridden. The difference here is in the jitting model,
not in the language.
Try it in F#, ensuring that the method is virtual and actually called
each time (consider that the method might be one which has side-
effects). I can't see how it would possibly have a different result.
This optimization can obviously be done statically by the compiler.
No - this optimization cannot be done statically for runtimes that
support dynamic code loading, as the CLR and JVM do. If the compiler
tries to replace 'callvirt' with 'call', the assembly will no longer be
verifiable, and if the assembly is dynamically loaded into the context
of another application, the virtual call semantics will be violated.
For example:
---8<---
using System;
public class B
{
public virtual void M()
{
Console.WriteLine("Hello from B");
}
}
public class App
{
static void Main()
{
CallM(new B());
}
public static void CallM(B instance)
{
instance.M();
}
}
--->8---
Compile this App.cs to App.exe, then disassemble with:
ildasm App.exe /out:App.il
Then edit App.il so that CallM is written thusly, applying the
"optimization":
---8<---
.method public hidebysig static void CallM(class B 'instance') cil
managed
{
// Code size 9 (0x9)
.maxstack 8
IL_0000: nop
IL_0001: ldarg.0
IL_0002: call instance void B::M()
// (above was 'callvirt')
IL_0007: nop
IL_0008: ret
} // end of method App::CallM
--->8---
Assemble with:
ilasm App.il
Verify with:
peverify App.exe
Observe error:
---8<---
Microsoft (R) .NET Framework PE Verifier. Version 3.5.21022.8
Copyright (c) Microsoft Corporation. All rights reserved.
[IL]: Error: [c:\proj\cli-callvirt\App.exe : App::CallM][offset
0x00000002] The 'this' parameter to the call must be the calling
method's 'this' parameter.
1 Error Verifying App.exe
--->8---
For a concrete example of virtual method call semantic violation,
consider a second application, App2.cs:
---8<---
using System;
public class D : B
{
public override void M()
{
Console.WriteLine("Hello from D!");
}
}
class App2
{
static void Main()
{
App.CallM(new D());
}
}
--->8---
Compile this with:
csc App2.cs /r:App.exe
Run App2.exe when App.exe is the version assembled from App.il modified
to use call instead of callvirt, and observe:
---8<---
Hello from B
--->8---
Recompile the original App.cs from source, then run App2, and observe:
---8<---
Hello from D!
--->8---
- the "obvious optimization" has broken virtual method call semantics.
Implementing the "optimization" for strictly private classes is not
useful either, as reflection with appropriate permissions, along with
runtime code generation, can see through such visibility constraints.
-- Barry
-- http://barrkel.blogspot.com/
On Thu, 05 Jun 2008 10:59:58 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>Again, the fast .NET code (and compilation instructions) are already on the
shootout site. There is nothing for me to do (except tell you the same
thing over and over).
F# was much slower than C# and slowest of all...
$ time binarytreesf 20 (F#)
stretch tree of depth 21 check: -1
2097152 trees of depth 4 check: -2097152
524288 trees of depth 6 check: -524288
131072 trees of depth 8 check: -131072
32768 trees of depth 10 check: -32768
8192 trees of depth 12 check: -8192
2048 trees of depth 14 check: -2048
512 trees of depth 16 check: -512
128 trees of depth 18 check: -128
32 trees of depth 20 check: -32
long lived tree of depth 20 check: -1
real 1m16.180s
user 0m0.000s
sys 0m0.046s
$ time binarytrees 20 (C#)
stretch tree of depth 21 check: -1
2097152 trees of depth 4 check: -2097152
524288 trees of depth 6 check: -524288
131072 trees of depth 8 check: -131072
32768 trees of depth 10 check: -32768
8192 trees of depth 12 check: -8192
2048 trees of depth 14 check: -2048
512 trees of depth 16 check: -512
128 trees of depth 18 check: -128
32 trees of depth 20 check: -32
long lived tree of depth 20 check: -1
real 0m54.618s
user 0m0.000s
sys 0m0.031s
$ time java -server -Xms64m binarytrees 20 (Java)
stretch tree of depth 21 check: -1
2097152 trees of depth 4 check: -2097152
524288 trees of depth 6 check: -524288
131072 trees of depth 8 check: -131072
32768 trees of depth 10 check: -32768
8192 trees of depth 12 check: -8192
2048 trees of depth 14 check: -2048
512 trees of depth 16 check: -512
128 trees of depth 18 check: -128
32 trees of depth 20 check: -32
long lived tree of depth 20 check: -1
real 0m36.328s
user 0m0.031s
sys 0m0.046s
On Thu, 05 Jun 2008 10:58:53 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>The fast .NET code is already on the shootout site (again).
I tested it and it's slowest.
On Thu, 05 Jun 2008 10:58:10 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>This benchmark (revcomp) is completely IO bound and running it within Cygwin
with emulated Unix pipes will certainly affect performance.
I tested it and there is no difference in timing. Also, the "emulated
Unix pipes" is the same for both side.
On Thu, 05 Jun 2008 10:54:33 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>And Mersenne Twister, where F# is also 2x faster than Java.
It's empty claim since we have no chance to look at the code. The link
you gave was broken.
I wonder why Harpo doesn't post the link? Perhaps he knows the claim
will be debunked if we have a chance to optimize?
On Thu, 5 Jun 2008 06:22:50 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
>And I for one have never been claiming that .NET or C# is significantly
faster than Java overall. (If any benchmarks made custom calls to
native code, that would be interesting. I really have no idea how JNI
compares with P/Invoke in terms of speed. I know which is more pleasant
to use, mind you :)
This benchmark uses JNI to call libGMP http://shootout.alioth.debian.org/gp...igits&lang=all This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: tech |
last post by:
Hi, i have the following problem
In file1.h
namespace A
{
class Bar
{
void foo();
|
by: King Raz |
last post by:
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 ...
...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
