473,326 Members | 2,127 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

benchmarks? java vs .net

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 10673
Razii wrote:
On Wed, 04 Jun 2008 12:21:39 -0500, Razii <ni*******@mail.comwrote:
>>>sumcol: .NET is 2.5x faster than Java.

Now that I read your other post, I see where you got that from: by
writing custom parser that breaks benchmark rule that program must use
standard library for reading and parsing:
Now you are introducing new subjective "rules" to circumvent problems with
the benchmarks.
I can make Java 3x times faster by writing custom parser.
Congratulations, Java is finally catching up with the optimized .NET code.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jun 27 '08 #101
On Wed, 04 Jun 2008 18:39:59 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>Now you are introducing new subjective "rules" to circumvent problems with
the benchmarks.
I didn't make the rules. That's the rule for this benchmark on
shootout site.
>I can make Java 3x times faster by writing custom parser.

Congratulations, Java is finally catching up with the optimized .NET code.
In other words, .NET is much slower if it uses standard library. It's
about equal if both use use custom parsers.
Jun 27 '08 #102
Razii wrote:
On Wed, 04 Jun 2008 17:53:19 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>>Razii wrote:
>>On Wed, 04 Jun 2008 09:04:01 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
That's the only reason it's faster in partialsums benchmark.

That is pure speculation.

It's not. I posted the evidence. C# gets wrong result.

That says nothing about why it is faster.

It does.
No, you literally said nothing about performance.
http://blogs.sun.com/jag/entry/trans...tal_meditation
Ah, this affects only a legacy architecture but my non-.NET results are from
64-bit Linux.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jun 27 '08 #103
Razii wrote:
On Wed, 04 Jun 2008 17:53:19 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>>Mersenne Twister is freely available. Just time the generation of 10^8
int32s:

Post the link if it's freely available.
Type "Mersenne Twister" into Google and click "I'm feeling lucky" (it is the
first hit). There are implementations in many languages and Java is by far
the slowest of the compiled languages because it generally has very poor
integer performance.
>>Also, you have yet to optimize 4 benchmarks where
.NET is much slower: binarytrees, sum-col, recursive, revcomp.

binarytrees: benchmark is flawed so I can make it as fast as you like.

It's flawed because C# is twice slower? Nice logic.
I have explained in detail on the shootout list why that particular
benchmark is completely flawed. The clue is in the fact that it takes no
significant input and prints trivial output, i.e. there is no need for most
of the internal code that just wastes time building data structures that
are redundant or unused.
>>sumcol: .NET is 2.5x faster than Java.

I don't get that result even after changing it to BufferedStream. It's
2x times slower.
Then you're doing something seriously wrong. I suspect you're not even
running .NET.
>>recursive: .NET is only 20% slower than Java.

revcomp: I have not yet examined. Perhaps this will turn out to be the
only benchmark where Java is significantly faster (but I seriously doubt
it).

you have yet to optimize 4 benchmarks where .NET is much slower:
binarytrees, sum-col, recursive, revcomp.
That has not been true for some time:

binarytrees:
N/A

sumcol:
F#: 0.9s
Java: 0.73s

recursive:
F#: 3.0s
Java: 3.6s

revcomp:
C#: 1.2s
Java: 1.5s

As you can see, .NET is now faster on two (recursive and revcomp) and not
significantly slower on another (sumcol).

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jun 27 '08 #104
Jon Harrop wrote:
Razii wrote:
>Console.WriteLine(Math.Sin (1e15));

