OSNews

I'm a fan of .NET, and I have to say that this test was moronically executed. Not only does it conclude completely false things, such as claiming that .NET treats arrays of native types as arrays of objects, but it's also very lacking in number and quality of tests.

I agree totally. This was no meaningful comparison of Java and .Net at all. Move along.

"Since it looks like these benchmarks ended up .NET's favor, how we can expect at least 80 comments explaining exactly how and why thest tests were biased in favor of .NET."

All benchmarks are biased one way or the other. Just like statistics, benchmarks is a great vehicle for "proving" your point.

Despite all the trolls that write code for Java, Sun doesn't have a clue on how to make usuable software.

Despite all the trolls that write code for Windows-Only .NET, Microsoft doesn't have a clue on how to create multiplatform software.

Despite all the trolls that write code for Windows-Only .NET, Microsoft doesn't have a clue on how to create multiplatform software.
I'm not sure. The .NET is basically not tied too strictly to windows, let see the mono project. There is a way to create platform-independent .NET compatible sytem. It is only the Microsoft's decision. IMHO in the future the main plaform of microsoft will the .NET and not the Windows.

It was true for win3.x and 9.x. But the NT-line is a relative good thing, the NT microkernel is really good (better then linux kernel), the win32 is not the best idea (but better then the 10000 little inconsistent library and application under linux) and IMHO the .NET will replace it in the near future.

NT is not a microkernel. This is straight from the kernel team. It only looked like one at the start, but it's not anymore.

Firstly, Linux is not a microkernel.
Secondly, your priorities for what you want in a kernel will most likely be different than everyone elses. Both Linux and NT kernels have good points, and both have bad points.
Thirdly, the NT kernel is totally uncustomizable (totally closed proprietory). Whereas Linux is totally free.

Your comparation is nearly as baseless as this article. It also seems like you dont know what you are talking about. Oh, and good luck with your driver programming in C#...

"But IMHO the NT microkernel is better then the monolithic linux kernel."

The NT kernel is not a microkernel and the Linux kernel is not monolithic. They're both hybrid kernels with varying degrees of modularity.

I used linux as desktop from 1995. I don't see too many good points in the linux kernel. There are many good thing in the linux, but it is not the kernel.

LOL! And precisely what technical insights did you get into the kernel from being a desktop user?

You obviously are an idiot.

Linux is a Kernel - NOTHING MORE.

GNU/Linux is the total system.

Yeah yeah, when I think about windows GUI I recall Xview/Motif/Openstep/Gnome/KDE all these are MS achievements, the other OSes are only command line.

First of all, I would say the windows GUI sucks badly too. It is just that people are so used to it that they don't notice.

Second, most java programs runs ever written runs on the serverside without much of a GUI. In some way Java act as a modern replacement for COBOL, and just like COBOL it will take a very long time before it becomes extinkt regardless how many better techniques that becomes available.

Third, .net 2.0 is newer than Java 5 (jdk1.5), and being so similar it is only natural that .net is somewhat better, just like java 1.6 will be better than java 1.5 and .net 2.0, just like java 5 was better than .net 1.0 However, most organizations can't afford to change their software platform as often as the version numbers of the development platforms change.

Despite all the trolls that write code for Windows-Only .NET, Microsoft doesn't have a clue on how to create multiplatform software.

With previous version(s) of Windows NT being released for multiple platforms and the Rotor project bringing a large part of the .net base framework to *nix I'd say MS is more than capable of supporting multiple platforms.

The fact that they do not support them more at this point is purely strategic for them.

The dynamic languages always will suck. Without static type system the applications always will be slow and unstable. You can write a little bit less code, but with the dynamic typing the IDE's code completition always will be less sophisticated. In long term (and with bigger projects) you will create your application with using more working hours then the tradidional languages and systems. And with .NET or Java you can use a very big class library. This class libraries are very well designed - oppisitely the most of FOSS class libs. And this class libraries are coherent, not 1000 little redundant, incompatible, buggy little library. And this libraries are precompiled, especially on .NET.

