422,757 Members | 1,151 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 422,757 IT Pros & Developers. It's quick & easy.

crushing java

P: n/a
here a little test program.
it's so simple taht it should deliver simmilar result.
it's also so simple that people that might says it's unfair to the looser
(why Java people are always arguing like that ?)...

anyway see for yourself the test command lines:
javac SimplePerf.java && java SimplePerf 10000000
csc /nologo SimplePerf.cs && SimplePerf 10000000


Nov 16 '05 #1
Share this Question
Share on Google+
14 Replies


P: n/a
Lloyd Dupont <ld@NewsAccount.galador.net> wrote:
here a little test program.
it's so simple taht it should deliver simmilar result.
it's also so simple that people that might says it's unfair to the looser
(why Java people are always arguing like that ?)...


Congratulations - you've shown that the JIT compiler for Java doesn't
spot that the call to Math.cos can be removed.

Now, how applicable do you believe that is? Are your programs full of
calls to trig methods which aren't actually relevant?
In fact, if you fix the program so it *does* use the value, .NET still
wins easily - but the fact that you thought this was even slightly
useful in its current form is somewhat interesting.

(I was running with JDK1.4.2; it would be interesting to try the IBM
JDK as that's traditionally been better for floating point stuff.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #2

P: n/a
As John said, there are a number of things that might explain this. And C# and Java is sufficiently different that comparing the two is difficult and in many cases pointless (Apples and Oranges).

Strange thing though, when trying to force Math.Cos do work in C# I added a double[10000000] array and stored each value in there. This increased the execution time for C# from 0-16 ms on my system to about 1.4 seconds. However, java was incapable of creating a double array of that size. ??? OutOfMemoryError

It would be interesting to see if someone on non Windows systems could run the code (or anyone using Windows).

My modified code is

C#

public static void Main(string[] args)
{
int N = int.Parse("10000000");
double[] d = new double[N];
long t0 = Environment.TickCount;
for(int i=0 ; i< N; i++)
{
d[i] = Math.Cos(i);
}
Console.WriteLine(Environment.TickCount-t0);
}

Java

public static void main(String[] args)
{
int N = Integer.parseInt("10000000");
double[] d = new double[N];
long t0 = System.currentTimeMillis();
for(int i=0; i< N; i++)
{
d[i] = Math.cos(i);
}
System.out.println(System.currentTimeMillis()-t0);
}

--
Happy coding!
Morten Wennevik [C# MVP]
Nov 16 '05 #3

P: n/a
Morten Wennevik <Mo************@hotmail.com> wrote:
As John said, there are a number of things that might explain this.
And C# and Java is sufficiently different that comparing the two is
difficult and in many cases pointless (Apples and Oranges).

Strange thing though, when trying to force Math.Cos do work in C# I
added a double[10000000] array and stored each value in there. This
increased the execution time for C# from 0-16 ms on my system to
about 1.4 seconds. However, java was incapable of creating a double
array of that size. ??? OutOfMemoryError


It's not an inability of Java to create the array - it's that the
maximum heap size is set to 64Mb by default. Run it with -Xmx128M to
give it 128MB instead.

However, rather than storing all the doubles, another way is to keep a
single double variable and add the result of Math.Cos to that on each
iteration. It's then testing floating point addition as well, of
course.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #4

P: n/a
Yeah,
I initially stored a single double value, but was unsure if the compiler was smart enough to discover it only needed to do Math.Cos(9999999) and drop the rest (sometimes compilers can surprise :P). If only I had also thought of doing the addition.

--
Happy coding!
Morten Wennevik [C# MVP]
Nov 16 '05 #5

P: n/a
Just curious: How does the JIT compiler know that Math.Cos *can* be removed,
i.e. that it has no side-effects, like changing a global variable, writing
to a file, or shutting down my computer? Is there some kind of attribute
that says "this function may be removed if it's return value is not used"?
Some programming languages have expressions for that, but I didn't know
there was a way for that in .NET IL.

Niki

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om...
Lloyd Dupont <ld@NewsAccount.galador.net> wrote:
here a little test program.
it's so simple taht it should deliver simmilar result.
it's also so simple that people that might says it's unfair to the looser (why Java people are always arguing like that ?)...


Congratulations - you've shown that the JIT compiler for Java doesn't
spot that the call to Math.cos can be removed.

Now, how applicable do you believe that is? Are your programs full of
calls to trig methods which aren't actually relevant?
In fact, if you fix the program so it *does* use the value, .NET still
wins easily - but the fact that you thought this was even slightly
useful in its current form is somewhat interesting.

(I was running with JDK1.4.2; it would be interesting to try the IBM
JDK as that's traditionally been better for floating point stuff.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #6

P: n/a
Niki Estner <ni*********@cube.net> wrote:
Just curious: How does the JIT compiler know that Math.Cos *can* be removed,
i.e. that it has no side-effects, like changing a global variable, writing
to a file, or shutting down my computer? Is there some kind of attribute
that says "this function may be removed if it's return value is not used"?
Some programming languages have expressions for that, but I didn't know
there was a way for that in .NET IL.


My *guess* is that this knowledge is built into the CLR, but that's
only a guess.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #7

P: n/a
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om...
Niki Estner <ni*********@cube.net> wrote:
Just curious: How does the JIT compiler know that Math.Cos *can* be removed, i.e. that it has no side-effects, like changing a global variable, writing to a file, or shutting down my computer? Is there some kind of attribute
that says "this function may be removed if it's return value is not used"? Some programming languages have expressions for that, but I didn't know
there was a way for that in .NET IL.


My *guess* is that this knowledge is built into the CLR, but that's
only a guess.


You mean that somewhere in the JIT code there's a line like "if
(function=="Math.Cos" && ! returnValue.used) continue;"? Would that kind of
optimization have any other use than faking benchmarks? I mean: what
'normal' program would call Math.Cos without using it's return value?
Wouldn't it make more sense e.g. to state a warning in that case, instead of
just removing the code?

Niki
Nov 16 '05 #8

P: n/a
Niki Estner <ni*********@cube.net> wrote:
My *guess* is that this knowledge is built into the CLR, but that's
only a guess.
You mean that somewhere in the JIT code there's a line like "if
(function=="Math.Cos" && ! returnValue.used) continue;"?


Sort of, yes.
Would that kind of optimization have any other use than faking benchmarks?
I mean: what'normal' program would call Math.Cos without using it's return value?
Wouldn't it make more sense e.g. to state a warning in that case, instead of
just removing the code?


In this case, yes. I suspect there are situations where dead code is
present where it's not actually so obvious.

I could be entirely wrong, of course, and the JIT compiler could be
working it out by inlining it and then removing dead code as it
normally does. That would be a more flexible system, of course.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #9

P: n/a
of course the compiler don't just remove a call.
it's incorrect to remove a function call !
at most does it inline it.
your reaction just proved you to be sentimental and self blinded

anyway, this proof can be canceled by another similar test:
using System;

public class ExceptPerf
{
public static void Main(string[] args)
{
int N = int.Parse(args[0]);
long t0 = Environment.TickCount;
for(int i=0; i< N; i++)
try{
throw new Exception();
}catch( Exception e )
{
;
}
Console.WriteLine((Environment.TickCount-t0));
}
}

public class ExceptPerf
{
public static void main(String[] args)
{
int N = Integer.parseInt(args[0]);
long t0 = System.currentTimeMillis();
for(int i=0; i< N; i++)
try{
throw new Exception();
}catch( Exception e )
{
;
}
System.out.println((System.currentTimeMillis()-t0));
}
}
Nov 16 '05 #10

P: n/a
Lloyd Dupont <ld@NewsAccount.galador.net> wrote:
of course the compiler don't just remove a call.
it's incorrect to remove a function call !
Not if the JIT compiler absolutely knows that it can have no effect on
anything other than performance.
at most does it inline it.
Really? I looked at the JITted code with cordbg. Did you?
I tried running your code without the call to Math.Cos, and got the
same results. Did you? Are you saying that Math.Cos calls are
absolutely free?
your reaction just proved you to be sentimental and self blinded
Whatever you say...
anyway, this proof can be canceled by another similar test:


On my box, that shows .NET throwing exceptions to be significantly
slower than Java. Of course, any system which is throwing hundreds of
thousands of exceptions ought to look at its design very carefully
anyway.

There are areas where .NET is faster than Java.
There are areas where Java is faster than .NET.
I really don't see why that's so hard to accept...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #11

P: n/a
of course the compiler don't just remove a call.
it's incorrect to remove a function call !
at most does it inline it.
your reaction just proved you to be sentimental and self blinded

anyway, this proof can be canceled by another similar test:
using System;

public class ExceptPerf
{
public static void Main(string[] args)
{
int N = int.Parse(args[0]);
long t0 = Environment.TickCount;
for(int i=0; i< N; i++)
try{
throw new Exception();
}catch( Exception e )
{
;
}
Console.WriteLine((Environment.TickCount-t0));
}
}

public class ExceptPerf
{
public static void main(String[] args)
{
int N = Integer.parseInt(args[0]);
long t0 = System.currentTimeMillis();
for(int i=0; i< N; i++)
try{
throw new Exception();
}catch( Exception e )
{
;
}
System.out.println((System.currentTimeMillis()-t0));
}
}
Nov 16 '05 #12

P: n/a
Lloyd Dupont <ld@NewsAccount.galador.net> wrote:
of course the compiler don't just remove a call.
it's incorrect to remove a function call !
Not if the JIT compiler absolutely knows that it can have no effect on
anything other than performance.
at most does it inline it.
Really? I looked at the JITted code with cordbg. Did you?
I tried running your code without the call to Math.Cos, and got the
same results. Did you? Are you saying that Math.Cos calls are
absolutely free?
your reaction just proved you to be sentimental and self blinded
Whatever you say...
anyway, this proof can be canceled by another similar test:


On my box, that shows .NET throwing exceptions to be significantly
slower than Java. Of course, any system which is throwing hundreds of
thousands of exceptions ought to look at its design very carefully
anyway.

There are areas where .NET is faster than Java.
There are areas where Java is faster than .NET.
I really don't see why that's so hard to accept...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #13

P: n/a
BTW, if needed, I didn't intended to be rude, I just believed you wrong.

additional comment below.

"Jon Skeet [C# MVP]" <sk***@pobox.com> a écrit dans le message de
news:MP************************@msnews.microsoft.c om...
Lloyd Dupont <ld@NewsAccount.galador.net> wrote:
of course the compiler don't just remove a call.
it's incorrect to remove a function call !
Not if the JIT compiler absolutely knows that it can have no effect on
anything other than performance.
at most does it inline it.


Really? I looked at the JITted code with cordbg. Did you?

No
I tried running your code without the call to Math.Cos, and got the
same results. Did you? mmhh....
I just increased N and see it was slower.
now that it remove the Math.Cos call but let an empty loop, now that's
something puzzling !
Are you saying that Math.Cos calls are
absolutely free? did I ?
your reaction just proved you to be sentimental and self blinded
Whatever you say...

it looked so at least ...
anyway, this proof can be canceled by another similar test:
On my box, that shows .NET throwing exceptions to be significantly
slower than Java. Of course, any system which is throwing hundreds of
thousands of exceptions ought to look at its design very carefully
anyway.

There are areas where .NET is faster than Java.
There are areas where Java is faster than .NET.
I really don't see why that's so hard to accept...

I accept, I accept, didn't I ?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #14

P: n/a
Lloyd Dupont <ld@NewsAccount.galador.net> wrote:
BTW, if needed, I didn't intended to be rude, I just believed you wrong.


I think whenever you say that someone's reaction proves them to be
"sentimental and self blinded" you're likely to be rude, to be honest.
Not if the JIT compiler absolutely knows that it can have no effect on
anything other than performance.
at most does it inline it.


Really? I looked at the JITted code with cordbg. Did you?

No
I tried running your code without the call to Math.Cos, and got the
same results. Did you?

mmhh....
I just increased N and see it was slower.
now that it remove the Math.Cos call but let an empty loop, now that's
something puzzling !


Not really - it's just as I said: the JIT is removing calls which it
knows are pointless. It does the same in other situations. For
instance, I believe if you do:

int[] x = new int[100];

for (int i=0; i < x.Length; i++)
{
DoSomethingWith(x[i]);
}

it won't need to do both the Length check in the "for" condition *and*
the implicit bounds check on x[i], because it knows that if
0 < i < x.Length, x[i] should be fine.
Are you saying that Math.Cos calls are
absolutely free?

did I ?


If you had done the tests without Math.Cos and still claimed the JIT
wasn't removing them, you'd have been implying that.
anyway, this proof can be canceled by another similar test:


On my box, that shows .NET throwing exceptions to be significantly
slower than Java. Of course, any system which is throwing hundreds of
thousands of exceptions ought to look at its design very carefully
anyway.

There are areas where .NET is faster than Java.
There are areas where Java is faster than .NET.
I really don't see why that's so hard to accept...

I accept, I accept, didn't I ?


I wasn't at all sure what your second test was meant to be showing as
you didn't say what results you got - but given the subject line of
"crushing Java" (and the denegration of Java developers in your first
post) you seemed to be under the impression that .NET was faster for
everything.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #15

This discussion thread is closed

Replies have been disabled for this discussion.