Slashdot Mirror

Java is significantly better now that it was years ago. It's not slow anymore, and I can make Java look exactly like any Win XP or Linux native app in just a few lines of code. Granted, I'm not aware of any easy way (if any) to make it look like a Win 7 native app, but it's looking like it will just be a matter of time before that happens. We are writing a Java Desktop application at work, and we are even doing things like allowing the user to select the theme of the app. Java has very much improved over the last several years.

"It doesn't take a rocket scientist to work out that a GC-based, VM-based language that has layers of intermediate execution is going to be slower than is required for a trading system."

Actually, this is only true in an ever decreasing set of circumstances.

See here for an explanation of some of the common reasons why this is often not the case:

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

Also here are some benchmarks:

http://kano.net/javabench/

These sites are focussed on Java, but the points are applicable to .NET also as it's on par nowadays. In .NET you also get the option of using unmanaged code anyway so you can have areas that don't require the VM to underlie execution.

I'd imagine the real problem in this case was a combination of poor project management with poorly skilled developers in an attempt to make the profit margins for Microsoft and Accenture as big as possible. The net result though, as you can see, is quite bad. I do not believe for a second .NET was the problem as there is no reason it can't be used in a way that performs as well as or better than a C++ application. It would use a bit more memory to achieve that performance, but memory is cheap enough for this to not be an issue for most cases nowadays, particularly when you factor in the benefits of security and resilience you get from the managed parts of the codebase.

What version of the JDK are you using? Java 6 has improved speed considerably.

I'm on 1.6 and have been since beta releases of it, as it added some features I desperately needed. It improves the situation for some floating point algorithms, as I believe it uses processor intrinsic implementations of sin and cos, but not exp.

Here is are interesting benchmarks comparing floating point performance:

1) http://www.fourmilab.ch/fourmilog/archives/2005-08/000567.html

Java is 12% slower than C and Visual Basic.NET is 13% faster. This is based on the usage of an optical design ray tracing programme.

Again, this is using only raw floating point and trig. Sun's Java VM supports processor-based trig functions, but not other transcendental functions.

2) http://kano.net/javabench/

None of these are floating point benchmarks. I agree entirely that there is little reason to avoid using Java for integer number crunching.

Note: If you are raising numbers to an integer power you will almost certainly get better performance doing y = x*x*x than y = pow(x, 3.0) in any language

Agreed. My problem is very specifically calculating 1 / (1 + e^{-x}), which is somewhat slower in Java than in (e.g.) C, and can't be helped with any such transformation.

Here is are interesting benchmarks comparing floating point performance:

1) http://www.fourmilab.ch/fourmilog/archives/2005-08/000567.html

Java is 12% slower than C and Visual Basic.NET is 13% faster. This is based on the usage of an optical design ray tracing programme.

2) http://kano.net/javabench/

Note: If you are raising numbers to an integer power you will almost certainly get better performance doing y = x*x*x than y = pow(x, 3.0) in any language.

First off, its not a requisite that a VM add significant overhead to code. Its true that it can't have zero overhead, but its not true that it automatically causes a massive CPU performance hit and memory explosion. I'll point to one benchmark that at least indicates JVM performance can exceed C++ performance, http://kano.net/javabench/ . (To be clear, Android does not use a JVM, it uses its own VM).

Second, if you base your language choice for a mainstream, general purpose platform, solely on code efficiency, you're making a mistake. Speed is *not* all that matters. Portability and *programmer* efficiency are major factors to consider if you want a successful platform. In these dimensions the Java language and VM execution environments tend to be superior.

Third, for the vast majority of programs, its the code you write, regardless of language that makes the most difference. Languages create far fewer slow programs than poor programmers and designers.

None of this is to say that their aren't benefits to native code, and in the long run Android should provide a way to write native code for those tiny bits of the program that are doing heavy algorithmic work. What I do mean to say is that saying the best language for all your code is C[++] is incorrect (unless all you write is heavy algorithmic code, most applications have more than this).

