Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Re: benchmarks? java vs .net (sin and cos)

Reply
Thread Tools

Re: benchmarks? java vs .net (sin and cos)

 
 
Jon Skeet [C# MVP]
Guest
Posts: n/a
 
      06-04-2008
Razii <(E-Mail Removed)> wrote:
> On Wed, 04 Jun 2008 19:29:35 +0100, Jon Harrop <(E-Mail Removed)>
> 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 - <(E-Mail Removed)>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
 
Reply With Quote
 
 
 
 
Jon Skeet [C# MVP]
Guest
Posts: n/a
 
      06-04-2008
Razii <(E-Mail Removed)> wrote:
> On Wed, 4 Jun 2008 20:01:54 +0100, Jon Skeet [C# MVP]
> <(E-Mail Removed)> wrote:
>
> >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 - <(E-Mail Removed)>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
 
Reply With Quote
 
 
 
 
Jon Skeet [C# MVP]
Guest
Posts: n/a
 
      06-04-2008
Razii <(E-Mail Removed)> wrote:
> On Wed, 04 Jun 2008 20:34:59 +0100, Jon Harrop <(E-Mail Removed)>
> 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 - <(E-Mail Removed)>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
 
Reply With Quote
 
Jon Skeet [C# MVP]
Guest
Posts: n/a
 
      06-04-2008
Razii <(E-Mail Removed)> wrote:

<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 - <(E-Mail Removed)>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
 
Reply With Quote
 
Mark Thornton
Guest
Posts: n/a
 
      06-04-2008
Jon Skeet [C# MVP] wrote:
> Razii <(E-Mail Removed)> wrote:
>
> <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
 
Reply With Quote
 
Jon Skeet [C# MVP]
Guest
Posts: n/a
 
      06-04-2008
Mark Thornton <(E-Mail Removed)> wrote:
> > 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 - <(E-Mail Removed)>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
 
Reply With Quote
 
Mark Thornton
Guest
Posts: n/a
 
      06-04-2008
Jon Skeet [C# MVP] wrote:
> Mark Thornton <(E-Mail Removed)> wrote:
>>> 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
 
Reply With Quote
 
Jon Skeet [C# MVP]
Guest
Posts: n/a
 
      06-04-2008
Mark Thornton <(E-Mail Removed)> wrote:
> > (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 - <(E-Mail Removed)>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
 
Reply With Quote
 
Jon Skeet [C# MVP]
Guest
Posts: n/a
 
      06-04-2008
Razii <(E-Mail Removed)> wrote:
> On Wed, 4 Jun 2008 22:21:31 +0100, Jon Skeet [C# MVP]
> <(E-Mail Removed)> wrote:
>
> >(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 - <(E-Mail Removed)>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
 
Reply With Quote
 
Jon Skeet [C# MVP]
Guest
Posts: n/a
 
      06-04-2008
Razii <(E-Mail Removed)> wrote:
> On Wed, 4 Jun 2008 23:03:59 +0100, Jon Skeet [C# MVP]
> <(E-Mail Removed)> wrote:
>
> >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 - <(E-Mail Removed)>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Hot Requirements: 1.Sr Java Developer,2.Java Developer (Java with EJB) Isaac Java 0 01-20-2011 08:41 PM
hey i am just started java,, can anyone tell me the use ,application, why java , importance of java.. manish sahu Java 3 02-14-2008 12:00 AM
Another Question: Java and other application, Java and hardware Roberto Faenza Java 4 02-25-2007 06:18 PM
[JAVA] [EVALUATION] - The Java Failure (Sorry: The Java(tm) Failure) Ilias Lazaridis Java 0 02-01-2005 10:32 AM
Job to convert Java App 1.3.1 to Java Newest of Java Michael Kintner Java 0 11-30-2003 04:42 AM



Advertisments