Java vs. C execution time

[Markbnj]

Originally posted by: degibson

Originally posted by: Markbnj

Something like the CLR/VM will eventually be running in firmware.

I'm really against you on that -- runtimes and VMs are just too big for firmware, for one. And its not like these things don't themselves change all the time.

If there's one thing history has shown about software evolution, its that software accumulates in layers, and the old layers rarely, if ever, die. I fully think that future application layers will expose managed languages primarily, but managed languages may never be able to compete with raw C for performance-critical enterprise systems (e.g. commercial databases, big $) and performance-critical non-enterprise applications (e.g. games, also big $). Web applications, GUIs, etc., are of course all non-critical and can easily take a 10x slowdown on the client side without the user noticing. (not to say that the managed language impact would be 10x, that was just a number)

Well, you're certainly right that no matter how fast the processors and memory get, or how much of the latter we have available, native code will always run faster by definition. On the other hand, the risks inherent in native code development, as well as the difficulty of training people with the appropriate skills, will relegate its use to a smaller and smaller subset of development over time. Eventually I still believe the managed code environment will run on the hardware, but I admit it could take a long time to get there.

 

[degibson]

Originally posted by: Markbnj
Eventually I still believe the managed code environment will run on the hardware, but I admit it could take a long time to get there.

This seems reasonable, especially since managed code isn't usually all that different from unmanaged code. You could probably compile 'well-behaved' managed code directly to hardware right now. The lacking parts are the hardware hooks to make it manageable, pun intended. There's plenty of ongoing research on fine-grained memory protection -- what else is needed?

 

[Markbnj]

There's plenty of ongoing research on fine-grained memory protection -- what else is needed?

You'd know better than I, from what I've seen of your posts. I'm not really the low-level language guy I was twenty years ago. Haven't had time to keep up with it and still grow skills that people will pay me for. So I focus much more on the application layer these days, but because I've been at it a long time I think I have a pretty good sense of where things are headed. In general the problem that vexes me the most is the incredibly low bar for people who call themselves programmers these days. I run into people all the time who can't even write a paragraph without mispellings, much less engineer good code, and they almost never know why something works or doesn't. If I had a dollar for every question like this, "Hi! I'm in charge of developing the database for a mission-critical trading system. Can someone tell me what a table is?" well, I'd have some money .

And that's the primary reason why I think we'll all be writing managed code in the future.

 

[degibson]

Originally posted by: Markbnj

... I run into people all the time who can't even write a paragraph without mispellings, much less engineer good code, and they almost never know why something works or doesn't. If I had a dollar for every question like this, "Hi! I'm in charge of developing the database for a mission-critical trading system. Can someone tell me what a table is?" well, I'd have some money .

And that's the primary reason why I think we'll all be writing managed code in the future.

I remember that kind of 'coder'. Fortunately, I'm currently surrounded by really competent people, but there are some idiocy barriers that no dumbing-down and safety-ifying of a language can breach. However you're really correct in your belief about managed code -- heck, already managed code is staggeringly popular (by number of projects).

I tend to come on pretty strong on this topic because the thought that I might one day be forbidden by some upstart compiler from doing pointer arithmetic frightens me. It reminds me of the days before I had a good understanding of what was going on under the hood. I firmly believe that that understanding is critical... it might even be possible to develop such an understanding in a managed environment... but I haven't tried. I, for one, was clueless until my sophomore year of college when they dumped me into my OS course and expected me to know C. I learned a helluva lot that year, and very little was actually about OSes.

Kudos on misspelling mispellings, by the way. I'm not a spelling nazi, but I did enjoy the pun.

 

[duragezic]

Originally posted by: kylef

Originally posted by: duragezic
I think compiling the code instead of interpreting made the biggest difference by far.

You said that you're running on an embedded platform? What JVM are you using?

Anyway, thanks for posting back your findings.

Yeah running on a Freescale MPC5553, common processor for automotive apps. JVM is JamaicaVM.

 

[Markbnj]