> This class libraries are very well designed
I remember using Swing a long time ago, its design is quite clean but it was also full of bugs and very slow at this time, which Sun took years to correct..

As for the dynamic vs static type debate, I remember seing that C# v3 will have locally inferenced types which should increase the readability.
I think that local type inference is an interesting middle ground: you get nearly the same type safety as static types with a much improved readability.

Hmm, Objective-C is nice on MacOS X, IMHO it does not "suck".

This is so moronic I hardly know where to start. Do you know the difference between dynamic typing and strong typing? I can't imagine why you think dynamic typing makes for slow and unstable apps. And what does code completion have to do with anything? Finally, I make a living writing .Net code and if you think the class libraries are especially well designed then it just reveals your naivety. They're acceptable, but the collection classes in particular are unwieldy and limited. It's no surprise that the roadmap for C# contains a lot of features inspired by Ruby, one of the most dynamic languages in common use.

I can't imagine why you think dynamic typing makes for slow and unstable apps.

Speed: if you use dynamic typing, your app will check the type of your variable before every instruction.

if you execute the $a=$a+1 statament your app must check the type of $a before you can add to 1 to the $a.

Stability (PHP):
$a=2;
$b="2 apple";
$c=$a+$b;
print $c; /* 4 */

Python is better (send type error if you try a+b, but the a*b is valid, the result is 2 apple2 apple).

You can create unit tests, but IMHO better if this type of bugs filtered out in compile time.

Python is better (send type error if you try a+b, but the a*b is valid, the result is 2 apple2 apple).

You should probably read up on dynamic/static vs strong/weak typing. Python, for instance, is dynamic and strongly-typed. You might not declare types in the code, but an int is an int is an int. It is an int when it is first assigned, and it is an int throughout the program. Since the type of a variable is constant, it does not need to be checked "before every instruction". Your a*b example is doing exactly what you are telling it to do, and has nothing to do with the type system. a+b is a type error, and flagged as such. So, given that python has the same runtime type safety as java and .Net, and does not have the performance penalties you ascribe to it, I ask again - how is it that dynamic languages necessarily result in slow and unstable apps? Before answering, you might want to consider that the type safety in C# and java can be trashed by upcasting to an object in one statement, then attempting to downcast to an incompatible object in the next statement. This will not be spotted at compile time, and so by your definition must make C# and java apps unstable. C++ and (especially) C are even easier to abuse.

Java != Javascript && Javascript != Java

Javascript was created by Netscape, Java on the other hand was created by Sun microsystems.

"JavaScript was first introduced and deployed in the Netscape browser version 2.0B3 in December of 1995. The choice of name proved to be a source of much confusion. There is no real relation between Java and JavaScript; their similarities are mostly in syntax (that is, both derived from C). Their semantics are quite different: notably, their object models are unrelated and largely incompatible."
http://en.wikipedia.org/wiki/Javascript#Java.2C_JavaScript.2C_and_J...

Where did the original poster confuse Java and JavaScript? How would that even make sense, when he was clearly referring to it as a dynamic language?

Edited 2005-11-05 08:36

In an object oriented language if an object inherits from another than the one that inherits can be used in place of it's parent class; however, depending on the language the opposite isn't always true.

ex:
obj1 base class
obj2 extends obj1 // inheritence
void foo(obj1) can take obj2 instead, but
void bar(obj2) cannot always take obj1.

Therefore one can be the other but the opposite cannot always be true.

Oh, I agree with you, I am talking about in the since of boolean algebra though. With the operands being T/F values.

Last I checked .NET isn't designed for a compile once, run anywhere. Please correct me if I'm wrong.
This I'd consider Java to be more suitable/desirable for me.

