Slashdot Log In
Java Urban Performance Legends
Posted by
CmdrTaco
on Sun Oct 09, 2005 08:19 AM
from the still-don't-like-java dept.
from the still-don't-like-java dept.
An anonymous reader writes "Programmers agonize over whether to allocate on the stack or on the heap.
Some people think garbage collection will never be as efficient as direct memory management, and others feel it is easier to clean up a mess in one big batch than to pick up individual pieces of dust throughout the day. This article pokes some holes in the oft-repeated performance myth of slow allocation in JVMs."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Nonsense (Score:5, Funny)
Robomaid (Score:5, Interesting)
Re:Robomaid (Score:3, Insightful)
Re:Robomaid (Score:5, Insightful)
In seriousness, look at the bugzillas and changelogs of any programming project. Memory leaks abound. So the reality is that memory de/allocation programming eats quite a lot of productivity, and impedes many otherwise ready releases. Of course we can de/allocate memory properly in C. And we can compute with scientific calculators. When we've got something better, we use it.
Parent
Re:Robomaid (Score:3, Insightful)
Also, let us not forget that java has memory leaks too [ibm.com] and in my opinion they are much less obvious than C++ memory leaks.
Re:Robomaid (Score:5, Insightful)
At least in Java you only need to worry about one problem: removing items from caches, logs, queues, etc when you are done with them; in C++ you have to also worry about de-allocating that object, which requires strict planning since the object must not be referred to anywhere else when you de-allocate it. In general you can't prove that the object isn't still referred-to by someone who had it before it was put into the cache/log/whatever; instead you need to establish rules and write documents to make sure everyone knows what the lifecycle of an object should be.
As for your company not having a memory bug logged in 3.7 years, that's great, but without knowing what kind of applications you write, or how they're used, it's hard to say if that's significant. Some programs, like, say, grep, or mv or ls or any one-time-use utilities may be rife with memory leaks, but who cares? When the program terminates the memory is freed, and the user will likely not notice the leak. But even if your apps are long-running network services or whatever, I bet the time spent by developers preventing memory leaks is significant, even if that time is completely spread out throughout the development cycle instead of in large, easy-to-spot chunks running Valgrind or some other profiler.
Parent
Re:Robomaid (Score:4, Insightful)
The fact is that Java programs include more intelligence about programming from the compiler and the JVM. So programmers are more productive than with C. Which means that the same programmer budget can produce more product, or a lower budget can produce the same product. With distributed teams, outsourcing, OSS integration projects, those considerations are crucial to project success. Sure, quality projects also require good design and management. But Java eliminates some quality problems right out of the box. That can't be dismissed merely by saying "hire good programmers, not bad". Because it's a continuum, with a sliding scale of costs that isn't always proportional to productivity.
Parent
Re:Robomaid (Score:4, Funny)
I have never had any memory leaks, just by including the following code snippet:
Parent
Re:Robomaid (Score:5, Informative)
No, you can't. At most you can give the JVM a hint that it would be nice to collect garbage now. The JVM is free to ignore that hint, and many JVMs will do just that.
Parent
Java Urban Performance Legend #1 (Score:5, Funny)
They're good.. now.. (Score:5, Insightful)
Yes they are. Now. 10 years ago when Java applets were being embedded in webpages (to show rippling water below a logo
Just goes to show that even if you have a great technical product you'll still need the marketdriods. Unfortunately.
Re:They're good.. now.. (Score:4, Informative)
Parent
BULLONEY!! (Score:3, Insightful)
Java is slower. Don't even get me started on C#.
Re:BULLONEY!! (Score:5, Interesting)
I should hope not! Any form of benchmarking of Microsoft's
So when Microsoft declares their interpreted inverse-polyglotic language as "faster" than compiled pure C, just accept it. Best for everyone that way.
the FACT is that people's real-world experience, no matter how anecdotal, consistently demonstrates that Java is MASSIVELY slow than similar apps in C or C++.
Well, the linked article contained a number of what I will graciously call "assumptions" (rather than "outright lies") about allocation patterns in C/C++ that simply don't hold true in most cases.
For example, the parent mentions the old "stack or heap" question... Which no serious C coder would ask. Use the heap only when something won't fit on the stack. Why? The stack comes for "free" in C. If you need to store something too large, you need the heap. But then, you can allocate it once, and don't even consider freeing it until you finish with it (generational garbage collection? Survival time? Gimme a break - It survives until I tell it to go away!). As for recursion... You can blow the stack that way, but a good programmer will either flatten the recursion, or cap its depth.
And the article dares to justify its "assuptions" by comparing Java against a language interpreter such as Perl. Not exactly a fair comparison - Yes, Perl counts as "real-world", but in an interpreter, you can't know ahead of time anything about your memory requirements. At best, you can cap them and dump the interpreted program if it gets too greedy. Now, some might point out that Java gets interpreted as well - And I'll readily admit that, for doing so, it does a damn fine job with its garbage collection. But if you want to compare Java to Perl, then do so. Don't try to sneak in a comparison to C with a layer of indirection.
One last point - The article mentions that you no longer need to use object pooling. SURE you no longer need it - Java does it implicitly at startup. You can avoid all but a single malloc/free pair in C as well, if you just steal half the system's memory in main(). Sometimes that even counts as a good choice - I've used it myself, with the important caveat that I've done so when appropriate. Not always. I don't have malloc() as the second and free() as the second-to-last statements in every program I write. And that most definitely shows in the minimal memory footprints attainable between the two languages... Try writing a Java program that eats less than 32k.
Parent
Re:BULLONEY!! (Score:4, Informative)
Or NOT consider freeing it when you forget about it... as the case may be.
Try writing a Java program that eats less than 32k.
No problem at all. [sun.com]
Parent
Re:BULLONEY!! (Score:5, Insightful)
Programming takes some level of skill.
If you "forget" to increment a pointer, it won't have advanced the next time you use it. If you forget to open a file, assuming your program doesn't crash, anything you write to it goes to the bit bucket.
If you forget a wife' birthday, you'll have a pissed-off wife.
"Try writing a Java program that eats less than 32k."
No problem at all.
Uh-huh... Now do the same thing without needing a special, stripped-down, nearly featureless JRE. I don't need a special build of GCC to satisfy the condition, why did we shift from apples to oranges to make it possible in the Java world?
And most of these points end up exatly there - Apples and oranges. Java can do better than a few worst-case scenarios in C. Java can fit in a sane amount of memory with special builds. Java can outperform C by-way-of Perl. All nice claims, but self delusion doesn't make for better programmers.
Parent
Re:BULLONEY!! (Score:5, Insightful)
Parent
Re:BULLONEY!! (Score:5, Insightful)
I'm not about to forget my girlfriend's birthday, because my computer warns me about it three days ahead of time. Similarly, why should we risk forgetting to deallocate stuff from the heap, when we can have the computer do it itself? Yes, programming takes some skill. But we shouldn't start programming using only our thumbs while dangling over a pit of lava, just to up the skill factor needlessly. If we're going to do something more difficult, we need to get a benefit for it. The benefit of not using a garbage collecting language is that your code will probably be slightly faster than the equivalent code in a GC language. But, is that slight performance increase worth the pain in the ass of doing it the manly way? In most cases, not really. But hey, judge for yourself: find the best language for your particular job and forget the rest.
Parent
Really? (Score:5, Informative)
Parent
Re:BULLONEY!! (Score:4, Interesting)
There aren't many professional-grade Java Desktop apps out there, and those that _are_ out there are generally built for maintainability, not speed (Eclipse, Netbeans). I built a Java web client that blew the pants off its older C++ version. The reason Java apps are generally slower is because the Java culture is about maintainence over performance.
Parent
As I see it. (Score:4, Interesting)
Just for you (Score:4, Informative)
Parent
Article somewhat ignores the fatness of the JVM (Score:5, Informative)
Re:Article somewhat ignores the fatness of the JVM (Score:5, Informative)
Try "java -X". You will see that you can decide what the "right" size is. See this link, a guy forces the JVM to run a web server on 16 mb of memory and still get decent performance [rifers.org].
Parent
Re:Article somewhat ignores the fatness of the JVM (Score:5, Insightful)
Besides, I thought the biggest examples of Java was that it was all cool and dynamic and took care of things for you. It seems fair to me to expect such a language/platform to be smart enough to figure out that it's not polite to walk to the buffet, heap three plates with a ridiculous pile of food, and go back to the table and graze on a few pieces of celery, leaving the rest of the food untouched.
Parent
Article Actually Argues Something Else (Score:5, Informative)
Re:Article Actually Argues Something Else (Score:4, Insightful)
Valid point... for 1999. But Java has been through a lot of changes since "the original JBuilder" came out. There have been three major changes to the class libraries (1.2 [sun.com], 1.4 [sun.com], and the 5.0 [sun.com]).
Honestly, I understand why people are down on Java -- it's because there have always been two strengths to the Java "platform":
That said, I think you hit the nail ont the head -- people are still thinking in terms of 1999 and not 2005 when they think of Java -- at least on Slashdot. But the typical Java developer is busy writing enterprise apps, not writing kernel code, device drivers, or anything else that requires C/C++.
Parent
The problem I have is that (Score:5, Informative)
Re:The problem I have is that (Score:4, Insightful)
You can't just compare Java allocation to:
Foo *foo = new Foo();
You also have to compare it to:
Foo foo;
Experienced C++ programmers will prefer the latter both because it is faster and because you don't have to worry about freeing it. One of the problems with a lot of the "See, Java's faster than C++!" comparisons is that they tend to translate directly from Java to C++, ignoring the things you can do in C++ but not Java (like stack allocation) that have a huge performance impact.
Parent
First! (Score:5, Funny)
Re:MOD THIS UP!!!!!! +9 FUNNY (Score:5, Funny)
Too funny!
Parent
The performance red herring (Score:5, Insightful)
1. Make it work.
2. Make it work well.
3. Make it work fast
And #3 is the most interesting... how fast is fast? In an absolute sense, sure, C/C++ will always be faster. But does the end user notice this in a webapp? NO!
I have a p3 450mhz box running Tomcat/MySql. It serves my local applications fast enough. The server can render the page much more quickly than my browser (on a p4 1.5ghz box) can render it. As a webapp, java on an old machine is plenty fast.
Java as a desktop GUI is an altogether different story, but I'm not using java on the desktop. This point is moot to me.
"Fast enough" to not be noticeable. That is the secret of #3. In a webapp, this is easily achieved in java.
Interesting, but I doubt it'll work (Score:4, Interesting)
The first one is the need for a huge amount of memory. It would seem that the optimal way of dealing with this is restricting the amount of memory available to the application, otherwise any app can grow to the maximum size allowed by the VM, whether it needs it or not. But this sounds rather crappy to me, now every developer needs to figure out an right limit for the application.
The second is that performance is going to suck when garbage collection is performed. The slowdown could be a lot larger than a single execution of malloc/free, especially if virtual memory is taken into account. The unused half of the memory will often be quickly moved to swap by the VM, especially when the process grows to sizes in the order of hundreds of MB. Then GC will force bringing all that back to RAM, while possibly swapping the previously used half to disk. Exactly the same situation as what's described with heap allocation, but a whole lot worse.
It sounds to me that even if malloc is slower, it's a lot less inconvenient in applications like games, where something that is always slow can be taken into account, but where a sudden run of the GC could be really inconvenient.
But this is not my area of experience, so it's just what came to mind. Can anybody confirm or refute these suspicions?
This is Not News (Score:5, Interesting)
The author went on to make a very fast GC that set speed records.
If you are looking for factual arguments, with performance measurements and so on, just look at his work over the last few decades -- you'll see he did a lot of work in these very practical areas.
When you see how productive guys like him can be, it makes me wish that some people would just stay alive, and keep working, for a few hundred years more, instead of our typical mortal lifespans.
Java memory allocation vs. malloc (Score:5, Interesting)
However, thats not the problem. All memory in a Java program has to be allocated dynamically. Other languages offer static memory alternatives. Static memory use will be more efficient in many cases.
The my language is faster than yours argument is inherently stupid. There is no "best" language. You need to use the right tool for the right job.
--Barry
Programs (Score:5, Insightful)
Custom mallocs (Score:4, Insightful)
Which is the point.
Systems programmers write systems code. There is no one size fits all. There is no silver bullet. Comparing out-of-the-box C/C++ to out-of-the-box Java is a non-starter in my opinion because I've never used out-of-the-box C/C++ for large scale performance applications. What Google did in writing custom systems software is something that cannot happen with Java and is the accepted practice for C/C++.
Java programmers write applications in a "one-size-fits-all" performance environment. Comparing Java to C/C++ is like comparing apples to oranges.
Serious C/C++ systems programmers write their own malloc and systems software.
Article Summary and reality (Score:4, Insightful)
Reality: "JVMs are mostly very stupid, and you can never be sure what JVM your users are going to use, so in the real world of deployed applications garbage collection performance--and Java performance generally--is a nightmare."
I am so tired of GC advocates talking smugly about theoretical scenarios. Who cares?. When I can run a Java app on an arbitrary JVM and not have it come to a grinding halt every once in a while as the garbage collector runs--or worse yet bring the machine to a grinding halt because the garbage collector never runs--only then will GC will be useful.
The weasel-words in the article are worthy of a PHB: "the garbage collection approach tends to deal with memory management in large batches" Translation: "I wish GC dealt with memory management in large chunks, but it doesn't, so I can't in all honesty say it does, but I can imagine a theoretical scenario where it does, so I'll talk about that theoretical scenario that I wish was real instead of what is actually real."
This is not to say that there aren't one or two decent JVMs out there that have decent GC performance. But having managed a large team that deployed a very powerful Java data analysis and visualization application, and having done work in the code myself, and having had to deal with user's real-world performance issues and having seen the incredible hoops my team had to go through to get decent performance, I can honestly say that up until last year, at least, Java was Not There with regard to GC and performance.
The most telling proof: my team did such a good job and our app was so fast that many users didn't believe it was written in Java. It was users making that judgement, not developers. Users whose only exposure to Java was as users, and whose empirical observation of the language was that it resulted in extremely slow apps. They didn't observe that it was theoretically possible to write slow apps. They observed that it was really, really easy to write slow apps, in the same way it's really easy to write apps that fall over in C++, despite the fact that theoretically you can write C++ apps that never leak or crash due to developers screwing up memory.
Every language has its strengths. Java is a good, robust language that is safe to put into the hands of junior developers to do things that would take a senior developer to do in C++. But its poor performance isn't a myth, nor is its tendency to hog system resources due to poor GC. Those are emprical facts, and this article introduces no actual data to demonstrate otherwise.
Re:Counter arguments (Score:5, Insightful)
In the end though, the MOST important thing is that these days, processor cycles are cheap. Programmer cycles are expensive. Therefore it makes sense to sacrifice a little bit of program performance to get more productive programmers.
Parent
Re:Counter arguments (Score:5, Insightful)
Faster productivity, less bugs, no ram guzzling 5 minute startup. Java isn't the only language that reduces development time, it's just the only one (besides VB) that makes you sacrifice big things to get it.
Parent
Re:Counter arguments (Score:5, Interesting)
Indeed. It might be worth (pardon my pun) reiterating what those cycles really are, in regard to application performance.
In all languages I know of, you get some library functions ready-made, and you need to code some stuff yourself.
Most performance problems occur in the code you made yourself.
In my experience, you get most bang for buck when you are able to efficiently allocate your programmer time to a) program a functionally complete draft version, b) optimize those parts which need optimization and c) maintain the program, in a manner which is BALANCED, but biased towards maintenance.
De facto, you get better balance between those things, and most bang for buck, using languages such as Java, as opposed to languages such as C++, because (say) Java offers a pretty coherent conceptual framework (class libraries) for creating your draft in a maintainable way, provides default access to excellent non-invasive performance measurement tools such as YourKit and JProfiler which let you objectively find out where you need to do performance work.
This means you can do only the optimization work that is necessary, and create optimized packages which extend the default class library interfaces which means that generally maintenance programmers don't have to put nearly as much work into figuring out how the optimizations affect the draft work.
It's not perfect, but it gets you more bang for buck, which is what matters to you when you manage resources.
Not the default developer perspective, I know.
Parent
Re:Counter arguments (Score:5, Insightful)
I don't care that Java will get there at some point, or that it's better now. I care about whether it actually works right, and right now it does not. It does have too long a startup, most of the UI toolkits are horribly slow, it does not follow native platform UI conventions, and it is just not as nice to use a Java app as it is an equally well written native app. It does take far too memory, especially compared to other languages. Even the cross-platform nature of the code is largely a lie. Different JREs don't support the same things, and many platforms lack a JRE. There are massive differences between the various editions of Java so as to make it useless to try to write something across them. Your Java app written against "Vendor X Version Y Edition Z JRE" should work fine on any other platform with the same version of "Vendor X Version Y Edition Z JRE". That's all you can safely say without a good amount more testing.
However, most of all, my CPU time and RAM might be cheap, but they are abused every time I use an application written in that mindset. I have memory needlessly abused, and CPU time needlessly wasted every time I run some poorly coded program. That means that I lose time and productivity every time I run your poorly written app. That attitude pisses me off, why we should all squander our system resources so that a few lazy programmers can write some app a little faster and with less effort, rather than doing their job right.
Programmer cycles are a lot cheaper than making thousands of people upgrade their hardware. I imagine those programmer cycles are a few orders of magnitude cheaper.
Parent
Re:Counter arguments (Score:5, Informative)
A typical mobile phone is sub-ghz too, and there is plenty of J2ME software running on them...
Java rocks on limited devices AND as server software. It is only on the desktop it isn't a big hit. Yet.
Parent
good programmers (Score:5, Insightful)
If you have been involved in developmnent for any reasonable amount of time or worked on projects of reasonable size, you know that *good* programmers are hard to come by. When you add the real world to the picture you find that simple things like garbage collection and a virtual machine can make a mediocre java programmer outperform a mediocre C++ programmer.
If schools actually learned to produce good programmers, and HR departments learned how to identify them, and job interviews verified them, we wouldn't be having this discussion.
Parent
Re:good programmers (Score:4, Insightful)
When an interviewee comes to an interview, his state of mind is on passing HR related questions. He's prepared for questions like "Why did you leave your last job" or "What's your greatest flaw", not writing code on the spot.
Most programmers I know have to be "in the zone" to write good code, and can't just jump from one mode to another instantaneously. That's why programmers need to be given nice quiet areas and left alone for long periods of time to get stuff done. Constant interruptions and distractions prevent them from being "in the zone".
While critical thinking may be a good trait, it's not a very common one, especially to programmers. Maybe THAT is why so few of them can do what you ask, not that they're incapable, but rather that they just weren't expecting it and can't switch gears that fast.
Parent
Re:If I had a dime for everytime I heard that.... (Score:4, Informative)
There are lots of games done in Java, mainly for mobile phones through J2ME. A few of them might have cutting edge gameplay (though I've yet to see one), but it is unlikely to see cutting edge graphics. Still, there are some pretty impressive things you can do with JOGL [java.net].
Parent
Re:If I had a dime for everytime I heard that.... (Score:4, Informative)
Parent
Re:Doesn't poke holes at all (Score:3, Informative)
The author is giving you a high-level, greatly edited view of some of the major optimization techniques in use today. The original academic/technical papers on which that is based demonstrate/measure their techniques on various benchmarks.
One thing the a
Re:Cool code no longer means fast (Score:5, Insightful)
public double getDistanceFrom(Component other) {
Point otherLocation = other.getLocation();
int deltaX = otherLocation.x - location.x;
int deltaY = otherLocation.getY() - location.getY();
return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
}
Look at the implementation of getLocation(). It's a simple non-recursive procedure. In virtually all compilers, a simple procedure like this is going to be inlined, producing:
public double getDistanceFrom(Component other) {
Point otherLocation = new Point(other.location) ;
int deltaX = otherLocation.getX() - location.getX();
int deltaY = otherLocation.getY() - location.getY();
return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
}
(Note that to the compiler, all variables are effectively public, so this would not be an access violation.)
Next, the compiler can (easily) prove (by inspection) that Point(Point) is a copying constructor. As a result, it can replace the use of new Point(other.location) with other.location so long as it proves it will not modify otherLocation, and of course, it can prove this quite easily by inspection of getDistanceFrom(). This results in:
public double getDistanceFrom(Component other) {
Point otherLocation = other.location ;
int deltaX = otherLocation.getX() - location.getX();
int deltaY = otherLocation.getY() - location.getY();
return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
}
Also, note that getX() and getY() are also simple non-recursive leaf procedures, so the compiler would have inlined them at the same time, so you would actually get code equivalent to this:
public double getDistanceFrom(Component other) {
Point otherLocation = other.location ;
int deltaX = otherLocation.x - location.y;
int deltaY = otherLocation.y - location.y;
return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
}
Which is now faster that your hand-written "optimization." Note in fact, that you "over-optimized" by replacing otherLocation with other.location twice. If a compiler were actually dumb enough to implement it that way, literally, it would have involved an extra (and needless) pointer dereference to get the value of other.location twice, when it already had it sitting in a register. (Fortunally, most any compiler nowadays would have caught your "optimization" and fixed it.)
In fact, the compiler wouldn't stop here. It might even rearrange the order in which it fetches x and y to avoid cache pollution and misses. Do you consider that each time you fetch a variable? Most programmers don't, and shouldn't. The moral of the story is that most programmers fail to realize how smart compilers have become. Compiler writers design optimizations with "good coding practices" such as this in mind, and the programmer will be rewarded if he or she uses them.
Parent
Re:What a bunch of FUD (Score:5, Informative)
First, you definately have an L1 cache miss. On a P4, that is a 28 cycle penalty. You also likely have an L2 cache miss. Fast DDR2 memory has an access latency of about 76 ns--call it 220 processor clock cycles. If you miss the D-TLB, then add another 57 cycles. Total cost of your "fast" allocator--305 cycles of memory access latency. 305 is somewhat higher than 100.
Even worse, if you are on a system with a lesser amount of memory, you may miss main memory entirely, causing a page fault. That'll cost you several milliseconds waiting for the disk. That really really hurts, since 8 milliseconds latency from disk is twenty-four million cycles at 3 GHz. 24 million, 24,000,000, 2.4 * 10^6, no matter how you write it, that's a lot of cycles to allocate memory.
All of a sudden, 100 instructions to hit hot memory seems cheap.
Parent