Why Java sucks

[DemonWasp]

Okay, then look at Tribal Trouble ( http://tribaltrouble.com/ ), JMonkeyEngine demos ( http://jmonkeyengine.com/demo/webstart/ ) and JMonkeyEngine tutorials ( http://jmonkeyengine.org/wiki/doku.php/jme3#tutorials_for_beginners ).

All the things you've listed as benefits of XNA are also benefits of JME, with the exception that most of JME is Java. The difference is pretty negligible though, especially since much of the straight-up arithmetic is farmed out to the GPU in either case.

[mirhagk]

But the fact that the library is written in Java is the point. Obviously assembly routines are going to run faster than either language ever could, so the fact that the .NET libraries are all assembly routines is the thing that makes it fast.

[rdrake]

Thread is TL;DR, but...

mirhagk @ Fri Jul 29, 2011 12:37 am wrote:

But the fact that the library is written in Java is the point. Obviously assembly routines are going to run faster than either language ever could, so the fact that the .NET libraries are all assembly routines is the thing that makes it fast.

Yes, but .NET assemblies are different than object code compiled from assembly. Both the JVM and .NET environments compile bytecode down to machine code in a JIT manner when required.

Tools such as ngen exist for .NET to pre-JIT all of the code. That is, run every possible branch ahead of time so the native code is generated. Otherwise the JIT compiler would compile to native code at run-time. I'm sure Java has similar projects.

Another random slap at Java which I personally found amusing: [general] [WARNING] Index corruption and crashes in Apache Lucene Core / Apache Solr with Java 7.

[DemonWasp]

Actually, I don't find it obvious that hand-written assembler will necessarily be faster than compiled code. That may have once been the case, but compilers are orders of magnitude better now, and JVM / CLR run code pretty fast. Often, the performance difference is so narrow you'd never notice it; occasionally, the managed languages are actually faster than equivalent C++ code.

[Tony]

That depends on all kinds of things. Sometimes you might have intimate knowledge of the operating environment (OS, hardware, memory states) that will let you make assumptions that a compiler cannot infer from static analysis alone. Or that are plain illegal (e.g. certain shenanigans with raw memory access). Then you could win in some (in absolute terms... not necessary significant) performance.

But the size of the applications has grown in complexity to a point where anything that runs on top of an OS will benefit from a compiler over hand assembly.

[mirhagk]

I just want people to try out a little experiment. (not sure if it works with Java, since their libraries are written in Java I believe).

Open up a C# project with .NET. create a sorting algorithm, the fastest you can (probably quicksort), and then try to optimize the best you can. Make the algorithm sort an object of type list. Okay now test out the speed. Now call the exact same list with it's built in sort method and compare.

Last time I did this, I sorted some giant data structure (forget exactly how big) in about 3 seconds, and I was so happy. Called .Sort() and it sorted in 11ms. That's what I'm talking about here.

[Tony]

All that this "experiment" shows is that you shouldn't be the one writing library implementations for major programming languages

[DemonWasp]

Err, yeah. Just did this experiment myself. Sorting a list of 1M Integer objects with my custom not-especially-efficient mergesort implementation...833ms. The Collections.sort() API managed it in 653ms.

What the hell were you sorting that it took you a full 3 seconds to sort?

[Insectoid]

Lol mirhagk. People have been improving and optimizing the standard library for years and years now. Good luck writing a better sort function in one evening.

[mirhagk]

It was actually my final algorithm after about a month's lesson's on sorting in school. It was quicksort, so perhaps others may have been slightly faster, but it was definetly the fastest in my class, and it was a true implementation of quick sort.

I don't remember exactly how many integers I was sorting, but I know it was at least a couple million.

Also i mentioned that the experiment probably wouldn't work with Java, which is why demonwasp's results turned out as they did.

Oh and insectoid, I have written better sorting functions than quicksort, or any implementation of sorting. They were only better for certain projects but they were MUCH faster for those projects. (For instance a list where only one item is out of place takes much too long with quicksort, or mergesort, or anything the standard libraries may use, but it's trivially fast with bubble sort, it's all about the application)

[DemonWasp]

Are you sure you didn't have the API sort run on already-sorted data? When I do that, the time for the API sort drops to ~120ms. I seriously doubt that a full sort of "several million integers" occurred in 11ms, no matter what language you implemented it in.

Full list of times I generated (1M Integers for the Collections examples, 1M ints for the array examples):
Collections.sort() - random data - 763ms
Collections.sort() - sorted data - 117ms
Custom mergeSort() - random data - 903ms
Custom mergeSort() - sorted data - 543ms
integer array sort - random data - 242ms
integer array sort - sorted data - 62ms

[phil]

It sounds like you would be happier programming in Haskell

[goroyoshi]

for #2, you can return an array

[bbi5291]

re: sorting: The C++ standard library typically uses introsort. It starts out as quicksort, but falls back to heap sort if it hits too many bad partitions, in order to avoid degenerating to quadratic running time; and below some small cutoff, it uses insertion sort to finish the job (it's non-recursive, so it has less overhead). These parameters are typically carefully tuned and tested against real-world data (and, of course, on real-world machines) in order to obtain optimal performance.

That's why standard library sort functions are so damn fast.

[randint]

Java 7 supports switch (String)