Are you kidding? .NET was designed by MS from the beginning to be cross-platform from the ground up! MS has released versions of .NET (Rotor) for Mac OS X and at least one other OS. Then you have Mono, which takes .NET's design onto virtually every other platform. I wrote cross-platform apps in .NET every day. It rocks!

.NET was designed by MS from the beginning to be cross-platform from the ground up!

Last time I heard Mono is not going to support System.EnterpriseServices...

Last time I heard Mono is not going to support System.EnterpriseServices...

This has nothing to do with the platform itself being designed to be OS/system neutral. There are many C++ libraries not available on other platforms, but it doesn't mean you can't create code that runs on all of them.

The fact is the CLI was developed to be platform neutral. .NET is one implementation of this standard. The MSR runtimes, Mono, and .GNU are other implementations of the same standards. .NET and Mono also include and/or have seperately distributed platform-specific libraries not unlike most other language distributions. These libraries in no way impede one's ability to develop platform-neutral applications as the various CLI implementations have proven.

Only problem is Mono uses microsoft API's that are not part of any standard. i.e. ASP.NET and ADO.NET are not part of the ECMA standard.

Heck, even on the Mono website, they are already figuring out ways to 'get around' the patent problems.

Java seems safer from a legal perspective.

Only problem is Mono uses microsoft API's that are not part of any standard. i.e. ASP.NET and ADO.NET are not part of the ECMA standard.

And again, the availability of class libraries licensed only for specific OSes has nothing to do with the platform neutral design of the runtime architecture.

As you said, they aren't part of the standard. This in no way impedes the development of cross-platform code, nor means the standard wasn't designed with neutrality in mind. Practically all language platforms have libraries that won't work across OSes, whether for technical reasons or only due to licensing. Whether a library is limited to a particular OS/architecture is up to the developer of that library.

Java seems safer from a legal perspective.
It is true, but just because the MS and the SUN agreed. But it is not concern to any other implementations (classpath+gcj, etc) and if SUN is out of business the legal perspective of java can be very interesting. But probably the IBM also can protect their java implementation.

SUSE, although a good distribution, is not the only Linux distribution out there.