Try actually benchmarking Java http://kano.net/javabench/ Server-side Java is one of the fastest scalable platforms available.

Here you go - a whole slew of tests (that you can run to prove for yourself), that Java is indeed faster than C++. And these benchmarks are with a slower JVM version. Please become educated about what you talk about. http://kano.net/javabench/

I normally don't feed trolls, but what the heck. Please check your facts on Java performance, for example : http://kano.net/javabench/data

Plus, we have more than half a million of lines of code, which for a relatively small group like ours is huge, so we cannot "just rewrite"... And, it is a mixed platform cluster. There are/will be all sorts of machines running inside, so java makes life easy...

It is just sad how many readers jump straight on the meme of java=slow. Sure, 10 years ago that was the case. Have you ever actually used java to do some heavy lifting ? Try 1.6 and see...

If your code is not doing something awfully specialized like massive matrix inversions and pure floating point calculations, and you dont care about startup times ( our simulation runs are many thousand times longer that the startup) there is very little difference is speed. A massive difference in development cost though. Plus basically ALL agent based modeling platforms are written in java. I wonder why...

But if its on a static machine architecture why bother?

Java's slow

Given that the Mozilla/Firefox browsers have such an enormous codebase to be maintained and debugged would you recommend that the efforts of those developers be spent writing a window manager

No. That is why you use a "standard" Window Manager like MetaCity. It's intended to do the heavy lifting of screen layout while the application instructs the WM according to the agreed upon protocols.

Given that the Mozilla/Firefox browsers have such an enormous codebase to be maintained and debugged would you recommend that the efforts of those developers be spent writing a DE based on it?

Do I think that the Mozilla developers should do it as a mainline part of the Mozilla/Gecko codebase? No. Do I think it should be done as a separate project built on top of the Mozilla platform? Yes. The latter does not necessarily mean a reduction in the developer support for the Mozilla codebase, and may actually attract new developers to working on improving the platform.

Still, though, would you want a comprehensive network application such as a web browser to be directly integrated with the code and memory allocations which make up the display?

I do not understand this point. The Mozilla Platform is NOT a web browser. The Mozilla Platform is a collection of desktop and web technologies that can be used to construct a web browser. Or a variety of other applications. This is no different than the Win32 or Cocoa APIs, both of which contain support for Web Technologies in addition to standard desktop technologies. Thus Win32 systems have Internet Explorer (based on MSHTML renderer), Cocoa systems have Safari (based on WebKit renderer), and Mozilla systems have Firefox (based on Gecko renderer).

My understanding is that the underlying structure of the javascript environment is too rickety to ensure that an application built within it will ever be bulletproof.

Your understanding is incorrect. Javascript/ECMAScript is a full language limited only by its APIs. For XUL applications, Javascript apps have access to the complete XPCOM library; an API similar in concept to Win32 or Cocoa.

As touched upon in a recent discussion on a Slashdot book review, the primary issue with Javascript is that the majority of those who think they know how to program in it, do not.

Modern web browsers, IMHO, already have too much unrestricted access to the rest of the system. This can be configured away by the user but only at a severe cost to modern day functionality. Cookies are an illustration of this point: disabling cookies for an entire day would tank a normal daily network routine.

First off, this is neither here nor there. Issues affecting a desktop web browser do not relate to a desktop application unless it choses to provide web browser services. At that point, the standard issues with accessing network resources apply. It is up to the individual application to find a method of dealing with network security. Just as it is up to any network-enabled Windows or Mac application to deal with network security.

I appreciate that java, in and of itself, isn't slow but that the slowness is often brought about by layering the jvm on top of the already existent OS.

Incorrect. Java has surpassed C++ in a variety of benchmarks. Anyone who has paid attention to Java within the last 7 years is aware of these benchmarks. (Example) While perceived performance problems exist (e.g. slow startup, "feel" of GUI, etc.) the Virtual Machine itself is actually quite fast by virtue of runtime optimizations.

The jvm environment reminds me of the BASIC interpreter which the beloved C=64 provided in that it works like a jit compiler.