I tend to come on pretty strong on this topic because the thought that I might one day be forbidden by some upstart compiler from doing pointer arithmetic frightens me. It reminds me of the days before I had a good understanding of what was going on under the hood. I firmly believe that that understanding is critical...

We're definitely on the same page. I taught myself with help from a lot of people on Compuserve back in the late 80's, working with Pascal, 80x86 assembler, and then C++. I first programmed in the mid-70's on an HP-3000 mainframe in BASIC using a teletype for input/output. But in the 80's the motivation was figuring out the hardware. If you wanted to do mode-x you needed to know the VGA; if you wanted hi-res timing you needed to understand the 8254 PIC family; if you wanted low-level control over keypresses you needed to know how to read the keyboard port, and all of it required some assembler, either compiled or __emit__ed as bytes in C code.

I don't think many people will get this kind of intro in the future.

 

[degibson]

Originally posted by: Markbnj

I don't think many people will get this kind of intro in the future.

Yea, serious bummer.

 

[Extrarius]

If you want to run java on an embedded platform and you care about speed at all (or, even worse, want to call it real time), then you want to use a Java Optimized Processor where the java can be run natively.

Comparing java run on a JVM to natively-compiled C is similar to having an uneducated child calculate with pencil and paper using reverse polish notation and a computer scientist calculate on a computer using standard notation and then declaring that reverse polish notation is slower.

Comparing natively-compiled java to natively-compile C is much better, but you're still not comparing the java language to the C language - you're just comparing the java compiler to the C compiler. Either one could come out on top, but most companies spend much more work on making a quality C compiler because that is usually the lowest common denominator (excepting platforms where assembly programming is considered acceptable).

 

[JACKDRUID]

Originally posted by: duragezic

I don't remember specific numbers, but we ended up with C being something like 315 times faster than Java.

C is always faster simply because there is no memory management/ garbage collection , compilation overhead.

these threads are amusing... I don't understand why some people kept saying managed code is faster... its simply impossible to be faster DUE TO OVERHEAD.... they need to realize they cannot have the best of both worlds. reliability/ portability in managed code = little sacrafice in performance.

 

[duragezic]

Heh, wow, old thread. I'm out of school and trying to forgot about this.

We got the Java performance way better, but still ended up a lot slower than C, and a lot of the improvement was due to compiled Java versus interpreted. And as said, the C compiler was much more mature so it came down to compilers mostly when you did compiled Java vs compiled C. But the real-time performance with Java was pretty good. I think the main issue they had with our results was the raw peformance being a lot slower no matter what. But other types of programs might use some of Java's strengths and lessen the difference.

 

[hans007]

supposedly if you are a C coder and do not know how to use threads properly a lot of hte java libraries are coded more for that so it could be faster if you were bad at writing code.


as to the other comments about people never even learning how to do things the right way i have to agree with that. sadly i'm considered "old school" at my company and i'm 27. i started messing around computer when i was like 6 and actually screwed around with basic because in 3rd grade the school bought a computer lab an dput random posters apple sent with basic code on them. sort of a weird way to learn but you just type that stuff in and it worked!.

that said, some people at work seem to even think something like say perl is faster than C execution wise at say parsing xml because it has regexes.

and i'm sitting there thinking, wait uh wouldnt the perl regex engine probably be written in C. we actually were sitting around the other day lamenting that the massive amount of cpu and memory we have now, makes people completely not care about optmizing their code, using a language like C++ anymore etc because you have so much speed to burn, that its not worth bothering to even learn C++ anymore. most colleges dont even teach ASM or C anymore because its all moved to java or C# or python even in the intro classes. that and they are tyring to my computer science a field more people will major in so they are in effect dumbing it down since theres basically a lack of engineering talent in america now.


its like no child left behind for engineering. i'm sure we all want our future real time OSes running our fighter planes to be written by these people YEA!!!

 

[Fox5]

Don't know about java on other platforms, but Java on x86 desktops has pretty much closed the gap with C in most areas in terms of performance. In terms of performance at much higher memory usage however. Java on other platforms may not be optimized so well, especially for smaller apps.

 