When a value type needs to act as an object (like when it's used via an object or interface referfence), then and only then does it get boxed and take up more space.

Exactly. And of course Java does exactly the same, only you've got to do the boxing and unboxing manually, which is a pain in the ass.

And C# is actually more efficient when value types are combined with generics. In Java e.g. you have to manually box integers to put them into a List<Integer>. In C# you can put them into a List<int> directly, and the runtime system automatically creates a version of the List<T> code that is specialised for int's and thus does not require any boxing at all.

>Exactly. And of course Java does exactly the same, only you've got to do the boxing and unboxing manually, which is a pain in the ass.

Not with J2SE 5.0, which does autoboxing.

There's another thing to note in there.

If the Java double type is 64-bit, that means each double takes 8 bytes of memory. With 5million doubles, that adds up to 40000000 bytes of memory, but the Java test shows 19.9MB which is ~half that.
What happens here? Does java compress the floats when they are not used, or is it that the JVM detects that they are not used, and so doesn't keep all of it in memory?
The guy who made this test is a moron who don't understand what he's talking about, plain and simple.

I noticed that too... I'm thinking Java recognizes that he hasn't done anything with his memory, he needs to be smarter than his vm and do something like:
char lst = new char[50000000];
for (int c; c < 50000000; ++c)
lst[c] = char(c%32 + 65);

That way, maybe he can trick the VM into thinking he's using that RAM.

However the neutrality of this test can be called into question as we are testing the microsofts dotnet implementation on their own platform meaning they have access to private API's and the like that Sun does not have access to. Maybe this is not the case but we can't really be sure of this now can we?
Which private API helps .NET during selection sort? Which private API helps .NET to take up less memory for an array of objects?
Do you really believe there's a private API that makes the CPU run faster?

"Which private API helps .NET during selection sort? Which private API helps .NET to take up less memory for an array of objects?"

Couldn't tell you really mate. I think the whole "private" part of it kind of gives me a reason not to know now doesn't it...

"Do you really believe there's a private API that makes the CPU run faster?"

I doubt it, if you find one be sure to let me know...I would it really appreciate it.

Whether or not they have a private API, Microsoft does have some advantage working off their native O/S.
{and yes, MS has in the past used undocumented apis to increase performance compared to rival products on their platform}

If .Net performed worse than Java on Windows, wouldn't you be shocked?

How about we compare Mono performance vs. Kaffe?

"Whether or not they have a private API, Microsoft does have some advantage working off their native O/S.
{and yes, MS has in the past used undocumented apis to increase performance compared to rival products on their platform} "

I love it everytime someone tries to use this argument. Sun themselves did a test with this in StarOffice, and what did they find? Performance gain with undocumented API = zero.
Certain APIs are undocumented because they WILL change in the future. Once MS publically documents an API, it's very unlikely to change.

"How about we compare Mono performance vs. Kaffe?"
This has already been done, Mono won. IKVM on an old build of Mono (VM on VM, whee!) ran Java just as fast as Kaffe.

I'm guessing that's because Sun still doesn't make it all that easy for FreeBSD to even run Java 1.5, which isn't a great selling point for the people using it.

Actually you do know what algorithm was used: selection sort. Though knowing that is not strictly necessary so long as the same sorting algorithm is used in both cases and it is implemented in terms of the same functionality.


Your last meaningful paragraph doesn't make any sense to me, and I've only glossed over the middle of the comment. The benchmark is stupid, and the absence of source code makes it even more useless than it clearly is from the exposition. The source code though sounds like it would take about six minutes to write from scratch if anyone really cares.

Knowing it was selection sort is about as useful as knowing another benchamrk implemented a shopping cart. For all we know, the implementation could be assbackwards.

The real value of benchmarks is being able to study the results and the implementation that lead to the results so you can appropriately plan the best way to do something. In-depth and detailed benchmarks are hard to come across because it takes a lot of time, effort and resources to conduct one, which is why they're usually funded. Being a funded benchmark doesn't lessen its validity as long as you get to inspect the details from full disclosure and understand what's going on.


I vote for knife vs fork shootout. Fork is clearly superior to knife.

Is that your really weak manner of saying "I don't know what I'm talking about, stop correcting me? I didn't read the first paragraph."

As long as it's implemented in terms of precisely the same functionality on both platforms (and it clearly is since they just 'ported' the same code from one to the other) they are testing essentially the same aspects of the virtual machines. What would be much more interesting is the exact parameters used for conducting the benchmarking.

Providing the source code in this case, or even saying what algorithm is used is unimportant. It's unimportant because a single test case is completely worthless for benchmarking. It affords absolutely no advantage here because the nature of the algorithm places most of the overhead in the effectiveness of the JIT compiler, and there aren't enough tests being made to conclude anything about the VMs.

Oh, starting with the personal attacks already? Is this your really lame hypocrytical attempt to act holier than thou?

"As long as it's implemented in terms of precisely the same functionality on both platforms (and it clearly is since they just 'ported' the same code from one to the other) they are testing essentially the same aspects of the virtual machines. What would be much more interesting is the exact parameters used for conducting the benchmarking."
No. Firstly, .NET != Java. Secondly, no proof has been offered that it is just a simple port. .NET and Java are implemented differently, their VM behaviours will be different, and the class libraries will perform differently. .NET and Java are not equal. The algorithm used could have been specifically chosen to exploit weaknesses in Java. We don't even know if the tests did anything with the doubles. The only thing we got is a digested number spitted out claiming ".NET is faster than Java".

"Providing the source code in this case, or even saying what algorithm is used is unimportant. It's unimportant because a single test case is completely worthless for benchmarking. It affords absolutely no advantage here because the nature of the algorithm places most of the overhead in the effectiveness of the JIT compiler, and there aren't enough tests being made to conclude anything about the VMs."
So now you're saying the benchmark is worthless because it one uses a single test case, but it wouldn't be if the VM paramaters were given out? So now the switches are be be all and end all? Well, Hello contradictory. I'm saying it's worthless because it's too simplistic and does not disclose the full details. You can make your benchmark as complex as you want, but it will still have little real value because your implementation could be retarded, or overly biased. You can learn something about performance even from biased benchmarks by studying the details.

If you can't understand that, then there's no point continuing this discussion with you. Your arguments strike as exactly the same kind of arguments Sun uses to avoid disclosing the details of their benchmarks, and the poor arguments made for 'apples to apples' comparisons which deliberately perform unnecessary 'tweaks' to the competing system causing poorer performance.

No question benchmark is plain dumb.

As far as this statement:

"3 different codebases for 100% 'Pure Java' applications on Win, Linux and OSX" ... could you elaborate. People always throw around various complaints, without ever quantifying or at least qualifying their points.

In spirit of free discovery,

Someone who thinks benchmark is stupid.

P.S: Even though Java used to run billions of e-commerce transactions per year, with vulnerabilities counting in single digits over a period of 10 years, nothing is ever 100% perfect and no one ever writes the same code. Java provides a _specificiation_, which is free to be implemented so long as it complies with "the test suite". No test suite is ever perfect.

And most people using .NET are using it on Windows, so how does that make anything better?

You never can compare a real word applications, because IMHO if you write a real word application on .NET and Java the code will be very different. The best thing what you can do the synthetic tests...

Yes, java at this moment very popular. But at this moment is nobody behind the Java, only the SUN. And the SUN is not too stable and ritch company. Yes, IBM, Oracle, etc supports Java, but this companies also supports .NET.

And, as if all those books/articles on managed code taught us nothing: Who cares if you sacrifice half of your clock cycles if you can save 10% of your development costs.
Not to mention, managed languages have a tendency (especially Java) to try and push you into the more efficient ways of using the VM to get the job done.. Where as, in say c, you can do whatever you want and there's no real push (although you likely won't be declaring structs with functors in them).