0.858272132476373 (C# with .NET)
0.8582727931702358355238863908484 (right answer)

So C# doesn't get 15-17 digit accuracy of double for sin and cos.

For double precision floating point your argument of 1e15 to sin has already
lost all precision because it is fourteen orders of magnitude outside the
primary domain of this trig function.
Sin and cos are defined for all real numbers. Sure Java is rather
unusual in returning accurate results for all values of double (bar
infinite and NaN). While many systems set the bar rather lower, one has
to admire Java for raising it (and eventually delivering).

Mark Thornton
Jun 27 '08 #105
Razii <ni*********@mail.comwrote:
<quote>No, it won't have a major effect.</quote>

*That's* an assertion. Therefore by your own instructions, it's up to
you to prove your assertion.

There is no reason to believe that it "may have" any effect.
There absolutely is. What will be feeding the programs their standard
input? Cygwin. What will be launching the processes? Cygwin.

Will it definitely have a difference? Who knows. I'm not claiming it
definitely will - just that until you've proved that it doesn't, your
tests are invalid when considering how Java and .NET are *normally* run
on Windows.
Cygwin offers easy way to time with time command. If you can time all
the becnhmarks as easily on Windows and get different results, let us
know.
What I *will* do is amend the sumcol test to be sensible in the first
place - to run *once* with a suitably large input. That way you can
easily measure the time taken within the app, discounting the
(massively repeated) startup costs.

--
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
Jun 27 '08 #106
Lew wrote:
Mark Thornton wrote:
>Given that my Java code won't be making best use of SSE

Are you sure of that?

If true, it's one more area for Hotspot authors to approach.
As far as I know Java 6 only uses SSE for a single operation at a time
(i.e scalar operations), it doesn't detect opportunities to do 4 at a
time ops.

Mark Thornton
Jun 27 '08 #107
Razii wrote:
On Wed, 04 Jun 2008 18:39:59 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>>Now you are introducing new subjective "rules" to circumvent problems with
the benchmarks.

I didn't make the rules. That's the rule for this benchmark on
shootout site.
Actually the shootout explicitly states "read integers from stdin, one line
at a time" but the Java program is not reading lines at all. So the fastest
Java programs currently on their site are all cheating.

Another one of the Java programs on their site is actually valid by their
rules:

http://shootout.alioth.debian.org/gp...ng=javaxx&id=0

but it is 1.75x slower (their results) than the invalid Java that you wanted
to compare against.

Drawing a fair comparison, we find:

sumcol: (line by line)
C#: 3.2s
Java: 4.7s

So .NET is also substantially faster than Java on this benchmark.
>>I can make Java 3x times faster by writing custom parser.

Congratulations, Java is finally catching up with the optimized .NET code.

In other words, .NET is much slower if it uses standard library.
My fast program only used the stdlib. Moreover, that doesn't even make sense
because .NET languages provide their own stdlibs.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jun 27 '08 #108
On Wed, 4 Jun 2008 19:05:19 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
>Will it definitely have a difference? Who knows.
Dowsnload Cygwin

http://www.cygwin.com/

Time it and let us know if there is a difference.
Jun 27 '08 #109
Razii wrote:
On Wed, 04 Jun 2008 09:04:01 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:

>>>That's the only reason it's faster in partialsums benchmark.

That is pure speculation.


It's not. I posted the evidence. C# gets wrong result.
First of all, "right" vs. "wrong" is a matter of language specification.
C# could be getting a different answer from Java, and yet produce an
acceptable answer within the terms of its language specification.

Similarly, Java only requires "The computed result must be within 1 ulp
of the exact result. Results must be semi-monotonic.". One could imagine
a language that requires the answer to be the round-to-nearest
equivalent of a value within one part in 1e100 of the infinitely precise
result. If a Java implementation did not get that answer, but did meet
the Java specification, would its answer be "wrong"?

The next question is whether Java's answer is usefully better than C#'s
answer. As Jon Harrop indicated earlier, 1e15 radians is too big for
useful trig precision.

During a calculation, any infinitely precise result in the range
[999999999999999.9375,1000000000000000.0625] gets rounded to the double
representation of 1e15. The width of that range, regarded as an angle,
is 0.125 radians, over seven degrees. The sine of the actual angle,
before rounding to double, could be anywhere between about 0.8245 and
about 0.8886.

A 64 bit floating point calculation that depends on taking sines of
angles around 1e15 radians is effectively operating with less than 2
decimal digit precision. It has far, far worse numerical problems than
the difference between the C# and Java results.

Of course, this does not address the question of whether there are any
angles for which Java's sine calculation is usefully more accurate than
C#'s. 1e15 is not one of them.

Patricia
Jun 27 '08 #110
On Wed, 04 Jun 2008 18:56:32 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>
That has not been true for some time:

binarytrees:
N/A
That's says it all. You can't optimize it even though both programs
are doing the same.
>sumcol:
F#: 0.9s
Java: 0.73s
Custom parser. C# is slower with standard library.
>recursive:
F#: 3.0s
Java: 3.6s
Post the C# version so I can verify the above claim. C# is slower on
my comp.
>revcomp:
C#: 1.2s
Java: 1.5s
Post the link to the code. How am I supposed to verify the result when
you don't post the code?

Post it to pastebin.com
>As you can see, .NET is now faster on two (recursive and revcomp) and not
significantly slower on another (sumcol).
I see no such thing.
Jun 27 '08 #111
Mark Thornton wrote:
Jon Harrop wrote:
>For double precision floating point your argument of 1e15 to sin has
already lost all precision because it is fourteen orders of magnitude
outside the primary domain of this trig function.

Sin and cos are defined for all real numbers. Sure Java is rather
unusual in returning accurate results for all values of double (bar
infinite and NaN). While many systems set the bar rather lower, one has
to admire Java for raising it (and eventually delivering).
If Java were competitively performant here I would agree but this workaround
for legacy hardware is slowing a lot of code down for insignificant
practical benefit.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jun 27 '08 #112
On Wed, 04 Jun 2008 18:56:32 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>Type "Mersenne Twister" into Google and click "I'm feeling lucky" (it is the
first hit). There are implementations in many languages and Java is by far
the slowest of the compiled languages because it generally has very poor
integer performance.
http://www-stat.stanford.edu/~naras/...neTwister.java

Forbidden
You don't have permission to access
/~naras/programs/mt/sluke/MersenneTwister.java on this server.

--------------------------------------------------------------------------------

Apache/2.0.52 (Red Hat) Server at www-stat.Stanford.EDU Port 80

Until I have seen it, verified it, and failed to optimize it. This one
means nothing.
Jun 27 '08 #113
On Wed, 04 Jun 2008 19:09:59 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>Actually the shootout explicitly states "read integers from stdin, one line
at a time" but the Java program is not reading lines at all. So the fastest
Java programs currently on their site are all cheating.
Well, if you want to interpret the rule this way, then the other C#
and Java version is NOT reading line by line because they buffer the
result. How is that reading line-by-line when the program is
buffering?

The correct interrelation is that program must use standard library
and C# with .NET is slower. You had to write a custom parser to
catchup with custom parser.
Jun 27 '08 #114
Razii wrote:
On Wed, 04 Jun 2008 19:09:59 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>>Actually the shootout explicitly states "read integers from stdin, one
line at a time" but the Java program is not reading lines at all. So the
fastest Java programs currently on their site are all cheating.

Well, if you want to interpret the rule this way, then the other C#
and Java version is NOT reading line by line because they buffer the
result. How is that reading line-by-line when the program is
buffering?
Exactly. The shootout's subjective rules are completely flawed.
The correct interrelation is that program must use standard library
and C# with .NET is slower.
For another subjection notion of "correct" that also has no practical
relevance, yes.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jun 27 '08 #115
On Wed, 04 Jun 2008 19:18:06 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>If Java were competitively performant here I would agree but this workaround
for legacy hardware is slowing a lot of code down for insignificant
practical benefit.
If on AMD phenom and Windows Vista, and C# gets wrong result for sin
and cos on my computer. How are you calling this legacy system?
Jun 27 '08 #116
Razii wrote:
On Wed, 04 Jun 2008 19:18:06 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>>If Java were competitively performant here I would agree but this
workaround for legacy hardware is slowing a lot of code down for
insignificant practical benefit.

If on AMD phenom and Windows Vista, and C# gets wrong result for sin
and cos on my computer. How are you calling this legacy system?
64-bit or 32-bit Windows?

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jun 27 '08 #117
On Wed, 04 Jun 2008 19:29:35 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>For another subjection notion of "correct" that also has no practical
relevance, yes.
Why can't you post C# version that uses standard library and is not
slower? Perhaps that's because it's not possible?
Jun 27 '08 #118
Jon Skeet [C# MVP] <sk***@pobox.comwrote:
Cygwin offers easy way to time with time command. If you can time all
the becnhmarks as easily on Windows and get different results, let us
know.

What I *will* do is amend the sumcol test to be sensible in the first
place - to run *once* with a suitably large input. That way you can
easily measure the time taken within the app, discounting the
(massively repeated) startup costs.
Okay, done - and it's interesting.

First here's a program to duplicate the original input file:
using System.IO;

class DuplicateSumCol
{
static void Main(string[] args)
{
string text = File.ReadAllText("sumcol-input.txt");
int iterations = int.Parse(args[0]);
File.Delete("sumcol-large.txt");
for (int i=0; i < iterations; i++)
{
File.AppendAllText("sumcol-large.txt", text);
}
}
}

I ran that with an input parameter of 10000 to get a 43MB file, which
appears to be large enough to give interesting results.

Then I refactored both the Java and C# versions to allow input either
from a file or from standard input. The bulk of the time is spent in a
single method, so it shouldn't make much difference - and if *either*
language is significantly hampered by this sort of refactoring, then
frankly it deserves all it gets. Here's the C# version:

using System;
using System.Diagnostics;
using System.IO;

class SumCol
{
static void Main(string[] args)
{
int sum;
Stopwatch sw = Stopwatch.StartNew();
if (args.Length == 0)
{
sum = Parse(Console.In);
}
else
{
using (TextReader reader = File.OpenText(args[0]))
{
sum = Parse(reader);
}
}
long elapsed = sw.ElapsedMilliseconds;
Console.WriteLine("Result: {0}", sum);
Console.WriteLine("Elapsed millis: {0}", elapsed);
}

static int Parse (TextReader reader)
{
int sum = 0;
string line;
while ( (line=reader.ReadLine()) != null)
{
sum += int.Parse(line);
}
return sum;
}
}

And here's the Java version:

import java.io.*;

public class SumCol
{
public static void main(String[] args) throws Exception
{
int sum;
long start = System.currentTimeMillis();

if (args.length==0)
{
sum = parse(System.in);
}
else
{
// For the sake of brevity, don't bother closing...
sum = parse(new BufferedInputStream
(new FileInputStream(args[0])));

}
long end = System.currentTimeMillis();

System.out.println("Result: " + sum);
System.out.println("Elapsed millis: " + (end-start));
}

static int parse(InputStream stream) throws IOException
{
int sum = 0;
StreamTokenizer lineTokenizer = new StreamTokenizer(stream);
while (lineTokenizer.nextToken() != StreamTokenizer.TT_EOF)
{
sum += (int) lineTokenizer.nval;
}
return sum;
}
}

I'm running .NET 3.5, and here's all the Java information:
java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing)

The C# version was compiled with:
csc -o+ -debug- SumCol.cs

The Java version was compiled with:
javac SumCol.java

I'm running on an Intel Core 2 Duo with 32-bit Vista.

Results (in ms):

SumCol.exe < sumcol-large.txt: 4833
SumCol.exe sumcol-large.txt: 3327
java SumCol < sumcol-large.txt: 3321
java SumCol sumcol-large.txt: 3315
Feel free to suggest changes to how the Java version is run, of course
- and please test on your own machine.

My conclusion: Java and .NET are effectively neck and neck here in
terms of actual *processing*, but .NET's console handling slows it down
significantly. No great loss IMO - I very rarely pipe large input from
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
Jun 27 '08 #119
Razii wrote:
On Wed, 04 Jun 2008 19:29:35 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>>For another subjection notion of "correct" that also has no practical
relevance, yes.

Why can't you post C# version that uses standard library and is not
slower? Perhaps that's because it's not possible?
The C# version works perfectly when you don't run your CPU in legacy mode.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jun 27 '08 #120
[Side-note: Hi Patricia! Good to be chatting again... it's been a long
time.]

Patricia Shanahan <pa**@acm.orgwrote:
It's not. I posted the evidence. C# gets wrong result.

First of all, "right" vs. "wrong" is a matter of language specification.
C# could be getting a different answer from Java, and yet produce an
acceptable answer within the terms of its language specification.
In this case I don't think it's actually a language issue at all - it's
a standard libraries issue. C# and Java (the language) don't define any
trig methods as far as I'm aware. So long as the compiler can get the
value into the method accurately, and propagate the value back to the
caller accurately, the languages are doing their jobs.

There *are* interesting issues in terms of C# and its handling of
floating point numbers, because it doesn't guarantee that calculations
won't be performed at a higher precision than the type's
representation. See
http://msmvps.com/blogs/jon.skeet/ar.../02/68716.aspx
for an example of this.
The next question is whether Java's answer is usefully better than C#'s
answer. As Jon Harrop indicated earlier, 1e15 radians is too big for
useful trig precision.
Agreed. One thing I find interesting is that Google's result is the
same as .NET's - if you type
sin(1e15)
into the search bar, you get 0.858272132, the same as the .NET answer.
That can't be pure coincidence, but I've no idea where the similarity
is...

--
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
Jun 27 '08 #121
Razii <ni*******@mail.comwrote:
On Wed, 4 Jun 2008 19:05:19 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
Will it definitely have a difference? Who knows.

Dowsnload Cygwin

http://www.cygwin.com/

Time it and let us know if there is a difference.
I'd rather time a more *useful* benchmark (one that doesn't involve
starting thousands of processes) - so I've done exactly that.