The C64 did not JIT the BASIC code. It is well known

Oh, and another thing:

I can compile java bytecode to run faster then optimized C++ apps.

It's been this way for years.


Please hurry with that patch! Also, it would be nice if you updated your script from VB4!!!! ;)

Client side, that is true. Server side, its just as fast or sometimes faster. See http://kano.net/javabench/ and http://www.aceshardware.com/Spades/read.php?articl e_id=153

You don't get it, do you? typechecking is always done statically at compile time, unless you use dynamic_cast; virtual overloading is not avoidable, if you want message passing. C++'s mentality is that you can avoid the cost of what you are not using; so if you don't need virtual methods, you don't use them. If you only need stack allocation, then you don't pay the cost of allocating everything on the heap.

That's a lie. C++ most certainly does do type-checking at run-time.

modern video games have incredibly tight loops,

No they don't. They have an event-pump and a timer. Tight loops are done in hardware these days.

multiple threads of execution,

Only to work around API problems. Threads make for slower execution because the cost of context switching is high (esp. on x86).

network I/O,

No they don't. That's the operating system. Usually it's kernel. On most systems, that's written in C. Note that NDIS is written in C.

controller I/O,

What controller are you talking about?

real-time file I/O (if they are using disk spooling),

Ah, no. Real-time doesn't mean what you think it means. Furthermore, Windows doesn't have any Real-time File I/O interfaces. Nor should it, it's not a real-time operating system.

It supports asynchronous I/O operations, but then, the AIO interface is written in C.

Realtime does not mean "fast".

fully fledged guis (especially PRGs),

Ah no. GDI is written in C. GTK/GNOME is written in C. These things do not require C++.

The Unreal engine alone is over 1 million lines of code.

So what? Do you have the source code? Is it really all C++? What about the code for the GPUs actually drawing things? You know, the parts that have "tight loops"?

but there has never been a conclusive benchmark that proves it. Especially the 'much' faster part.

Here you go.

C is not more deterministic than C++. For the tasks C++ does, C would have to implement them at least in the same way, albeit with much uglier syntax.

But that syntax is explicit.

Take message passing,

C++ doesn't support message passing. Objective-C does.

you can't get faster than vtables.

Ah no. A perfect hash will always beat vtables.

The only difference is that C++ does it in a better way, whereas in C it is more difficult and error-prone.

No, that's wrong. What does if (a << b) do? What code does it evaluate? Do you know?

C++ hides these things, ergo, without knowing what a is, and having it's source code, you cannot tell what the C++ is doing.

I am still waiting for the benchmark that proves that. Guess what? there is not such a beast. Even if the Java hotspot compiler can optimize a series of instructions better on a specific machine, overall Java has enough 'hotspots' to make it slower, overall, than C++.

Here's one you can try at home: Compile this program:

#include <stdio.h>

int main(int argc, char *argv[]) {
puts("Hello World!");
}

Compiled with gcc, this produces a file 4695 bytes long. Compiled with g++, this produces a file 5104 bytes long. To make sure this actually changes the code, main() starts at 0x8048384 and ends at 0x80483ab in C++, but only runs from 0x8048434 and ends at 0x804845f. Clearly, that dynamic type checking you were talking about, not only exists, but has a cost.

I have never seen a benchmark proving Haskell faster than C++. When Haskell can sort 100,000 records in a database as quickly a

For a good rebuttal to the http://kano.net/javabench/ check out: http://www.freewebs.com/godaves/javabench_revisite d/.

• This is not Java vs C++. This is Sun's JDK 1.4.2 vs GCC 3.3.1 on a P4 mobile processor.
• GCC is not a fast compiler, it's a portable compiler that happens to be fairly fast. A fast compiler might be something like Intel's own compiler: http://www.linuxjournal.com/article/4885
• Having proven that method calls take almost twice as long under G++: http://kano.net/javabench/graph - the author then several of the tests recursively ( http://kano.net/javabench/src/cpp/fibo.cpp ). When this benchmark came out, various people on /. managed to get around 1,000 times better perfomance (under G++) by switching to a fixed memory usage non-recursive implementation.