[trexpesto]

RTJava can still use JNI?

 

[degibson]

Like the phoenix, this thread emerges from the ashes and is again alight!

However, lets have a debate about this anyway. But this time, lets talk about language features and not compilers. Are there language features that hinder or prohibit high performance? GC seems like a good candidate, but there are quite fast background parallel GCs ... what else? Type checking?

 

[Extrarius]

If you do some research on memory management, you'll find a lot of information about ways garbage collection can be faster than manual memory management from a runtime performance perspective. Put simply, the more control the memory manager has over memory, the less work it has to do to give you some when you ask for it and the less work required to reclaim the memory when you're done with it.

Custom memory allocators (combined with compiler help for more complex algorithms) can be much faster than the simpler allocators normally used for manual management. It might be a close race in single-threaded programming, but in multi-threaded programming it's not even a contest (managed memory allocation can be much faster and can provide awesome advantages for inter-thread communication).

That said, I'm speaking in computer science terms - theory. Whether Java or .Net or any other particular language platform have such optimized allocators in any particular implementation, I don't know. I work primarily in C++.

As far as I'm aware, neither Java nor .Net have any features that make them inherently slow.

 

[JACKDRUID]

Originally posted by: Extrarius
If you do some research on memory management, you'll find a lot of information about ways garbage collection can be faster than manual memory management from a runtime performance perspective. .

so what is it that can only be done with automatic memory management and cannot be done manually?

 

[Extrarius]

Originally posted by: JACKDRUID

Originally posted by: Extrarius
If you do some research on memory management, you'll find a lot of information about ways garbage collection can be faster than manual memory management from a runtime performance perspective. .

so what is it that can only be done with automatic memory management and cannot be done manually?

Technically, you can do it all manually (which is self-evident), but using new/delete or malloc/free using the standard idioms for C++ or C respectively is not the way to achieve such performance.

As an analogy, consider programming in C++ vs programing in x86 assembly. It is possible to write a program in each that uses the same algorithms and overall structure and make the assembly version faster by taking advantage of knowledge the C++ compiler does not have. However, an average programmer does not have the knowledge necessary to outdo the the C++ compiler's output, and it is quite likely the assembly version will be slower (not only because the programmer doesn't know all the tricks, but also because some of the things they think they know are wrong - tons of outdated information out there).

If you took the time (several orders of magnitude more), you could possibly beat the C++ compiler, but then you'll have a mess of horribly unmaintainable code that perhaps performs a few percent faster. Then the other guy runs his C++ program through some profile-guided optimization and adds a few compiler-specific keywords to give the compiler a bit more information and you're back where you started except his code is usable.

The same is true of memory management - automated systems can perform very, very well with little-to-no human assistance vs standard manual management idioms, and can perform even better with a bit of tuning and tailoring to a particular application. You could reproduce all the same operations and still maintain manual management if you wanted to, but it isn't easy (computers are better at some kinds of computations than people!), the end result isn't pretty (taking things into your own hands means you have to do much more and/or lose many of the benefits), and the gains are not significant.

 

[degibson]

Great points, Extrarius. I'm right with you on memory management criticality, especially for multithreaded codes.

To provide a performance-related example:
Since processors have caches, not all memory is equal. Smart memory managers can leverage locality -- dumb ones don't pay as much attention. This matters even more in multithreaded codes -- thread-local allocators will usually purposely allocate distant portions of memory to each thread, to cut down on coherence and false sharing.

 

[JACKDRUID]

Originally posted by: Extrarius
. You could reproduce all the same operations and still maintain manual management if you wanted to, but it isn't easy (computers are better at some kinds of computations than people!), the end result isn't pretty (taking things into your own hands means you have to do much more and/or lose many of the benefits), and the gains are not significant.

so.. in other words, you agree that with good programming manual management is faster.

frameworks are great but its not made for fastest speed. Its for good speed+ great security.

 

[Extrarius]

Originally posted by: JACKDRUID
[...]so.. in other words, you agree that with good programming manual management is faster.

frameworks are great but its not made for fastest speed. Its for good speed+ great security.

