NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Stephan Schwab's
blog entry brought
a recent benchmark done by BentUser
to my attention. The benchmark claims that .NET 2.0 is significantly faster than Java. According to BentUser, Java took about 355 ms to sort 1,000 floating point numbers using a selection sort. That number immediately sent up a bunch of red flags in my mind. Yeah, I know a selection sort is pretty inefficient, but 355 ms to sort 1,000 numbers? That's a ridiculously long time. I began to think their tests were seriously flawed, so I decided to write up my own.
The results? A selection sort, sorting a 1,000 element floating point array, with Java 5 running the server VM on my Celeron M 1.2 Ghz laptop, took 9 ms--a far cry from the 355 ms they reported on their Pentium D 3.0 Ghz system with 2 Mb of cache. That seemed like a lot more reasonable number. They also ran the test with 100,000 elements, for which they reported that Java took 37 seconds to complete the sort. Yeah, I know that no one actually sorts a 100,000 element array in reality using a selection sort, but I decided to humor them anyway. I sent my class file to Matt to run on his system. Running it on an Athlon64 2.19 Ghz system running 32 bit Windows XP and a 32 bit JVM produced a time of 30 seconds--again less than the time they reported on a significantly faster system with significantly more onboard cache.
My conclusions? To start with, the conclusion that .NET is faster than Java is completely flawed to begin with since the only test they based that on was a selection sort with an unreasonably large data set. Simply put, no one sorts a 100,000 element floating point array using a selection sort. But to confound matters even worse, their tests were seriously flawed, which caused them to produce bogus numbers. My opinion is that their conclusion is totally unfounded.
Well, I think that "benchmark" isn't even worthy of a discussion, you can instantly see that it's bogus because:
- the source of the benchmark was Not provided
- not details of the JVM or the how the code was run was given; did it use -server, do the runtimes include startup times,...
UPDATE: With "-Xmx128m -Xms128m -server" and "-g:none", the runtimes are as follows
100000 - 21837ms (On par with the .Net's 21375 but on my slower system and linux JVM!)
10000 - 229ms
Runtimes with default JVM options:
100000 numbers TIME TAKEN 29543ms
EDIT: 10000 TIME TAKEN 294ms
1000 numbers TIME TAKEN 3ms (the article has a typo which mislead me to use 1000)
Using linux 2.6, jdk5, pentium 4 2.4ghz with 384mb of ram. Boot strapped to run the method 50 times before actual test.
BTW, when is insertion sort memory intensive as the article claimed?
publicstaticvoid selectionSort(double[] numbers, int arraySize){
long start = System.currentTimeMillis();
int sizeSub1 = arraySize-1;
for (int i=0;i<sizeSub1;i++){
int largestIdx = i;
for (int j=i+1; j < arraySize;j++){
if (numbers[j] > numbers[largestIdx]){
largestIdx = j;
}
}
// do swap
double temp = numbers[i];
numbers[i] = numbers[largestIdx];
numbers[largestIdx] = temp;
}
long stop = System.currentTimeMillis();
System.out.println("TIME TAKEN " + (stop - start)+ "ms");
}
> 1000 numbers TIME TAKEN 3ms (the article has a typo
> which mislead me to use 1000)
It definately would be a little closer to being inline with expected results if it were a typo and it was supposed to be 10,000 instead of 1,000. But if that is the case, the same typo was made 4 times in the article. So that led me to believe it was not a typo, and was probably a case of a flawed test that was including all kinds of additional tasks in the time besides just the sort operation such as JVM startup and populating the array and such.
No, wait...he said the numbers where just monotonically decreasing. Maybe the JIT noticed this and didn't even bother to store the data values themselves, instead just storing that fact
Or maybe the JIT has a new feature where it can fool the process monitors, or just use memory and make it appear that it's some other process that uses the memory.
Or maybe it's some fancy use-the-swapfile-and-never-have-to-keep-it-all-in-memory-at-once technique.
And here I was about to dismiss these "benchmarks" as not worthy of comment, when in fact we can have a lot of fun thinking about what JIT features will be in Java324SE in the year 2089.
:)
Andy Tripp, CTO and Founder Jazillian
- Legacy to 'natural' Java.
Using class files generated through Eclipse, I have even better performance, and I wonder why? And the 100k speed is officially faster than the test .Net results.
Indeed this article seems completely bogus (e.g. no source code). The style and the comments are typical of "a very young" person (e.g. delusional generalizations):
It appears that Microsoft .NET has not only caught up to Java in many ways, but it has surpassed it in terms of implementation efficiency.
This is not surprising since Microsoft continues to prosper while Sun appears to be in a slow decline as businesses move away from expensive, proprietary systems.
This is not to say that Java should be discarded completely, but we have a clear efficiency champion in .NET.
Jean-Marie Dautelle - Marlboro, MA
-- Javolution: Everything should be made as simple as possible...
-- JScience: But not simpler!
i think i know why the original benchmarks of this "BentUser" looks bad.
As you know .Net 2.0 has special optimizations when primitive (value types) are used in Collections. My guess is, The test was done using objects and collections, instead of primitive and arrays. That is why author is HIDING the code, even the methodology. Naturally, .Net 2.0 is faster when you use value objects in Collections (which is actually not common).
Actually using objects for primitive operations (especially numeric calculations, sorting etc) is not a good idea if performance is an issue. For demonstrating this, i made the tests by using a List, and an array for Sorting using the selection sort algorithm. here is the results for Java:
As you see, object and Collections one is 10 times slower than the primitive and arrays solution. That is why that person who made the test is very sneaky .
For the kicks, i made the same tests with Mustang Build 59, here are the results:
for this particular algorithm and implementation, Mustang has %10-15 faster results.
At the end, this guy is unfair, becuase he hides his methodologies and codes with deliberately choosing an uncommon implementation of a simple algorithm, focuses on stregth of one platform. But, the fact is, Java should improve the performance of primitive usage in collections. i know that this is not a common use and does not matter in over all application performance, but nevertheless, .Net people will abuse this fact in every way possible with those kind of idiotic micro benchmarks.
when i have time, i will repeat the tests with .Net 2.0 and C# too.
BentUser Reports .NET 2.0 Significantly Faster than Java 5... Oh Really?
URL: Stephan Schwab
At 5:00 PM on Nov 21, 2005, Michael Urban wrote:
Fresh Jobs for Developers Post a job opportunity
The results? A selection sort, sorting a 1,000 element floating point array, with Java 5 running the server VM on my Celeron M 1.2 Ghz laptop, took 9 ms--a far cry from the 355 ms they reported on their Pentium D 3.0 Ghz system with 2 Mb of cache. That seemed like a lot more reasonable number. They also ran the test with 100,000 elements, for which they reported that Java took 37 seconds to complete the sort. Yeah, I know that no one actually sorts a 100,000 element array in reality using a selection sort, but I decided to humor them anyway. I sent my class file to Matt to run on his system. Running it on an Athlon64 2.19 Ghz system running 32 bit Windows XP and a 32 bit JVM produced a time of 30 seconds--again less than the time they reported on a significantly faster system with significantly more onboard cache.
My conclusions? To start with, the conclusion that .NET is faster than Java is completely flawed to begin with since the only test they based that on was a selection sort with an unreasonably large data set. Simply put, no one sorts a 100,000 element floating point array using a selection sort. But to confound matters even worse, their tests were seriously flawed, which caused them to produce bogus numbers. My opinion is that their conclusion is totally unfounded.
Here's the link to this benchmark:
.NET vs. Java Shootout
58 replies so far (
Post your own)
Re: BentUser Reports .NET 2.0 Significantly Faster than Java 5... Oh Really
Well, I think that "benchmark" isn't even worthy of a discussion, you can instantly see that it's bogus because:- the source of the benchmark was Not provided
- not details of the JVM or the how the code was run was given; did it use -server, do the runtimes include startup times,...
Re: BentUser Reports .NET 2.0 Significantly Faster than Java 5... Oh Really?
Perhaps they included startup time?Re: BentUser Reports .NET 2.0 Significantly Faster than Java 5... Oh Really
> Perhaps they included startup time?Even then, they would almost have had to be doing it from a cold start to get times that bad. Even including JVM startup time, I was under 100 ms.
Re: BentUser Reports .NET 2.0 Significantly Faster than Java 5... Oh Really
UPDATE: With "-Xmx128m -Xms128m -server" and "-g:none", the runtimes are as follows100000 - 21837ms (On par with the .Net's 21375 but on my slower system and linux JVM!)
10000 - 229ms
Runtimes with default JVM options:
100000 numbers TIME TAKEN 29543ms
EDIT: 10000 TIME TAKEN 294ms
1000 numbers TIME TAKEN 3ms (the article has a typo which mislead me to use 1000)
Using linux 2.6, jdk5, pentium 4 2.4ghz with 384mb of ram. Boot strapped to run the method 50 times before actual test.
BTW, when is insertion sort memory intensive as the article claimed?
public static void selectionSort(double[] numbers, int arraySize){ long start = System.currentTimeMillis(); int sizeSub1 = arraySize-1; for (int i=0;i<sizeSub1;i++){ int largestIdx = i; for (int j=i+1; j < arraySize;j++){ if (numbers[j] > numbers[largestIdx]){ largestIdx = j; } } // do swap double temp = numbers[i]; numbers[i] = numbers[largestIdx]; numbers[largestIdx] = temp; } long stop = System.currentTimeMillis(); System.out.println("TIME TAKEN " + (stop - start)+ "ms"); }Re: BentUser Reports .NET 2.0 Significantly Faster than Java 5... Oh Really
They're not very smart .. if they were smart, they would have had Microsoft pay them to come up with these resultsPeace.
Re: BentUser Reports .NET 2.0 Significantly Faster than Java 5... Oh Really
To really see the sheer genious of that benchmark, take a look at Page 2 .According to him, creating 5 million 64 bit doubles in Java took 20 megabytes, and the same in .Net was 45 MB.
(5,000,000 * 64) / (8 * 1024 * 1024) = 38.15 MB.
Can anyone explain how Java can store 38 MB of data in 20 MB?
I think the fact that he didn't even notice this speaks volumes for the quality of his non-disclosed code.
Re: BentUser Reports .NET 2.0 Significantly Faster than Java 5... Oh Really
I think we should contact them....send them the test...It is not fair to Java developers and we should voice out...
Re: BentUser Reports .NET 2.0 Significantly Faster than Java 5... Oh Really
> 1000 numbers TIME TAKEN 3ms (the article has a typo> which mislead me to use 1000)
It definately would be a little closer to being inline with expected results if it were a typo and it was supposed to be 10,000 instead of 1,000. But if that is the case, the same typo was made 4 times in the article. So that led me to believe it was not a typo, and was probably a case of a flawed test that was including all kinds of additional tasks in the time besides just the sort operation such as JVM startup and populating the array and such.
Re: BentUser Reports .NET 2.0 Significantly Faster than Java 5... Oh Really
> (5,000,000 * 64) / (8 * 1024 * 1024) = 38.15 MB.How about runlength encoding by the JIT
No, wait...he said the numbers where just monotonically decreasing. Maybe the JIT noticed this and didn't even bother to store the data values themselves, instead just storing that fact
Or maybe the JIT has a new feature where it can fool the process monitors, or just use memory and make it appear that it's some other process that uses the memory.
Or maybe it's some fancy use-the-swapfile-and-never-have-to-keep-it-all-in-memory-at-once technique.
And here I was about to dismiss these "benchmarks" as not worthy of comment, when in fact we can have a lot of fun thinking about what JIT features will be in Java324SE in the year 2089.
:)
Re: BentUser Reports .NET 2.0 Significantly Faster than Java 5... Oh Really
Using class files generated through Eclipse, I have even better performance, and I wonder why? And the 100k speed is officially faster than the test .Net results.10k TIME TAKEN 180ms
100k TIME TAKEN 19067ms
Re: BentUser Reports .NET 2.0 Significantly Faster than Java 5... Oh Really
Indeed this article seems completely bogus (e.g. no source code). The style and the comments are typical of "a very young" person (e.g. delusional generalizations):-- Javolution: Everything should be made as simple as possible... -- JScience: But not simpler!
Re: BentUser Reports .NET 2.0 Significantly Faster than Java 5... Oh Really
The web page shows no way to contact the author, but it does give an address for comments on articles:inbox at bentuser dot com
Since I didn't do any tests myself, I don't think I should reply. Any other takers?
Re: BentUser Reports .NET 2.0 Significantly Faster than Java 5... Oh Really
i think i know why the original benchmarks of this "BentUser" looks bad.As you know .Net 2.0 has special optimizations when primitive (value types) are used in Collections. My guess is, The test was done using objects and collections, instead of primitive and arrays. That is why author is HIDING the code, even the methodology. Naturally, .Net 2.0 is faster when you use value objects in Collections (which is actually not common).
Actually using objects for primitive operations (especially numeric calculations, sorting etc) is not a good idea if performance is an issue. For demonstrating this, i made the tests by using a List, and an array for Sorting using the selection sort algorithm. here is the results for Java:
Array, double:
N=10000 : 297ms
N=50000 : 7204ms
ArrayList, Double:
N=10000 : 2407ms
N=50000 : 70266ms
As you see, object and Collections one is 10 times slower than the primitive and arrays solution. That is why that person who made the test is very sneaky
For the kicks, i made the same tests with Mustang Build 59, here are the results:
Array, double:
N=10000 : 250ms
N=50000 : 6047ms
ArrayList, Double:
N=10000 : 2047ms
N=50000 : 59578ms
for this particular algorithm and implementation, Mustang has %10-15 faster results.
At the end, this guy is unfair, becuase he hides his methodologies and codes with deliberately choosing an uncommon implementation of a simple algorithm, focuses on stregth of one platform. But, the fact is, Java should improve the performance of primitive usage in collections. i know that this is not a common use and does not matter in over all application performance, but nevertheless, .Net people will abuse this fact in every way possible with those kind of idiotic micro benchmarks.
when i have time, i will repeat the tests with .Net 2.0 and C# too.
Re: BentUser Reports .NET 2.0 Significantly Faster than Java 5... Oh Really
Out of curiosity, how did you populate your array? With numbers that were descending sorted originally? Or with random numbers?