Regardless of the negligible performance hit compared to native code, major software houses, as well as a lot of open-source developers, prefer native code for major projects even though interpreted languages are easier to port cross-platform, often have a shorter development time, and are just as powerful as languages that generate native code.

Particular to Windows programmers, the announcement of MS-Windows Vista's system requirements means that future Windows boxes will laugh at the memory/processor requirements of current interpreted/JIT compiled languages (e.g. .NET, Java , Python, and others).

• This is not Java vs C++. This is Sun's JDK 1.4.2 vs GCC 3.3.1 on a P4 mobile processor.
• GCC is not a fast compiler, it's a portable compiler that happens to be fairly fast. A fast compiler might be something like Intel's own compiler: http://www.linuxjournal.com/article/4885
• Having proven that method calls take almost twice as long under G++: http://kano.net/javabench/graph - the author then several of the tests recursively ( http://kano.net/javabench/src/cpp/fibo.cpp ). When this benchmark came out, various people on /. managed to get around 1,000 times better perfomance (under G++) by switching to a fixed memory usage non-recursive implementation.

Regardless of the negligible performance hit compared to native code, major software houses, as well as a lot of open-source developers, prefer native code for major projects even though interpreted languages are easier to port cross-platform, often have a shorter development time, and are just as powerful as languages that generate native code.

Particular to Windows programmers, the announcement of MS-Windows Vista's system requirements means that future Windows boxes will laugh at the memory/processor requirements of current interpreted/JIT compiled languages (e.g. .NET, Java , Python, and others).

• This is not Java vs C++. This is Sun's JDK 1.4.2 vs GCC 3.3.1 on a P4 mobile processor.
• GCC is not a fast compiler, it's a portable compiler that happens to be fairly fast. A fast compiler might be something like Intel's own compiler: http://www.linuxjournal.com/article/4885
• Having proven that method calls take almost twice as long under G++: http://kano.net/javabench/graph - the author then several of the tests recursively ( http://kano.net/javabench/src/cpp/fibo.cpp ). When this benchmark came out, various people on /. managed to get around 1,000 times better perfomance (under G++) by switching to a fixed memory usage non-recursive implementation.

Regardless of the negligible performance hit compared to native code, major software houses, as well as a lot of open-source developers, prefer native code for major projects even though interpreted languages are easier to port cross-platform, often have a shorter development time, and are just as powerful as languages that generate native code.

Particular to Windows programmers, the announcement of MS-Windows Vista's system requirements means that future Windows boxes will laugh at the memory/processor requirements of current interpreted/JIT compiled languages (e.g. .NET, Java , Python, and others).

you get the slow startup times associated with JIT, and slow execution due to fiddling with bytecode. Let's not forget that the only type of optimisation carried out on the bytecode is peephole optimisation, which is inadequate for the majority of I/O intensive operations. The list goes on and on.

While the following benchmarks are somewhat biased, they fairly reflect the speed of the previous generation of Sun's JVM. The latest one (5.0) improves upon this.

http://kano.net/javabench/

Java's not the perfect tool for everything, but in my experience, it's great for making server applications that need to be reliable, maintainable, and fast, in that order. This is roughly the order in which many businesses need their software to be.

Soooooo not using an interpreted or JiT'd language when you have to pay $1 per CPU hour....

Perhaps not JITted code, but for long running processes, a modern mixed-mode JVM like hotspot can kick the pants off a similar C/C++ program. So using the latest Java VM may actually save you money by executing your code as efficiently as possible. You can probably get pretty close with a static compiler by optimizing specifically for the machines that Sun uses, but it would be hard to beat out a runtime JVM that knows the current execution path of the code.

Does gcj work on solaris/Opteron?

It should work. But you'll be running with 32 bit instructions, which will probably slow you down considerably.

Ahh...your typical uninformed slashdot poster...

You do realize that array bounds checking is eliminated by modern VM's? i.e. HotSpot. Suggest you read:

http://java.sun.com/products/hotspot/docs/whitepap er/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_4 .html

The Java version of Quake performs faster than the C version:

http://www.bytonic.de/html/benchmarks.html

Here are some other benchmarks:

http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html
http://kano.net/javabench/

Java VM's such as HotSpot have the ability to de-optimize and re-optimize on the fly. C/C++ can not do that.

Stop repeating the lie that Java is slower than C/C++.

Though this is not the most comprehensive article I have seen on the topic, a basic primer of AIM security for IM developers is available here.

This is an interesting comment, but in my opinion all you are doing is describing a series of reasons why you think that Java should not be able to match C++ speed.

But this is irrelevant. It does! Here is an example:

http://www.kano.net/javabench/

Just to correct one misunderstanding - Hotspot is not a typical optimiser, C++ style. It does not significantly impact performance, as it is not a full profiler - it detects 'hotspots' - performance critical areas and concentrates on them - it does not profile the entire application in detail (which would certainly impact performance).

The reason why this sort of thing is not used much elsewhere is that it is extremely hard. It is based on technology developed from the Self language, and has involved years of research. Also, until now, there has never been much of a need. Pre-compilation has been good enough for languages like C++. However, with Java, pre-compilation is often problematic.

The widespread use of Java in whatever industry you are is not likely to happen no matter what the performance, as areas of the IT industry are very conservative - for example, much game development is still in assembler, and COBOL is far from dead.

Guess what? I also write high-performance code - numerical simulations of molecular interactions. Java is the first language that looks like it may at least start to replace Fortran in this area.

Bollocks. This run-time profiling is a total myth. Java still badly loses benchmarks where, if your claims were true, it should win handily.

That is a broad claim, and is utter nonsense.

Java simply doesn't badly lose benchmarks:
http://www.kano.net/javabench/

I bet you were wanking while you wrote that.

Way to go to get modded up.

Fortunately, most people have a more realistic vision of Java. Namely that every Java app they've ever tried blows... drinks memory like water (and never gives it back) and slows their machine to a crawl while being spectacularly ugly. (and yes, this is with Java 1.5 *and* with the Mustang dev versions).

Fortunately most people have a more realistic vision of Java that you, which is why it is so successful. It is your opinion against the majority.

By the way - Java *does* give memory back. You need to research more.

That's what happens when you consolidate your energies rather than using a random collection. I'd be interested to know what these other languages were.

"It's much faster to write the application in php, then identify performance issues and code those functions as c++ extentions than it is to write the whole thing in java. This is Radwin's point, and I've seen it proven repeatedly in practice."

There's a problem with that. You now have to have developers know php and c++ which negates one of the benefits of PHP being easier to program. Whereas with Java you're starting off with better speed and if you need to go to native api's you can still do that through JNI and going from java to cpp is a lot easier than going from php to cpp from a coding perspective. (The languages are more alike).

"'Java's as fast as C++'. OMFG. LOL."

Ok, now I know you haven't used java or haven't touched it in years. On the server side JIT compilation really shows it's strengths. And things are going to only get better as cpu's continue to have greater threading capabilities which PHP can't usually take advantage of until more modules are made thread safe. JIT compilers can inline a method increasing performance and use other static calls. Intel worked on features of the P4 and Xeon processors to perform better with code with a lot of branching and inderection. They did this with JVM's in mind. The JIT compiler can reduce the number of branches and it's branch prediction is right most of the time. More than static compilers anyway. Delays on these processors for a correctly predicted branch are down to almost zero clock cycles.

Here are some links in case you don't believe me.

Java Pulling Ahead, Java faster than c++, Computer Language Shootout, http://www.tommti-systems.de/main-Dateien/reviews/ languages/benchmarks.html">This shows them mostly similar, this is an interesting read too

No, go back to your big 'O' notation. Throwing big computers at a problem doesn't always get it to run fast.

Anyway, Java apps usually run similar to C depending on what you are doing. Like any benchmark though, you can make Java run faster than C or slower, depending on your goal.