I really don't see the point in doing a benchmark of them. Maybe doing a benchmark of their graphics libraries, that might help out some aspiring 2d game programmers. Or, benchmark their 3d graphics libraries, maybe you'll help an aspiring cross platform 3d game programmer.

Let see: operator overloading, properties, databinding...

And this features are wasn't a new things when java was born (let see Delphi, C++, etc). You can implement this features in java, but if you want to use them you must rewrite all existing class libraries.

Ps: Java is a really good thing. But IMHO .NET is simply better. Not because the coders of MS are genious, only because the .NET is younger and the MS developers was draw the conclusions from java.

Just to back my claims up, in Server-Class Machine Detection [ http://java.sun.com/j2se/1.5.0/docs/guide/vm/server-class.html ] one can read:

"For J2SE 5.0, the definition of a server-class machine is one with at least 2 CPUs and at least 2GB of physical memory." -- The test machine is a Pentium D (dual-core) with 2Gb of RAM.

"The aim is to improve performance even if no one configures the VM to reflect the application it's running. In general, the server VM starts up more slowly than the client VM, but over time runs more quickly." -- This alone debunks these benchmarks.

It's been proven that the Hotspot does not actually do any additional optimizations for long running processes. It has different allocation and GC strategies, but JIT optimizations are zilch.

Furthermore, if you paid any attention to the 'benchmark', as stupid as it is, you'd see that the server VM must definitely start in less 375ms if the times took it into account, which certainly doesn't account for the 10000+ ms different in the second result, shooting your argument full of holes. Additionally, the graphs are proportionate, which suggests that the time taken was recorded via APIs, which in case you didn't notice, requires the VM to start first. Now, anyone can tell you that even on a 20 processor E20K, the server VM does not start in less than 375ms. Let's not even get started about the other dozen switches needed by Java to not make it look like a total laggard in properly conducted benchmarks. Switches that only help in those specific tasks and configurations.


This benchmark may be stupid and pointless, but the Java camp trying to defend Java with broken arguments is even worse.

"It's been proven that the Hotspot does not actually do any additional optimizations for long running processes. It has different allocation and GC strategies, but JIT optimizations are zilch."

Is it? Then point us all to some "proof", otherwise we will assume you are just taking that out of your ass.

The startup overhead isn't just about the startup time of the VM itself, it is about how aggressively the VM JIT compiles the code after it starts running.

If you are trying to benefit long running applications you don't start doing JIT compiling to the code right away, you collect statistics first to see what code runs frequently enough to be compiled without the JIT overhead becoming larger than the interpretation overhead of the bytecodes themeselves.

.NET, on the other hand, seems to be targeted (and used) mainly on the client side, where startup time matters. For this reason, and because of the JVM's server mode thing, .NET wins hands down in these tests.

.NET also has a server mode. One way of setting it is to make an app.config file (text file named appname.exe.config in the same directory as the app executable) with the following declaration:

<Configuration>
<runtime>
<gcServer enabled=“true“ />
</runtime>
</Configuration>

The problem with this is that MS won't allow benchmarks like this with their languages/platforms unless they approve it, which of course means the results will always be in MS's favor...so we'll probably never really know the truth.

MS does allow such benchmarks (excerpt from .NET 2.0 RTM EULA located in %systemroot%Microsoft.NET[backslash]Framework[backslash]v2.0.5 0727[backslash]Microsoft .NET Framework 2.0)

2. MICROSOFT .NET FRAMEWORK BENCHMARK TESTING. This supplement includes the .NET Framework component of the Windows operating systems (“.NET Component”). You may conduct internal benchmark testing of the .NET Component. You may disclose the results of any benchmark test of the .NET Component, provided that you comply with the following terms: (1) you must disclose all the information necessary for replication of the tests, including complete and accurate details of your benchmark testing methodology, the test scripts/cases, tuning parameters applied, hardware and software platforms tested, the name and version number of any third party testing tool used to conduct the testing, and complete source code for the benchmark suite/harness that is developed by or for you and used to test both the .NET Component and the competing implementation(s); (2) you must disclose the date (s) that you conducted the benchmark tests, along with specific version information for all Microsoft software products tested, including the .NET Component; (3) your benchmark testing was performed using all performance tuning and best practice guidance set forth in the product documentation and/or on Microsoft’s support web sites, and uses the latest updates, patches and fixes available for the .NET Component and the relevant Microsoft operating system; (4) it shall be sufficient if you make the disclosures provided for above at a publicly available location such as a website, so long as every public disclosure of the results of your benchmark test expressly identifies the public site containing all required disclosures; and (5) nothing in this provision shall be deemed to waive any other right that you may have to conduct benchmark testing. The foregoing obligations shall not apply to your disclosure of the results of any customized benchmark test of the .NET Component, whereby such disclosure is made under confidentiality in conjunction with a bid request by a prospective customer, such customer’s application(s) are specifically tested and the results are only disclosed to such specific customer. Notwithstanding any other agreement you may have with Microsoft, if you disclose such benchmark test results, Microsoft shall have the right to disclose the results of benchmark tests it conducts of your products that compete with the .NET Component, provided it complies with the same conditions above.

Edited 2005-11-06 08:42

Neither .Net nor Java is a panacea. Anyone who claims either is far superior to the other is an idiot.

I prefer Java, but I, unlike the idiot .Zealots and JZealots, recognize that it is a tool. Use whatever tool works for you, but don't try to be all high and mighty claiming .Net is far superior to Java, or vice versa.

.Net supports far more languages. Java has a number of languages that target the JVM, but .Net has far more. Java isn't good enough to hold .Net's jock strap in this regard.

Java supports far more platforms. Mono is a good start, but it doesn't have the currency or platform coverage to even think about holding Java's jock strap in this area.