My previous experiences with Cygwin have been far from great - I'd
rather not install it at all. As I say, if you want to justify running
..NET in a somewhat alien environment (you must admit that it's not
exactly the norm), you should check that it doesn't affect results.

--
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
Jun 27 '08 #122
On Wed, 04 Jun 2008 19:31:43 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>64-bit or 32-bit Windows?
32-bit. I hope your next answer is not that 32-bit is legacy system.

Jun 27 '08 #123
Razii <ni*******@mail.comwrote:
On Wed, 04 Jun 2008 19:29:35 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
For another subjection notion of "correct" that also has no practical
relevance, yes.

Why can't you post C# version that uses standard library and is not
slower? Perhaps that's because it's not possible?
Out of interest, what happens in your version of the test if you avoid
the deprecated StreamTokenizerConstructor? Force Java to actually deal
with text as text (which is why the constructor taking Stream is
deprecated) and see how the results fare.

On my box it makes Java slower than .NET - but YMMV.

--
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
Jun 27 '08 #124
On Wed, 4 Jun 2008 19:49:20 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
>into the search bar, you get 0.858272132, the same as the .NET answer.
That can't be pure coincidence, but I've no idea where the similarity
is...
That's pretty simple to explain. Both use hardware for angle reduction
and get the same wrong answer. That's why it's faster but wrong. It's
not just 1e15