I have to disagree here. There are certainly cases where Java is faster, but they're relatively few. Lets just go through that infamous benchmark again:

Java faster than C++ benchmark

Point 1 - "I was sick of hearing people say Java was slow, when I know it's pretty fast".
Baaaad start to any analysis - always keep an open mind about the results.

Point 2 - He used G++. So this is only valid for G++, not necessarily any other C++ compiler. Which is fair, I just feel this is worth emphasising.

Point 3 - It's rapidly determined that G++ takes much longer to execute a method call, than Java does. Given this, it shouldn't be a significant suprise that benchmarks relying heavily on recursion will be slow in C++.

For example, rewriting the Fibonnaci benchmark to use a for loop instead of recursion give a 600-times speed increase:

http://developers.slashdot.org/comments.pl?sid=111 205&cid=9436176

Rewriting it into constant-space gave an almost 10 times increase over that:

http://developers.slashdot.org/comments.pl?sid=111 205&pid=9438782#9439949

Moral of the story? Java is great for method calls , but I'm not so convinced about everything else...

Java does fix many cross-platform performance problems by leaving the optimization up to the virtual machine, it's a similar to what Transmeta does. Some People are even claiming that Java programs are faster than programs written in C++. Less biased benchmarks still put the Java VM just a bit slower than GCC and a lot slower than a really optimized compiler(Intel's).

Leaving aside the results or whether the benchmark is meaningful, his presentation of the results in the graph is truly awful. The one large spike for Method Call/Server JVM is so large that all the other results are nearly visually indistinguishable.

He admits he couldn't write a script to automate the tests. That does not inspire confidence in his ability to assess programming languages.

It also does stupid things. Like this:

int c = 0;
for (int i=n; i>0; i--) {
sprintf(buf, "%d", i);
if (X[strdup(buf)]) c++;
}

int c = 0;
for (int i=n; i>0; i--) {
if (X[atoi(i)]) c++;
}

The alternative is actually shorter, besides being faster and using less RAM.

I think the person which wrote this didn't know how to program in C++ very well. The two pieces of code are not even equivalent. The second loop is traversed backwards in the C++ version while it is not in the Java version. Don't ask me why.

It also does stupid things. Like this:

int c = 0;
for (int i=n; i>0; i--) {
sprintf(buf, "%d", i);
if (X[strdup(buf)]) c++;
}

int c = 0;
for (int i=n; i>0; i--) {
if (X[atoi(i)]) c++;
}

The alternative is actually shorter, besides being faster and using less RAM.

I think the person which wrote this didn't know how to program in C++ very well. The two pieces of code are not even equivalent. The second loop is traversed backwards in the C++ version while it is not in the Java version. Don't ask me why.

Why did he use only -O2?

-O3 adds function inlining and register renaming.

Also, some of the code doesn't look too much of a test of the language, but more of a test of the libraries. Both versions of hash rely on the library implementations, and it looks like hash.cpp does an extra strdup that the java version doesn't. I don't know either of the hash libraries well enough, but I don't see why this significant slowdown would be necessary in the gcc version.

The Java is Faster than C++ and C++ Sucks Unbiased Benchmark

Well, look here and here.

Oh look, these people are patently under 14</sarcasm>

That in under a minutes googling. Now crawl back under a rock troll.

And for people who STILL believe that Java is slow, download eclipse (the url is above, for those of you can't google for it, or even guess it) and have a play...it's written in Java and *GASP* is not only a)amazingly useful, but b)damn snappy, seriously, those people who said Java would never work on the desktop because its too slow, they can start eating their hats.

Plus, I just did a job search for c++ vs. Java on a uk job site and guess what, the number of results returned was nearly identical, so by the look of things, lots of people and companies use Java. IMHO, for enterprise n-tiered applications its the shiznitz.

The reason that Java can be faster is because you can do some really nifty optimisations during runtime with the latest JIT compilers that are impossible (or at least monumentally difficult) to do with compile c/c++ code.

In closing: Here is another benchmark...maybe because he has a domain name you'll trust him more?