I suppose for some definition of "good programming", sure. Personally, though, if I were paying somebody's salary, I'd want the guy that would produce clean, efficient code using the best tools available and not the one that could take a hundred times longer (and cost proportionally more), produce an unmaintainable mess, and potentially save me a few clock cycles that weren't needed in the first place.

(Hard real-time code doesn't use memory management in the first place, and soft real-time code will generally use some kind of automatic memory management like bulk-free arenas which is a really simple automatic management technique used in such products as apache).

An assembly guru (that knows the target system inside and out, has read all the manuals Intel and AMD released, etc; NOT an average or even good programmer) can possibly outperform a good C++ compiler. Then again, his expertise could be applied to improve the compiler and make beating it even more difficult. The same is true of memory management - an expert with enough time can beat a fully automated system only because he has information it doesn't.

If a Java or .Net application is slow, it's not because it uses garbage collection - at most, it is because it uses a slow garbage collector. The more likely explanation is that the programmer did something incorrectly (using the wrong data structure or algorithm) or some other aspect of the system is lacking (unsophisticated compilers, inefficiencies demanded by a standard of some kind, etc).

 

[degibson]

I have no choice but to parrot myself (pun intended) and say again: Great points, Extrarius.

 

[kylef]

If a Java or .Net application is slow, it's not because it uses garbage collection - at most, it is because it uses a slow garbage collector. The more likely explanation is that the programmer did something incorrectly (using the wrong data structure or algorithm) or some other aspect of the system is lacking (unsophisticated compilers, inefficiencies demanded by a standard of some kind, etc).

Garbage Collection can certainly be a bottleneck that an equivalent C++ implementation would not have, especially if the managed programmers take the "commonly accepted" advice to heart about not worrying too much about creating heap objects. All of that garbage has to be freed, and in long-running programs it can cause major latency problems, which can be a significant performance disadvantage. (The .NET 4.0 garbage collector, for example, halted all threads when performing a collection cycle... which is a major perf hit!) I saw one service that created heap objects for every inbound request produce so much garbage, that it was "freezing" for up to 10 seconds at a time every 15 minutes or so of runtime. Yes, re-designing the application reduced the usage of heap objects, but that's not what most people recommend you do when writing code initially, so it is a pitfall and can be very expensive to address later.

GC is not the only culprit, for sure. Sometimes it's the language ecosystem (like the framework/library) that causes problems, not the language itself... but it's hard to differentiate the two if there are no good workarounds. I remember debugging a particular tool that was a health monitoring service for a load balancer, where most of the endpoints were checked via HTTP GET URLs. At any given moment, the service could expect ~10% of the roughly 50,000 endpoints to be unresponsive and cause a connection timeout. But unfortunately the HTTP library in the .NET Framework always threw an exception for connection failures, and there was no way to avoid it by returning a simple error code instead! The volume of exceptions crippled performance of the C# implementation of the health monitor service. Re-implementing it with virtually identical logic in C++ instantly got a 20X performance improvement primarily because the WinHTTP APIs don't force exception handling down your throat.

 

[Maximilian]

Well its 7 years later.... I wonder what turned out to be faster

 

[Cogman]

Depends on what you are doing.

In the last 7 years, the JVM has gotten very fast and the garbage collectors available are top notch. Java can be anywhere from as fast or faster than C/C++ (works really well in heavy inheritance problems), to roughly 2x slower.

Java also does pretty well in scenarios where you are allocating and freeing a bunch of memory. It struggles with things that rely heavily on the CPU cache, the classic example is iterating over an array of Point objects and doing something with the values in the points. C++ can do that faster because you can allocate a block of contiguous memory. In java, it will be spread all over the place.

That being said, java's compacting collectors do help tremendously with at least improving the likelyhood that the cache will be populated with useful memory. It also helps that CPU caches have blown up in size.

If you have complex data models. Java wouldn't be a bad choice. If you have simple data models that require lots of math, C++ and C are better choices.

 

[Sankar789]

I thought Raw C compiler is really quick.