What about these?

Console.WriteLine(Math.Sin (1e7));

0.420547793190771 (C# with .NET)
0.42054779319078249129850658974095 (right answer)

Console.WriteLine(Math.Sin (1e10));

-0.48750602507627 (C# with .NET)
-0.48750602508751069152779429434811 (right answer)

I am sure there are better examples but the point is made.
Jun 27 '08 #125
On Wed, 04 Jun 2008 19:47:19 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>The C# version works perfectly when you don't run your CPU in legacy mode.
Huh? What does sum-col has anything to do with "legacy" mode?
Jun 27 '08 #126
On Wed, 4 Jun 2008 20:01:54 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
>Out of interest, what happens in your version of the test if you avoid
the deprecated StreamTokenizerConstructor? Force Java to actually deal
with text as text (which is why the constructor taking Stream is
deprecated) and see how the results fare.
$ time cat sum.txt | java -server sumcol (deprecated)
10500000

real 0m4.224s
user 0m0.155s
sys 0m0.327s

$ time cat sum.txt | sumcol (.NET)
10500000

real 0m6.395s
user 0m0.077s
sys 0m0.342s

changing the line to

StreamTokenizer lineTokenizer = new StreamTokenizer(new BufferedReader
(new InputStreamReader(System.in)));

$ time cat sum.txt | java -server sumcol
10500000

real 0m5.375s
user 0m0.202s
sys 0m0.296s

still faster.

Jun 27 '08 #127
Razii wrote:
On Wed, 4 Jun 2008 20:01:54 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
>>Out of interest, what happens in your version of the test if you avoid
the deprecated StreamTokenizerConstructor? Force Java to actually deal
with text as text (which is why the constructor taking Stream is
deprecated) and see how the results fare.

$ time cat sum.txt | java -server sumcol (deprecated)
10500000

real 0m4.224s
user 0m0.155s
sys 0m0.327s

$ time cat sum.txt | sumcol (.NET)
10500000

real 0m6.395s
user 0m0.077s
sys 0m0.342s

changing the line to

StreamTokenizer lineTokenizer = new StreamTokenizer(new BufferedReader
(new InputStreamReader(System.in)));

$ time cat sum.txt | java -server sumcol
10500000

real 0m5.375s
user 0m0.202s
sys 0m0.296s

still faster.
You are still timing Cygwin's implementation of Unix pipes which has nothing
to do with anything.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jun 27 '08 #128
Razii wrote:
On Wed, 04 Jun 2008 19:31:43 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>>64-bit or 32-bit Windows?

32-bit. I hope your next answer is not that 32-bit is legacy system.
So you're running a 64-bit CPU in 32-bit mode.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jun 27 '08 #129
Razii <ni********@mail.comwrote:
On Wed, 4 Jun 2008 20:01:54 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
Out of interest, what happens in your version of the test if you avoid
the deprecated StreamTokenizerConstructor? Force Java to actually deal
with text as text (which is why the constructor taking Stream is
deprecated) and see how the results fare.
<snip results: Java=4.2s->5.4s; .NET=6.4s>

Interesting - on my box it *halves* the speed of the Java version, to
*way* slower than the .NET version.

What happens if you run it not under Cygwin? (Now that it's just a big
file, it's very easy to see the elapsed time without using Cygwin.)

--
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
Jun 27 '08 #130
Jon Skeet [C# MVP] wrote:
[Side-note: Hi Patricia! Good to be chatting again... it's been a long
time.]
Hi Jon.
>
Patricia Shanahan <pa**@acm.orgwrote:
>>>It's not. I posted the evidence. C# gets wrong result.

First of all, "right" vs. "wrong" is a matter of language specification.
C# could be getting a different answer from Java, and yet produce an
acceptable answer within the terms of its language specification.


In this case I don't think it's actually a language issue at all - it's
a standard libraries issue. C# and Java (the language) don't define any
trig methods as far as I'm aware. So long as the compiler can get the
value into the method accurately, and propagate the value back to the
caller accurately, the languages are doing their jobs.
....

Arguable in the case of Java. The Java Language Specification says that
each compilation unit implicitly starts with an import of "the
predefined package java.lang".

I don't know whether C# has any libraries with such a privileged position.

Patricia
Jun 27 '08 #131
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.
Note that this functionality is entirely due to the hardware and is not
specific to .NET. Run 64-bit hardware and the problem disappears.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jun 27 '08 #132
Jon Skeet [C# MVP] wrote:
[Side-note: Hi Patricia! Good to be chatting again... it's been a long
time.]

Patricia Shanahan <pa**@acm.orgwrote:
>>It's not. I posted the evidence. C# gets wrong result.
First of all, "right" vs. "wrong" is a matter of language specification.
C# could be getting a different answer from Java, and yet produce an
acceptable answer within the terms of its language specification.

In this case I don't think it's actually a language issue at all - it's
a standard libraries issue. C# and Java (the language) don't define any
trig methods as far as I'm aware. So long as the compiler can get the
value into the method accurately, and propagate the value back to the
caller accurately, the languages are doing their jobs.
Unlike most previous languages Java is not really separable from its
standard library --- they come together, as do the mandated accuracy
requirements.

Mark Thornton
Jun 27 '08 #133
Jon Harrop wrote:
Mark Thornton wrote:
>Jon Harrop wrote:
>>For double precision floating point your argument of 1e15 to sin has
already lost all precision because it is fourteen orders of magnitude
outside the primary domain of this trig function.
Sin and cos are defined for all real numbers. Sure Java is rather
unusual in returning accurate results for all values of double (bar
infinite and NaN). While many systems set the bar rather lower, one has
to admire Java for raising it (and eventually delivering).

If Java were competitively performant here I would agree but this workaround
for legacy hardware is slowing a lot of code down for insignificant
practical benefit.
I'm not sure what you mean by legacy hardware as I have assumed that all
x86 systems share the same 66 bit approximation of PI when doing
'hardware' argument reduction for FSIN.

As for the practical benefit I think the most troubling points are the
values for sin in the vicinity of PI. It is just conceivable to me that
this could make a practical difference.

Mark Thornton
Jun 27 '08 #134
Razii wrote:
On Wed, 04 Jun 2008 18:56:32 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>>That has not been true for some time:

binarytrees:
N/A

That's says it all. You can't optimize it even though both programs
are doing the same.
Actually I don't need to because the existing F# code is already fast:

F#: 2.7s
Java: 2.4s

Unless you think a 13% performance difference makes Java "much faster"?
>>sumcol:
F#: 0.9s
Java: 0.73s

Custom parser. C# is slower with standard library.
C# is not slower here:

C#: 3.2s
Java: 3.2s

Note that I have ignored the invalid Java programs listed on the shootout
(that do not read lines as demanded by their own spec).

In either case, Java is not significantly faster.
>>recursive:
F#: 3.0s
Java: 3.6s

Post the C# version so I can verify the above claim. C# is slower on
my comp.
That was F# directly from the shootout.
>>revcomp:
C#: 1.2s
Java: 1.5s

Post the link to the code.
That was C# directly from the shootout.
>>As you can see, .NET is now faster on two (recursive and revcomp) and not
significantly slower on another (sumcol).

I see no such thing.
Perhaps you are still running your CPU in legacy mode and your .NET
applications in Cygwin with emulated Unix pipes? If so, I'd suggest
bringing your technology into the 21st century before benchmarking
anything...

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jun 27 '08 #135
Mark Thornton wrote:
Jon Harrop wrote:
>If Java were competitively performant here I would agree but this
workaround for legacy hardware is slowing a lot of code down for
insignificant practical benefit.

I'm not sure what you mean by legacy hardware as I have assumed that all
x86 systems share the same 66 bit approximation of PI when doing
'hardware' argument reduction for FSIN.
The modern 64-bit equivalents apparently do not. I have to run in a 32-bit
chroot to recreate this effect of using legacy hardware which is why I
hadn't noticed it before.
As for the practical benefit I think the most troubling points are the
values for sin in the vicinity of PI. It is just conceivable to me that
this could make a practical difference.
I suspect people who care about such accuracy would not have chosen broken
hardware in the first place...

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jun 27 '08 #136
On Wed, 4 Jun 2008 20:36:44 +0100, Jon Skeet [C# MVP]
<sk***@pobox.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.
We are discussing partialsums benchmark . Let's change

Console.WriteLine("{0:f9}\tFlint Hills", a4);

to

Console.WriteLine("{0:f16}\tFlint Hills", a4);

and see if even get the same answer.

(.NET)
30.3145415095625000 Flint Hills
42.9952339980839000 Cookson Hills

(JAVA)
30.3145415095632840 Flint Hills
42.9952339980842500 Cookson Hills

We don't. C# answer is most likely wrong so "fast" in this benchmark
comes at the cost of wrong answer.

Can you try this version and tell us if C# is still 2x faster (command
line argument is 2500000)

http://shootout.alioth.debian.org/gp...lang=java&id=4

It's not on my computer but Harpo claims it is.
Jun 27 '08 #137
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.
Jun 27 '08 #138
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.

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jun 27 '08 #139
Patricia Shanahan <pa**@acm.orgwrote:
In this case I don't think it's actually a language issue at all - it's
a standard libraries issue. C# and Java (the language) don't define any
trig methods as far as I'm aware. So long as the compiler can get the
value into the method accurately, and propagate the value back to the
caller accurately, the languages are doing their jobs.
...

Arguable in the case of Java. The Java Language Specification says that
each compilation unit implicitly starts with an import of "the
predefined package java.lang".
True - but it doesn't specify much about what's *in* that package, does
it? (I imagine it references java.lang.Exception, java.lang.Throwable
etc explicitly - but doesn't define java.lang.Math.sin.)
I don't know whether C# has any libraries with such a privileged position.
Some types are referenced by the C# spec (System.Disposable, the
generic and nongeneric IEnumerable interfaces and a few others) but not
whole namespaces.

--
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
Jun 27 '08 #140
Mark Thornton <mt*******@optrak.co.ukwrote:
In this case I don't think it's actually a language issue at all - it's
a standard libraries issue. C# and Java (the language) don't define any
trig methods as far as I'm aware. So long as the compiler can get the
value into the method accurately, and propagate the value back to the
caller accurately, the languages are doing their jobs.

Unlike most previous languages Java is not really separable from its
standard library --- they come together, as do the mandated accuracy
requirements.
Well, they come together to a *certain* extent - but they're not
inseparable. In particular you can easily use the Java platform without
using the Java language.

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. With C# it's easier to communicate the
difference between talking about the language, the runtime, and the
libraries. (Which isn't to say everyone gets it right, of course...)

--
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
Jun 27 '08 #141
On Wed, 4 Jun 2008 20:41:35 +0100, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:
>Interesting - on my box it *halves* the speed of the Java version, to
*way* slower than the .NET version.
Did you use BufferedReader?

I added the internal timer..
import java.io.*;

public class sumcol {
public static void main(String[] args) throws Exception{

long start = System.currentTimeMillis();

int sum = 0;

StreamTokenizer lineTokenizer = new StreamTokenizer(new
BufferedReader (new InputStreamReader(System.in)));
while (lineTokenizer.nextToken() != StreamTokenizer.TT_EOF) {
sum += (int) lineTokenizer.nval;
}
System.out.println(Integer.toString(sum));

System.out.println("Time: " + (System.currentTimeMillis() -
start));
}
}
---- C# -------
using System;
using System.IO;

class SumCol
{
static void Main(){
long start = DateTime.Now.Ticks;
int sum = 0;

using (StreamReader r = new
StreamReader(Console.OpenStandardInput())){
string line;
while ((line = r.ReadLine()) != null) sum +=
Int32.Parse(line);
}
Console.WriteLine(sum);
long end = DateTime.Now.Ticks;
Console.WriteLine("Time: " + (end - start)/10000);

}
}

sumcol < sum.txt
10500000
Time: 6821

java -server sumcol < sum.txt (Java)
10500000
Time: 5231

Blah no difference. Enough with Cygwin nonense.

Jun 27 '08 #142
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? .NET is twice slower.
Jun 27 '08 #143
On Wed, 04 Jun 2008 21:08:35 +0100, Jon Harrop <jo*@ffconsultancy.com>
wrote:
>Your inexplicably anomalous results already proved that.
Or you are the one with inexplicably anomalous results? Check if you
get different results on Cygwin, then let us know.

Jun 27 '08 #144
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.

We are discussing partialsums benchmark .
The post I was replying to wasn't - it was discussing sin(1e7)
and sin(1e10). This subthread was started with a post talking about
sin(1e15).

I still maintain that if you're using that magnitude of angle in a real
world application, you've got bigger problems. (In the benchmark,
giving a value of N=2500000 means you're still taking the sin of a
ridiculously large angle.)
Let's change

Console.WriteLine("{0:f9}\tFlint Hills", a4);

to

Console.WriteLine("{0:f16}\tFlint Hills", a4);

and see if even get the same answer.
That's not the best way of finding out the exact value of a double. See
http://pobox.com/~skeet/csharp/floatingpoint.html and download
DoubleConverter.cs. Then you can use DoubleConverter.ToExactString to
find out the absolutely precise value.
(.NET)
30.3145415095625000 Flint Hills
42.9952339980839000 Cookson Hills
Using DoubleConverter and N=2500000 I get:
2.999999999999998667732370449812151491641998291015 625 (2/3)^k
3160.81762188707580207847058773040771484375 k^-0.5
0.999999600000204380556567684834590181708335876464 84375 1/k(k+1)
30.31454150956249549153653788380324840545654296875 Flint Hills
42.99523399808393975263243191875517368316650390625 Cookson Hills
15.30901715473919821874915214721113443374633789062 5 Harmonic
1.644933666848367392887553251057397574186325073242 1875 Riemann Zeta
0.693146980560093828316325925698038190603256225585 9375 Alt. Harmonic
0.785398063397435564070292457472532987594604492187 5 Gregory
(JAVA)
30.3145415095632840 Flint Hills
42.9952339980842500 Cookson Hills

We don't. C# answer is most likely wrong so "fast" in this benchmark
comes at the cost of wrong answer.
I love the way you go straight from "most likely" to an absolute
assertion that the speed *is* at the cost of correctness. Note how the
benchmark doesn't provide "correct" values. Heck, the results posted
(in the languages I looked at, which was a fair variety) don't show
enough significant figures to show whether they agree with .NET, Java
or neither.

None of the languages is going to get a perfectly accurate answer, of
course - the accumulated error over 2.5 million additions is likely to
be pretty significant, especially when each of the values added is only
an approximation to the mathematical truth anyway.

Now when a platform starts giving inappropriate answers on *sensible*
questions, that's when I'd get more worried.

--
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
Jun 27 '08 #145
Razii <ni********@mail.comwrote:
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.
You're the one in the best position to test this, as you're the one
with Cygwin installed.

Run the benchmark I provided earlier both in Cygwin and from a plain
Windows prompt (with java SumCol < sumcol-large.txt and
SumCol < sumcol-large.txt, as well as java SumCol sumcol-large.txt and
SumCol sumcol-large.txt) and present the results.

--
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
Jun 27 '08 #146
Jon Skeet [C# MVP] wrote:
Mark Thornton <mt*******@optrak.co.ukwrote:
>>In this case I don't think it's actually a language issue at all - it's
a standard libraries issue. C# and Java (the language) don't define any
trig methods as far as I'm aware. So long as the compiler can get the
value into the method accurately, and propagate the value back to the
caller accurately, the languages are doing their jobs.
Unlike most previous languages Java is not really separable from its
standard library --- they come together, as do the mandated accuracy
requirements.

Well, they come together to a *certain* extent - but they're not
inseparable. In particular you can easily use the Java platform without
using the Java language.

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.

Mark Thornton
Jun 27 '08 #147
Razii <ni********@mail.comwrote:

<snip>
sumcol < sum.txt
10500000
Time: 6821

java -server sumcol < sum.txt (Java)
10500000
Time: 5231

Blah no difference. Enough with Cygwin nonense.
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).

You still haven't posted the results of accessing the file directly,
however - on my box they showed Java and .NET neck and neck. How about
on yours? If they show the same results, then we can conclude that .NET
is indeed slower at reading console input than Java - which is
interesting, but certainly nothing like your wide-scale generalisation
that "C# is slower than Java".

(Also note that your results are nowhere near the "2x slower" that you
were previously posting about sumcol - I suspect that was due to the
overhead of starting up .NET being slightly greater than the overhead
of starting up Java for this test. Again, interesting to know but not
terribly relevant to real world applications which typically run for
rather more than a few milliseconds.)

--
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
Jun 27 '08 #148
Jon Harrop wrote:
Mark Thornton wrote:
>Jon Harrop wrote:
>>If Java were competitively performant here I would agree but this
workaround for legacy hardware is slowing a lot of code down for
insignificant practical benefit.
I'm not sure what you mean by legacy hardware as I have assumed that all
x86 systems share the same 66 bit approximation of PI when doing
'hardware' argument reduction for FSIN.

The modern 64-bit equivalents apparently do not. I have to run in a 32-bit
chroot to recreate this effect of using legacy hardware which is why I
hadn't noticed it before.
>As for the practical benefit I think the most troubling points are the
values for sin in the vicinity of PI. It is just conceivable to me that
this could make a practical difference.

I suspect people who care about such accuracy would not have chosen broken
hardware in the first place...
All too often those that care aren't the ones who choose the hardware.
It just arrives ...

I do think there is some merit in the fact that with Java we can expect
to get the same answer regardless. It does make testing easier. When I
first did numerical analysis there were still a number of variations of
floating point in common use, which made constructing reliable and
portable numerical software rather harder.

Mark Thornton
Jun 27 '08 #149
Jon Skeet [C# MVP] wrote:
Razii <ni********@mail.comwrote:

<snip>
>sumcol < sum.txt
10500000
Time: 6821

java -server sumcol < sum.txt (Java)
10500000
Time: 5231

Blah no difference. Enough with Cygwin nonense.

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.

Mark Thornton
Jun 27 '08 #150

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

80
by: tech | last post by:
Hi, i have the following problem In file1.h namespace A { class Bar { void foo();
358
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 ... ...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.