Slashdot Mirror
Java Urban Performance Legends
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."
Well, Duh the stack wins everytime, its even coded into the instruction set, push and pop, and stack relative operators. If you agonize over it.
And yes I haven't read the article because its slashdotted, too much use of heap in the web server.
Why Java Will Always Be Slower than C++
Yeah, I do not think that IBM's websites could get Slashdotted. Article looked fine to me too, and loaded in a second or two.
Click here or here.
These java urban performance legends are rubbish - java is highly performant in a rural or urban setting.
but the main thing that frustrates me is the difficulty in storing primitives in sets or as keys for maps. I realise that there are libraries available such as pcj, but it's still annoying :)
Unpretentious Sydney reviews by unqualified Sydney reviewers
How much time have I spent with Electric Fence and valgrind finding memory leaks in my C programs? In Java, the auto garbage collection is as good as Perl's, without that tricky "unreadable code" problem ;). And I can always tune garbage collection performance by forcing a garbage collect when I know my app's got the time, like outside of a loop or before creating more objects in storage.
--
make install -not war
JVM memory allocation isn't "SLOW". It's just pleasantly unhurried.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
Here or use the Firefox extension.
JVMs are surprisingly good at figuring out things that we used to assume only the developer could know.
:) ) they weren't. The performance of the language has greatly improved while the perception of language has remained the roughly same (at least amoung the general coding community).
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.
http://twitter.com/onion2k
These articles keep popping up flatly stating that Java's slowness is a myth. But, no matter how many times you say it is a myth and how hard you try to create a new perception, 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++.
Java is slower. Don't even get me started on C#.
either support Novell with Mono or support Sun with Java, us geeks only like being fanboys for one side of the competition not both so when don't want to read about both...
------
Ever wondered why my posts are so different because I am trying to get +5 flaimbait or -1 Imformitive.
The memory allocation management routines are normally running when the JVM thinks it's best, but as a programmer it is usually possible to predict the best time when to actually take care of the housekeeping. Even if the memory management cleanup takes the same time in both cases Java has a tendency to issue them in the middle of everything. So if I as a programmer does the garbage collection at the end of a displayed page and Java does it uncontrollable in the middle of the page the latter case is more annoying to the user.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
How many JVMs can you afford to run on your system for different apps, and how can you make sure they are all the right size, the garbage collectors are in an appropriate mode that can keep up with generated garbage, etc. I can run lots of native apps, which in many cases have no need for a significant heap like Java brings into the picture in far less space than a single JVM. A JVM runs much heavier on the system, and when I run Netbeans, it is continuously on the verge of eating my 1.2 GB powerbook alive, in fact I have to frequently restart Netbeans to get memory back. It has a long way to go in real practical terms even if they have theoretical solutions to some of the problems. I am porting my server software away from Java for the same reasons. This is JDK 1.4, and I am about to try it on 1.5, but I don't think there is that much difference.
Lets compare new Object() which does nothing with a malloc which can allocate for whole collections in a single call. Lets forget every Java app anyone has ever used seems slow. Lets forget that C++ and C allow you to ignore malloc if you have a performance problem with allocation. Lets even make magic promises for forth-coming vaporware.
Face it Java fan boys. Its slow and bloated and no amount of articles can offset the reality in front of everyones eyes.
The article explains what in theory can be done by smart VMs. But all the examples in the article aren't tested in practise. Maybe the escape analysis the author describes works as advertised. But without actually testing and analysing real code produced and without actual benchmarks the article doesn't proof a thing. One thing the author seems to forget is that you would at least need a fallback mechanism when a method is overridden in a subclass (all the examples don't use final classes or methods). A subclass could override one of the get() methods and put some values in a cache (to keep some statistics for example). In such a case the VM has to detect such a case and "de-optimise" the inlinded code again. Maybe this can be done without too much overhead. But only really measuring these things in real world applications will tell.
I would love to have pointers to real data though.
Network-bound java servlet applications may perform better in built up areas, due to the higher bandwidth of urban ADSL connections.
This article is actually debunking some people's reasons why Java has poor performance. It does little to debunk my actual real world experience that it *is* slow. I'm glad to see that performance has increased alot, but I remember some all (well 90% or something) Java applications, like the original JBuilder, that made me want to claw my eyeballs out when using them. Those apps and other early apps are where Java's performance issues really took hold in many people's psyche.
the people who keep telling me allocation in Java is slow (much slower than 10 instructions) are generally experienced Java programmers. I use Ocaml, so I'm quite aware of how fast a generational garbage collector can be (btw, on the x86 in Ocaml, allocations are only 5 simple instructions). But from all first hand reports I've heard, Java allocation is still slow. It may be faster than C++, but it's still slow.
The best way to think of it is: Java = C (the cleanest of C!) & Java extension for portability and interoperability etc. SADLY most novices just dont get this. AND Java garbage collection is now next generation and way ahead of anything else out there. It's alomost flawless.
I've had many professors say that Java is nowhere near as slow as it used to be, and that it was just a myth now that it is that much slower the C or another language that doesn't rely on VMs. In most applications, I guess it's actually equal enough to C to be considered as an alternative. Although it doesn't have anywhere near the rich number of libraries C/C++ works with (I'd like to see someone make a cutting edge game in Java).
In undeveloped countries, the consumer controls the market. In capitalist America, the market controls you.
While he's at it, could he also address the myths that Lisp and Smalltalk are slow too? Because they're not, they're pretty fast (though not as fast as C) and they offer vastly improved programming environments which leads to vastly better development time, which C can never hope to achieve.
First post here from my Java workstation. Take that!
what if java's allocation may be non-slow? What counts is that java applets and AWT/Swing applications were slow in the late 90's, and by damn-it, thats what we slashdotters like to base our opinions of java on!
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.
The copying collector sounds really fast indeed, but I can immediately see two problems:
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?
http://www.agency9.com/
No matter what the theory says, your average Java application could be written to be more resource efficient, overall, in C/C++. That's the experience. (So Java's either inherently slower, or your average Java programmer is just really really bad at writing efficient algorithms.) Maybe Java will some day meet the assembly-level languages. I do doubt it, but I'll permit the possibility.
What I'm more interested in is porting this supposed efficiency to C/C++, if it's so useful. First, can we demonstrate that the model doesn't beget yet more allocation (which could shoot it in the foot)? It doesn't seem to at first glance. So, what's stopping a C++ coder from calling a monstrous malloc(), then using their own memory management routines on their userspace heap? Nothing at all. That's basically what Java has to do anyway (well, it probably uses brk()...)
Here is a paper (PostScript) from 1987 on the topic of GC being faster than manual allocation.
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.
http://www.thebricktestament.com/the_law/when_to_
This is the funniest post I have ever seen on Slashdot!
Think about the article and the n look at the post! Mod parent way up!
It's not the speed that is an issue, so much as the inability of java to function well outside of number crunching. Its graphical toolkits are crap, slow, non cross platform and ugly. As well as this it can't be used efficiently for 3d, sure there's java 3d, a terrible kludgy hack on top of opengl. If i could use java efficiently for programming graphical applications then i might consider it.
java's microbenchmarks prove where it doesn't have problems.
the java platform's mantra is "create and use objects". when you compare java to languages that allow objects, but are not heavily object oriented in terms of their supporting framework and libraries, then what you are seeing is the expense of the OO paradigm.
I thought this was about the seattle music scene...
Seriously shouldn't it be "Java Performance Urban Legends"
WTF??? You claim that since Java is fast enough for you, running a webapp, on older hardware, running locally, for a single user, it must be fast enough for everyone? Suppose, just for the sake of argument, that there are more than one users! Suppose you are CNN.com and that webapp has to serve 2 or 3,000 users per second. Is Java fast enough then? Is it faster than C++? Is it faster than C? Are you retarded??
get educated
A *good* C++ programmer will probably write code that outperforms the equivalent in Java. A *good* C+ programmer will remember to deallocate all of his objects to prevent memory leaks. A *good* C++ programmer will copy his strings correctly to prevent buffer overflow exploits.
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.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
Alternative, the author is an idiot savant that never overwrite memory in C, but still isn't smart enough to realize why it happens to other programmers (and realize that it slows development down, not makes it impossible, which his argument about writing OS kernels in C seems to assume).
Karma: Excellent (My Karma? I wish...:-( )
Java and C# programs tend to slow down for another reason, the programmers. I have seen a lot of programmers who throw and catch exceptions like candies, lock out entire functions as critical sections and what not. Although C# and Java does make programming easier by hiding details, they make it also make easier to do things that may slow down program execution.
In most cases it's other factors contributing to performance problems, mostly i/o. If it's memory, you buy extra memory. If it's cpu, you buy faster cpu's. If you can. If you can't then you have a problem if you go to multi-core cpu's. Multi-core cpu's are the Achille's heel of garbage collection since it requires a "stop the world" synchronization to safely avoid race conditions in determinine what memory is referenced or not. "Stop the world" is hugely expensive on multi-cores. There are specialized multi-core cpu's for java out there but they tend to run the jvm's on single cores with relatively few hardware threads to avoid this problem.
Really? Can provide a few REAL world examples? Can you name one? Personally, I'm running Azureus and Netbeans right now, and they're not perceptably different from C++ desktop applications like KDevelop or OpenOffice.
The article's main point is that Java's memory allocation is faster than malloc, and it's garbage collection is better than cumulative free's.
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
Rather than promoting your prejudice, why not RTFA, or this 19-year-old paper.
I'll await your learned rebuttal.
it would be interesting to see what is the overhead of the "Object" for different JDKs on 32/64 bits implementation? If class {int x,y;} takes 128 bytes, why would I care about speed of the memory allocation? They also mention thread specific allocators which are nice, but only if your program is nowhere close to max memory.
Simply put there may be fast efficient tiny java programs out there but I don't see them. I don't really care about how garbage is collected. All I care is that a simple editor gobbles up memory like it was some kind of FPS. Sure I love the fact that I can use the same editor with the same extensions (to a point) on my home linux machines and work evil OS machines BUT it comes at a price and that is a lot of memory.
Perhaps Sun has indeed improved java massivly over those horribly slow and crashing java applets we had a few years ago that were so going to take over the net by storm. Perhaps all the problems are just due to certain public java programs being badly written.
It doesn't matter, java is slow, c is fast. Instead of having written this article perhaps the author should have examined some common java memory hog programs and analyzed wether the fault lies with java OR the coding in question OR and this is an option few consider, that JAVA apps and C apps are often compared like apple and oranges. Azureus vs Bittorrent (a tiny and far simpler app) Eclipse vs VI etc etc.
A lot of languages deal with mis-reprensatation. I don't exactly feel sorry for the bad rep that java has as many java fanboys happily spread un-truths themselves. Like java vs PHP vs ASP for web development. Judging from my own experiences all this is just one giant "Your mom is so fat ...." competition.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Are you kidding? You're saying that Azureus, a BitTorrent client, is "not perceptably different from" a multi-language graphical IDE or a full blown office productivity suite??? From your statement it sounds like Java, or at least Azureus, is pathetically slow compare to C++ desktop applications.
Why don't you try comparing two BitTorrent clients instead? Try comparing Azureus with KTorrent, a C++ BitTorrent client. You will find that KTorrent is orders of magnitude faster and also uses a tiny fraction of the memory that Azureus uses.
Apples to apples, Java is SLOOOOWWWWW...
I think automatic garbage collection is great, but _my_ problems with Java's memory allocator have little to do with performance. Rather, it sucks so hard at dealing with out-of-memory conditions.
Why would you ever run out of memory? If you're on a microcomputer, you tend to have an arbitrary limit anyway. The JDK default is 64MB max heap. This is to prevent runaways, but setting the heap size to some arbitrarily high number has really awful performance characteristics -- god help you if you set the number higher than the amount of RAM you have available, or applications that want to share the machine. There's a whole other rant about how stupid automatic garbage collection is on a timeshared environment (like a server), but it's not the point I want to make.
The point I want to make: since Java is supposed to run everywhere, you really can find environments where you only have 1 or 2MB of heap to play with. Having constrained resources is nothing new to programmers, they've been dealing with it forever. But Java's allocator combined with constrained resources leaves you with very little wiggle room.
If you've ever developed a Java applicatoin that manages an in-core cache you might have experienced how fucked you are when you get around to the logic of cache expiration. Ideally you can keep cache forever, as long as a) you know it's not stale, and b) you don't need the memory for something better. A is not a problem in Java, but setting up a system to facilitate B is actually really hard. In C/C++ you can wrap malloc() so that if it fails, you can start dumping cache until it succeeds. The solution is elegant, dare I say beautiful.
In Java this is totally impossible. When you run out of memory the garbage collector is tripped, and if it can't free anything up it generates an OOM exception. You can't realistically catch these exceptions -- they can bubble up from anywhere at any time. The only place you can catch them is at the top of your program loop and the only good it does there is let you say "OUT OF MEMORY" in a user friendly way before exiting the application -- assuming you have the resources left to even say that of course.
So how does this effect your cache model? Well, you end up having to guess at how much cache to maintain. Guess too high and your application breaks when it's run in a low memory environment. Guess too low and you're not caching enough, the user experience suffers when it has no reason to. The above scenario is just one example.
Essentially, the problem is one of prioritized memory. Java gives you no usable way of saying memory allocated for purpose X is fine as long as purpose Y is not short. Designers and apologists can make excuses for why Java doesn't support this and maybe provide a good reason, but those reasons hardly qualify Java as a general purpose programming language.
Goto also.
Sun is introducing shared memory in the new VM that should alleviate this somewhat.
The idea is that the majority of the "fatness" comes from the libaries. If you only have to load the core libraries once, and each VM can use them then additional VMs won't add so much overhead.
If this works, I'm wondering, will we get side-effects from the over-abuse of static member variables.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
Anonymous kettle Coward, learn to capitalize and punctuate before spewing garbage about "getting educated" and illiteracy.
--
make install -not war
I haven't done anything with java in the last 5 years.
...BY HAND!! IT WILL NOT COMPILE ELSEWAY.
*everybody.screem("w00t!");*
I can understand the discussion about memory allocation is legitimate.
*everybody.agree();*
Now, saying this would not be the case anymore, so hence java is fast now, would be false.
*everybody.status = iritated;*
Writing jevecode does make yu handle a lot of errors...
*everybody.ask("is this not good?");*
*some.ask("is this not good?");*
Maybe there is a loss of speed for handling all those errors as well.
*FirstHalfOfCoders.grab(stone);*
C coders don't check for every possible error.
*SecondHalfOfCoders.grab(stone);*
Maybe, sometimes, it is ok for a programmer, if from that code, there could
be errors. While on the other side you buy speed with insecurity.
*FirstHalfOfCoders.throw(stone);*
*SecondHalfOfCoders.throw(stone);*
*me.troll();*
AND BY THE WAY; I LOVE THE "GOTO" STATEMENT!
*me.run(away);*
Bjarne Stroustrup : why so many people use "C++" just as "C" ?
Dennis Ritchie : because you named the language "C++", not "++C"
I have been doing Java programming for several years now and ported many C/C++ applications to Java, mostly server side apps and I'd say roughly 85% of the time the Java apps outperformed the originals, sometimes by an order of magnitude. Now these were more redesigns than straight ports and the performance gains were not because Java was any better from a performance standpoint, but because design is more of a factor in speed than the language used, especially for larger applications. Usually when I find big performance hurdles that are hard for me to overcome, I find I would have same issues in most languages, so finding a better design is usually the solution. If you are writing small - medium apps or mostly GUI apps then I might have reservations about Java, but for larger apps Java is a good choice.
Garbage collection is generally more efficient, byte for byte allocated, than malloc.
The problem is that Java programmers and Java libraries tend to be written in such a way that they do a lot more memory allocation, just because it's so easy to do. The quality of Java code in general is not very impressive (and this include Sun's own libraries). And Java itself makes writing efficient code harder than it needs to be.
So, people can write highly efficient code in garbage collected languages, and even in Java. But Java programmers generally don't bother, and that's the reason why Java has such a bad reputation, and it deserves it.
see http://shootout.alioth.debian.org/benchmark.php?te st=all&lang=all&sort=fullcpu
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
it's significantly better.
if you RTFA you'd get some ideas as to why. perl's garbage collector is very, very stupid by comparison.
I've never believed that Java's garbage collection is the root cause for its slowness. I do believe that Java's GC is the cause for its random (and more notably, its inconveniently timed) stutters.
I think the more general Java slowness comes from the obfuscation of efficiency. In C for instance, ugly code correlated with inefficient code. This is no longer the case for object-oriented programming in general, and it is possibly worst correlated in Java.
The example in the article provides a starting point for what I'm saying. It's based on the algorithm for a point in some Cartesian graphics system:
The Component.getDistanceFrom() algorithm is considered "good OO style." By using bad style, though, you can break the pretty encapsulation -- and make "bad OO style" -- but get a performance gain:
Both code blocks require the math (two subtracts, two multiplies, an add, and a square root) but the original block (unoptimized) also requires the allocation of the Point object and the two memory copies to store the (x,y) location.
This is a trivial example, but my point is that in a complex Java project, readable and elegant code bears no correlation to fast and efficient code. I believe this is why Java is slow.
--- Jason Olshefsky
Karma: Poser (mostly affected by adding this line long after everyone else did)
Look at any of the BSDs. There's 3 complete unix operating systems, kernel and userland, all in C. And yet, somehow, memory leaks are simply not an issue. Sure, they happen once in a while, but not often enough to be a problem. Yeah, memory leaks abound in poorly written, buggy piles of crap like mozilla, but that's my point. If you have problems with memory leaks, then you are the problem, not C.
Firefox even has its own garbage collection in the Javascript interpretation, but it's memory performance is orders of magnitude better than Java-based applications including NetBeans.
Unfortunately, programs such as Azureus, which run piggishly slow on a 1.2GHz laptop do nothing to dispell these 'performance myths'.
C doesn't program itself. These "language in a vacuum" arguments are specious, nonconstructive navelgazing.
--
make install -not war
The common code path for new Object() in HotSpot 1.4.2 and later is approximately 10 machine instructions (data provided by Sun; see Resources), whereas the best performing malloc implementations in C require on average between 60 and 100 instructions per call (Detlefs, et. al.; see Resources).
Wow, that's really shocking. Until you actually look at the Detlef paper and realize that it was published in 1994, 11 years ago!! Who knows, maybe things have improved a bit in 11 years. The author certainly thinks Java is getting better; maybe it's possible that C/C++ compilers have improved as well.
Here's a link in case you ever get the urge to write some Java code.
So, the JVM allocation works, and there's no performance bottleneck there. But where is it? Why is Java still so painfully slow?
Java used anywhere, from webservers to full client apps just feels and even *looks* slow! Stop coming up with pointless articles. Find the problem and fix it.
Just because your voice reaches halfway around the world doesn't mean you are wiser than when it reached only to the end
One approach to speeding up Java applications involves drawing a prudent line between what will be done in Java vs. native code. Java purists may claim that anything less than 100% pure Java is evil, and there are trade-offs, particularly in the area of security. If you're pragmatic, and use the right tool for the right job, don't be afraid to use native libraries where appropriate. You don't have to go all or nothing.
For example, to speed up Java apps running on the client (not in a browser, full applications), use Eclipse's SWT. SWT is a UI toolkit that (mostly) uses the underlying Windowing system's widgets, rather than trying to draw everything in Java. As you might expect, this leads to some nice behavior from a performance standpoint. For example, try resizing windows in Eclipse on Windows XP. You'll notice very smooth redraws of the underlying components while the window resizes, just like a C++ app. Now try the same thing in Netbeans.
Similar solutions exist for accessing OpenGL natively, rather than using a more "Java heavy" library like "Java 3d."
I'm willing to believe that Java allocation/deallocation, in bulk, is better than C++ when amortized over the course of an entire application. The problem is the lack of control; while this is no longer an issue in most parts of the development world, for real-time applications -- and gaming in particular -- performance has to be good from start to finish; taking a time hit to free up memory is fine when you do it yourself at the end of a level, but not so cheerful when it happens automatically in the middle of your boss fight. This isn't a fatal flaw (my current side programming project is a Java-based game), but it's an inherent aspect of the language that severely hampers its applicability to some programming jobs.
I have never felt the last bit of anxiety when choosing to "allocate" an object on the stack. I do not even call this an allocation, I just use a local variable that happens to be an object.
I only allocate an object on the heap when I know this object needs to be exported from the function -- which is something I'd better be aware of by design.
Stack-allocation is an easy, default, way of life in C++. It is even a key idiom for managing non-memory resources (RAII).
When programming in C or Java, what makes me agonize is to manually ensure that (non-memory) resources are released properly and in a timely fashin (files, locks, communication ports, etc). try...finally blocks, anyone ?
Somebody has a case of Dyslexia it appears, it should read like this.
Java Performance A Urband Legend
Got Code?
Garbage collection is nice. It does its job and it does that job well.
But garbage collection only helps you manage one sort of resource. In C++, the RAII techniques that help you manage memory are good for every resource, from file handlers to database connections. Resource management in Java is not so nice. Often it is quite a hassle.
Also, if you really want the benefit of garbage collection in C++, simply compile your program using something like the Boehm Garbage Collector.
Single inheritance is the one that is simple to implement. As an application programmer I want the one that is simple to use and that means not having to program around language limitations.
all the energy released by a an article that is conceptually flawed... it is supposed to be an engineering discipline. engineering disciplines are about using the mathematical models to make appropriate decisions trading off different abilities to get the best "fit" for the desired result. verticle and horizontal understanding of technologies, their uses, strengths, weaknesses, & costs can be a complicated. as shown by the replys to this article. too bad such energy isn't funnelled into create better usable models about how to make technology choices for the job at hand...
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.
//My response to the Java bashers //thank you and have a nice day
benderResponse.bite(ass, shiny, metal);
Everything I need to know I learned by killing smart people and eating their brains.
VB.Net complies to the same code has C# if you turn on remove overflow checking and options strick. So how can you lump VB into a differenct category than C#?
I thought Java was our savior, to lead us against the scourge that is Microsoft. Ha! Let's replace one bloated and buggy piece of software with one equally bloated and albeit less buggy piece of software. Slow, slow, slow. It started off as any day now you'll see Java take off to It's not your father's Java anymore. It still sucks. It's way too complicated. I'd use it before C# or VB or .NET anyday. I was far more productive with PHP and MySQL in a few days than I was with Java. Of course, I already knew Perl. Python looks even more promising. C++ has a steep learning curve too, but it's a real language and worth the effort. Java, is it a desert topping or a floor wax? It's both!
Fuck Java. I've said it before and I'll say it again. Java is only good for keeping programmers employed at companies who bought into the Java hype. And who are loathe to admit they already spent too much money. It could be worse though. They could be using Oracle, a great system, that is too complicated to make effective use of.
I've come to terms now with Java's place in the annals of programming.
It's a political language. It's a language you learn to get a job.
It does not appear to be a language you should write any commercial applications in.
I'm going to get hated for this but that's how I feel. I've never seen a Java app that wasn't really bloated and slow.
Puzzle Pirates is a prime example. If that application had been written in something like C/C++, it would run a hundred times faster. It's dog slow and laggy no matter what system you have. I just built a new PC with the fastest processor, best graphics card, hooked up on a full T1 to the net with no other traffic on the pipe and still YPP runs like a dog.
I have yet to see any impressive commercial Java application. I'm sure there are some out there, but on the average, this language seems to me, to be a system you embrace because you're required to, for one reason or another; not because it's the best choice for any given application beyond some embedded web page eye candy.
Since when has allocating all my RAM in exchange for speed ever been a way to break a "myth"?
Ask anyone who's used a Java app. If you leave it open for a while, it'll take quite a long time to get it to continue because it uses so much RAM that it has to be flushed out to disk for me to use anything else. A "paper" cannot dispell personal experience.
Java has been hit hard about its slowness for a very long time. We all know about the tradeoff between memory and speed. And now Java goes to one extreme and tries to pass it off as if it's just as fast (and in some [nut]cases) even faster than C or C++. Sorry, but I'm not that stupid. I'd rather believe in conspiracy theories than believe the nonsense that Java is faster than C/C++.
Garbage collection is probably the single best cause of producing below par programmers. Some programmers think that because Java has a garbage collector that you don't need to deallocate your objects. This is really scary on many levels. Also, some people even go so far as to say because you don't have to worry about it (which is again false BTW), your software will run faster. I'm simply incredulous. It's like saying I don't have to worry about the amount of fuel in a car race.
Going with the analogy, Java runs fine on its first tank, but as soon as it gets low, it needs a fuel tanker. With C/C++, sometimes it may seem like it's taking slightly longer fueling up than it should, but that's because it's environmentally friendly and only consumes what it needs. Java uses a one-stop pit strategy where they steal fuel from the other teams and throws shrapnel in front of other cars. C++ is a well oiled machine that uses proper pit strategy and will still be around long after the other cars have been disqualified (killed and uninstalled).
I'll take C/C++ (Formula 1) or any other compiled language anyday over the ramhog that is Java (SUV).
In my experience, Java's slowness issues stem not from the bytecode JVM, but rather J2SE's class libraries, and generally the object-oriented approach to solving problems.
Now, before you attack that, I'm heavy into design patterns and all the rest. No problem there, but consider this: how many times does an original piece of data get touched, copied or transformed in a Java app?
Case in point, parsing HTML or XML documents. Under the J2SE scheme of things, even a tiny XML document can result in hundreds if not thousands of objects being created, even if you're after just one piece of info in that document. That results from the *lazy* use of Java's built-in parsers, which are inefficient due to their abstract nature.
You have to carefully monitor where your data goes, and what gets done with it, in a Java application that makes heavy use of J2SE's classes. They're entirely general purpose, which is great when you need to slam out some code. But if you're at all interested in performance, you're screwed, because general purpose = glacial performance.
When I can, code state machine parsers for problems like this, and look for other ways to avoid the heavily abstracted code that can result in data duplication and slow performance. JVMs today are quick, and code written from fundamentals of minimal work can achieve maximal performance.
O lord, bless this thy holy hand grenade, that with it thou mayest blow thine enemies to tiny bits, in thy mercy.
The Shootout Benchmarks are short-running microbenchmarks. Just-in-time compiled environments (e.g. Java and .NET) have a startup time that is as high as 100-200 milliseconds. You can imagine what that looks like in an Ackermann benchmark whose total runtime is 120 milliseconds. A 100-millisecond startup time matters less in real applications.
I converted the Ackermann and binary trees benchmarks from that site to run in a loop (to get JIT compilation happening). Java became faster than gcc. YMMV.
There's nothing that turns me off more than the one-size-fits-all zealotry that often comes from the Java camp. One size does not fit all. It never has, and it never will.
Programming languages are tools. Pick the appropriate tool for the specific job. More specifically, understand the capabilities and deficiencies of a wide range of languages and map those appropriately to the specific problem domain you've been asked to tackle.
Examples:
*) Production quality, single-user, cross-platform application: Java is at the top of my list.
*) Production quality network service with deterministic behavior under load and soft-to-firm response-time requirements: Hard to beat C w/ Linux here.
*) Quick and dirty lab-only tool to thrash through some test results: Yep, it's Perl.
Engineering is all about trade-offs. Understanding your problem and the tools you have to solve it with are critical. Making a poor choice, especially early on, can be disastrous. Even though I don't discount the performance enhancements Java has enjoyed over the years, I'd be very hard-pressed to select a virtual-machine based language/system for any performance critical application requiring a deterministic response.
Pounding a square peg into a round hole by insisting on one language for everything doesn't demonstrate a lot of design-maturity or sophistication on the part of those making such claims.
I've worked this into my interview questions for new hires as well and have found it to be a pretty good indicator of who I'm dealing with, experience-wise. (hint: the guy who insisted on smalltalk for everything did not get the job)
Hold on a moment, there are a lot of errors here!!
) ;
It's Java, it should be:
System.all.group.second.half.of.coders.grab(stone
All anyone has to do to determine java is slow is run a practical application written in java. You can give examples and hypothesis and benchmarks all day long. It still won't change the fact that I can put a java app on joe blows desktop and will get a, "Damn this is slow." comment with all but the most trivial apps, each and every time.
Java, as Larry Wall stated, is one of those "stay-at-home" competitive language that works best in a pure environment. As opposed to say Perl which is a regular party animal and plays well with everything. Although, I have to say, I've never had the occasion to invoke Java from Perl.
Java programmers design code to object oriented methodology and do not design primarily for performance. Java is not a systems programming language. Java is a software engineering language designed to optimize human time and not computer time.
If one is going to start a project with performance as the top priority, one would not design it in Java because most assuredly one is not going to have the luxury of a homogeneous environment but will need to play well with others using a language like C/C++. Case in point are databases. Java's interface to MySQL is still slower than C/C++ or Perl.
The question is how best to balance human performance time with the software engineering design philosophies that optimize human time in languages like Java with that of computer performance time and systems that lie out side of the Java native spectrum and defeat the "stay-at-home" homogeneous design requirement of not playing with other languages like C/C++, COBOL, etc.
If a performance project requires heavy integration and interaction with multiple systems outside of Java one would not choose Java, but one could choose C/C++.
Also one more point I would like to make: The point of Java is write once run anywhere. Sure in theory I can use the same application on multiple operating systems. The problem is that many of them have specific version requirements for the JVM I am using. Even with 2 or 3 Java applications on my PC there is a trial and error process of trying to find a JVM that all 2 or 3 applications can run on.
So I can write _one_ application and run it anywhere, as long as noby elses Java application using a seperate JVM version is already there.
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
Java is fast enough for most tasks, and the GC is a wonderful convenience.
But let's not go overboard. I started writing a 2D vector game in Java a couple years back that included rudimentary physics. I tried the Windows, Linux, and Apple JVM's at the time, and as things got more complicated I ran into a lot of performance problems, namely, a notable split second lag every couple seconds where the GC would kick in and lock everything. After trying every trick I could find, I converted to C++ and got an immediate huge performance boost -- well over 10x -- without any further optimization.
I'm sure JVM's have come a long way, but I just fired it up under the latest Apple JVM (I'm sure folks will tell me that's the worst one...) and the performance was still notably less than the C++ version.
I'm not trying to put Java down, here, but let's not make pretend it's super fast. It's not. Neither is perl, my day-to-day language of choice. But that's okay because different languages have their place. C++ is fast. And frankly, when I did the Java to C++ conversion, the code didn't even look much different.
Enjoy whatever you use...
And I've never seen malloc/calloc/free anywhere among the top time-consuming functions...
Maybe, Java's allocation/deallocation is even faster, of course.
In Soviet Washington the swamp drains you.
Until a JVM implemented in pure Java works as well as a JVM implemented in C/C++ (like all of today's JVMs), Java's still slow.
They got the concept right. The implementation is crap.
it's not that GC is slow, it's that the comparison is invalid. malloc libraries are designed to minimize or at least keep low the amount of wasted space. GC trades off extra space for the performance of contiguous arena allocation. malloc could do that too, and its fast path would be identical. the slow path matters, too. further, a GC language necessarily trades off contiguous allocation vs some sort of indirection or pointer-editing. that is, GC has to be able to move memory objects, so the simplest (historic, inefficient, naive) implementation is to always just indirect through an object table. that extra memory reference is much more important than shaving off a few cycles of the allocation fast-path, since the cost is taken on every reference.
Gah. If you use C (or better, C++), and you like it, and you like garbage collection, why not just use a garbage collection in C? I haven't written anything particularly huge lately, but the Boehm-Demers-Weiser one seems pretty solid. It's the best of all worlds -- you let the garbage collector handle most of your memory recollection. Remember the 90-10 rule ("90% of execution time is spent in 10% of the code"), so if there's a chunk that really needs manual allocation you can do that too. And the performance? Wonderful! Bump-pointer allocation means new objects get there fast.
There's no such thing as a wart-free language, but in C++, lack of garbage collection isn't one anymore.
malloc is a function, and when you call functions the stack is used to pass parameters, so no matter how clever you write your heap allocator it is always at least 2 stack frame allocation more work than a stack frame allocation!
(1 to allocate a heap block, 1 to free a heap block).
And that ignores the heap searching algo overhead.
Your stack allocations are totally free, because they are allocated when your function is called.
I find it rather amusing that these "studies" claim the JVM to be more efficient that C/C++ when the language that the JVM is coded in is C/C++ (or a like language).
Bloody rediculous.
The only way that they are going to get favourable numbers is by cooking them... big surprise.
Garbage collection will never be as efficient as direct memory management.
Slightly OT, but why do people put C and C++ in the same performance class ? The performance difference between the two is quite significant, especially if you use gcc/g++. I once try to port a big project from C into C++, without actually converting the code into classes (not a big deal, since the incompatibilities were really small). At some point I had the code compile under both gcc and g++. Interestingly enough, with g++ the code was about 30% slower.
The Raven
There is a whole 'nother source of Java slowness -- the JVM startup and loading the classes used by your app. It is not just that some Java apps are slow, they take forever to get going.
Similarly, why should we risk forgetting to deallocate stuff from the heap, when we can have the computer do it itself?
Because you don't want to risk falling behind on the incoming and outgoing signals. A lot of the applications of embedded devices and handheld devices are signal-processing applications, and they must run in some semblance of real time. Even video games are soft-real-time signal processing applications that turn signals from the controller into video and audio signals. When you need to maintain a (hard or soft) latency guarantee between the input and output signals, you have to design for the worst case, not the average case. Taking a break to GC the heap is often not an option. Or has incremental collection on the heap become as fast as malloc/free?
I don't know about netbeans, but I use eclipse (3.0 and 3.1) more than 8 hours a day and it is not slow. I have 1GB of RAM, but next to eclipse I'm running a weblogic (development) instance and lots of other normal office programs, and eclipse works very fast. It is really amazingly fast for such a complex GUI program. It has a very complex with lots of tabs, menus, browsing trees everywhere on the screen, all kept up to date in real time.
Please, give it a serious try since your experience, the non-trivial last of which must be at least several years old. Slowness of Java is really a myth. It is very very irritating to see that myth kept alive by people repeating each other (and of course MSFT) for the last years without being open to review.
Yes, any Java GUI app written in swing crawls unless it has a lot of memory and a good CPU behind it. But that is because swing sucks, not Java itself.
Or, to put it differently, "having sucky java apps is optional". Computation and networking can be pretty nippy. Because threading is easier, you can also make use of multi-core systems quite easily.
What you cannot do in Java is go low-level when you need to issue cache prefetch opcodes, or directly address the SS2 parallel register set (Java1.4+ hands off all floating point operations to the SS2 registers/opcodes, but doesnt SIMD parallel ops).
At the same time, how often is top-tier performance really needed. For many programs, time to market with stable apps matters more. This is potentially Java's big weakness: successor languages (e.g. Ruby) that offer even better productivity, without making performance tangibly worse.
You can write high performance, CPU intensive code in Java. If you don't believe me just download jrMan and try it. If you want to compare with a C++ implementation you can download Aqsis which implements the same algorithm to render images.
Are you adequate?
I have been using Java for a long time, for server software, server-side methods and client-side applications. In general, through not always, interacting with databases. I have also written C++ code, both for similar purposes and for hardware control.
My experience is that in a well-written Java application, the performance of the JVM is usually not the real cause of performance bottlenecks that can be felt by the user. Design errors can make Java code slow; it may be a relatively "easy" language but the programmer still has to understand very well what he or she is doing, and seemingly unimportant choices can have serious performance impact -- just as in C++.
Fortunately, understanding the system is much easier in Java than, in say, Visual C++ (to mention just one abomination from the deep.) I suspect that on average Java code contains fewer blunders with a serious performance impact than C++ code.
Certainly, for the really high-speed parts of the code and for specialized purposes I too would still recommend to use C++, but for 95% of all code there is no reason not to write it in Java. And it is fairly simple to integrate C++ code in Java.
I harbour a suspicion that programmers who insist on writing all code in C++ or even C because they think that it will be faster, are largely the same people who insist on writing labyrinthine, unstable and unmaintainable code because they think that is faster. As you may suspect, I don't have a high opinion of programmers in general: I think that in general, only a third of professional programmers can be called competent (enough) to safely handle tools such as C++. The rest should be kept in to a sandbox.
And besides, the majority of infuriatingly slow applications that I have seen were not written in Java: More typically these are the work of naive Visual C++ and Basic programmers, the kind of people who recalculate the layout of the entire screen when they need to change the display of a variable, or copy the content of an entire database to memory on start-up.
A caveat, however: Java performance can depend enormously on how your system is set up. For example, the way the on-access scan of McAfee antivirus handles the Java JRE and other libraries is a bloody disgrace and results in painfully and unacceptably long startup times. But that is hardly Sun's fault. (Note for the next job interview: Ask what virus scanner they use.)
I admit that relying on garbage collection can be unnerving for the C and C++ programmer. I think I was nervous about not explictly de-allocating memory for the first two years or so; then I got used to it. (And, despite finally acquiring Java habits, I do not forget to de-allocate in C++ code. If anything, I am more accurate in it than I used to be.)
Ironically -- and this should serve as another caveat -- the biggest memory leak I ever created was in Java, not in C++. What I had overlooked is that the GC will not get rid of memory if a reference to it has been passed to a dialog; and I had forgotten to dispose of the dialog, which (very indirectly) controlled the display of a large data set.
While I agree that in theory, and in labratory conditions, Java is just as fast (sometimes faster) than C/C++, in practice it doesn't usually end up that way.
.NET available instead.
The way normal people write code, and the libraries and functions that normal people use, java is slow as snot. I don't care why that is, it just is, and it makes me steer away from Java client applications if there is something that is native or
Real world results are different from labratory ones as far as Java is concerned in my book. And that's just my experience.
If you need web hosting, you could do worse than here
Garbage collection is not a magic bullet that makes memory leaks dissapear. You can forget you have a reference to something just as easily as you can forget to free something.
Let me see here: on the one hand a C program will possible run very well in a particular environment. A interperted langauage- has to do several things- including guessing your hardware, optimise itself, not crash etc etc. and lets not forgot many of these things are done while your using it. I used J Office and was impressed. It did what I could want it to. Sure it had some bugs, some more anoying than others. Just my opinion is its issues were minor compared to the offic 2k (in fairness to office it was just released of OS X). Java 1.x sucked- plain and simple- it was terrible buggy. Java 1.5 sucked less. Java 2.0 is practicly a rewrite and works. I do agree the initial run of java applications is not particularly good. (J-office took 15 minuts the get going first launch. The second launch was 10. then 5 then just a few moments.) However it seemed to be as well written-suposedly their is a multithreaded edition that's even better and sexier.
As soon as you go to a website and seed the dreaded .jsp extension, you know you're in for a wait.
All the websites that use Java are just ridiculously slow. Name one that isn't.
Could you imagine Google running Java and some JVM?
Anyone that complains about java's being a bad language-How many of you are using Limwire or Azereus?-Your using Java
i've never noticed much difference in performance in c++ or java, except when writing gui apps and using swing with java. swing is slower than any gui toolkit you can use in c/c++, at least any i've used. but non-gui java apps never seemed slower to me, who's been saying this?
Spiral out. Keep going...
Summary: "If JVMs were smart, garbage collection would be fast."
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.
Blasphemy is a human right. Blasphemophobia kills.
On the other hand, we absolutely cannot do without C or something very much like it. What else would we use to write the JVM in? And Perl?
C is getting old, we need a replacement. C++ is too complex and error prone; At least -- we know we can do better than either C or C++ and keep the high performance. Look at the D programming language, as a proof of concept. Can we do better than D and keep the performance?
I18N == Intergalacticization
I believe that, directly or indirectly, an unjustifide emphasis on execution speed is the one of the biggest causes
of the failure of software projects. The problems usually begin with the choice of
implementation languages. Programming languages should
be chosen for the ease and cost effectiveness with which they can be used accurately and reliably generate
a correct and maintainable application that satisfies the customer.
In my experience selecting a language because it is "faster" than another language
before it is even known what the speed issue is for an application is just a costly mistake.
For speed critical parts of an application an experienced C++ programmer might be a without-which.
A tool like JWrapper can be used to connect a Java application to an optimized C++ library.
Speed requirements should usually be dealt with towards
the end of the development. Most of the execution time is usually spent in a small fraction of the code.
Only that portion of the code should be optimized because optimizations can be costly to derive and implement,
costly to maintain, and more difficult to verify.
In the interest of peacefull coexistence we might all agree that:
1. Java is sometimes too slow
2. C and C++ programs sometimes have memory leaks.
3. Writing efficient, reuseable, object oriented programs in C++ can be an extremely subtle business and,
as a result, good and efficient C++ programmers are harder to find.
A quick web search turns up several surveys with lots of benchmarks,
http://java.sys-con.com/read/45250.htmr k.html
http://www.idiom.com/~zilla/Computer/javaCbenchma
This is about as much of a myth as the myth of the earth traveling around the sun. There is a lot more to allocating memory than this article lets on. Psuedocode will always be slower than machine code no matter how you slice it. You can do various tricks to make it seem faster by instruction count at certain things but in the end those same things can be applied to compiled code like c/c++. Most people can accept that as fact and move on using Java where it seems appropriate. Make all the excuses and extraordinary claims you wan tint the end Java is just plain old FAT n slow, anyone in any programming course who has used java can tell you that.
Oh and it is hard to test out his little theory on the free malloc in C++ because you can't do the same thing in Java. You can try but it will get around to the free part when it gets good and ready and may not attempt the malloc until you use the memory.
Certainly much of the Enterprise business world I've interacted with is under the same impression as this statement so you are in good company. Except that last part "And it is fairly simple to integrate C++ code in Java." . I'm curious if you could speak to your experience on how is it fairly simply to integrate Java with any other code. The JNI interface is very error prone and can have huge impacts on performance. When I consult for people wanting to interoperate Java with some other language the best solution is to go through some known interface protocol like SOAP or HTTP.
In fact, sometimes the best way to interoperate distinct Java programs is to isolate them within different JVMs on different machines. Companies like EBay implement what they call "use case" machines where hardware isolates Java software release and performance problems.
Java runs best as a SUSA environment, single user, single application. Java's JVM doesn't do well at all as MUMA, multi-user, multi-application environment unless you have a highly customzied environment as with web application servers. Web application servers are really a misnomer. They are not application servers. They are JVM environments that allow Java to scale to MUSA, multi user single application. The raw JVM assumes one application, one user in my opinion when one is considering performance.
Java allocates objects linearly, i.e. it simply increases an index. When that index reaches the top of the garbage-collected memory, memory is defragmented.
C++ and C have quite complex algorithms that search lists of blocks for either the biggest size or the closest to the requested size. In reality, manual allocation is slower than the Java model.
But there is a very important problem with Java that C++ does not have: Java allocates all its objects on the heap, whereas in most C++ apps most objects live on the stack. This little difference makes C++ programs faster, even though allocation of Java objects is significantly faster.
Another problem with Java is that Swing is slow, and therefore Java apps are perceived as slow. But it is only Swing that is slow, because Swing implements its own Window system, complete with region geometry.
In the end, Java wins for me, because I simply don't have to track down pointers as in C. From the day I started to use Java, my productivity has skyrocketed, even if my programs 'feel' a little slower.
I recently decided to try out Eclipse - after hearing how brilliant it was - to replace Anjuta for C++ development. I notice an eclipse package is in Debian so I "apt-get install eclipse-sdk". Oh, it needs a Java SDK first. No worries, I'll just install one of those using apt. I'm sure this will be easy.
Easy? Hah! Maybe it's easy for x86 users but us PPC users are out in the cold. After hours of fruitless searching I eventually chance upon the IBM Java SDK on the IBM website. It's only in RPM format, but a quick "alien" later and I have a package. I install it, go to run it, and the JRE crashes.
So I simply delete the Java SDK and any hopes of using Eclipse on Linux/PPC. I'm not going to jump through hoops; if it doesn't "apt-get install" then I don't want to know about it.
I always find it interesting to see how many C/C++ programmers think manual memory management is "fast". I think anybody spouting off about such topics should be required to have least *implemented* a fast malloc()/free(). It's a non-trivial task, and when you see that the hot-path is still dozens of instructions long, it really puts the cost of malloc() into perspective.
A deep unwavering belief is a sure sign you're missing something...
So does JVM i/o performance, specifically disk, still suck the big one when dealing with moderate i/o loads?
I believe that this battle can be summed up in the battle of Java vs. PHP. Here we have a fully OO VM based language that has been widely deployed on both Unix and Solaris, vs. a (mostly) UNIX only scripting language turned web programming language with lots of web-specific features. I have developed large solutions in both languages, and it really comes down to: PHP rocks for quick-and-dirth websites. Put a PHP next to a Java guy to develop a basic ecommerce or content mgmt website, and PHP will TOAST that guy. Now required six-sigma reliability, 100+ hits per second, redundant servers w/ clustering, the ability to connect to multiple corporate database from different manufacturers, and other high-end enterprise features, and Java wins hands down. Not to mention of the security of PHP vs. the security of Java - PHP is "wide open" in many ways. USE a big hammer for a big nail, and a small hammer for a small nail. Java ran WebMD (many thousand hits per second, all data driven) with an early version of Java 1.1. - yes, we need to clean up the socket code some w/ SUN, but it worked, and it worked very well. The future looks to me .NET - Microsoft was brilliant - a well defined software app network architecture what is language agnostic. This time in a few years there will be many Java programmers writing web-service code behind the .net standard.
Thanks for reading my stream-of-consciousness.
Horns are really just a broken halo.
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ ref/SoftReference.html
It's been in the JDK for quite a while, and is exactly what you say is missing.
This is really very good idea.
Bit it just illustrates the typical tradeoff between speed and memory.
Quick, but use twice the memory, or slow and don't use additional memory.
Is this algorithm in use in the JVM garbage collector or in other languages with garbage collection?
"if you didn't trust your compiler (or working toward multiple architectures) you could always use some compiler directives and some embedded asm"
:-)
You could also just compile the code, and dis-assemble the resulting object code to *know* what the compiler is generating. But, I guess its more fun to use imagination and conjecture to create points to debate.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
"Assume you are a contractor and all code is to be passed off to the internal development team afterwards"
You are doomed no matter what you do in this situation. NIH syndrome take over and you'll get blamed for everything anyway. When there is a problem the in house people will tell their PHB that whatever you did caused the problem. The PHB won't understand anything anyway.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
The C++ new and C malloc are not the same thing.
In C++ allocation is a fast business. Open up stdlib code and see what I mean.
In C, good applications use malloc carefully to minimize number of malloc calls.
Also, especially in C++ we AVOID dynamic allocation as many others have observed.
The author of the article is a mediocre programmer who does not know the nuances of his trade. I wonder if he could program in any other language than Java.
--exa--
Name one that isn't
I'll give you two. Ebay and Amazon.
But the allocation sequence isn't the bottleneck -- it's all about the actual garbage collection itself. GC can be costly in terms of cycles and, if you're unfortunate enough to be running in low physical memory, page faults. The reorganization of memory may improve application locality, but that may not be enough to buy back the performance penalty.
Rather than try to argue the case with hand-waving, my student Matthew Hertz and I performed experiments on an infrastructure that lets us replace garbage collection with malloc/free in Java programs so we can quantitiatively compare the cost of garbage collection. Our paper, to appear in OOPSLA 2005, shows that a good, generational copying garbage collector can match or slightly beat the performance of malloc/free -- but this requires 5X as much memory as the allocator. It's a classic space-time tradeoff. On the other hand, if you don't have enough RAM to hold the entire heap, though, garbage collection runs tens or hundreds of times slower.
--
Emery Berger
Asst. Professor, Dept. of Computer Science
University of Massachusetts Amherst
The C++ Corba bindings are incredibly obtuse. The "smart" pointers there are incredibly "unsmart", and the semantics of memory management is rather strange.
Upcasts are (conceptually?) new objects, meaning that you can free a CORBA_Object_ptr object, even if you have another *_ptr to a *::_narrow()'d version of it. In fact, you should, as that is the only way to guarantee the CORBA_Object ever gets freed! To keep some level of performance, while maintaining this obtuse semantics, even objects with plain pointers have to be reference-counter. Furthermore, when you (conceptually) deep copy an object with *::_duplicate(), in reality all you are doing is increasing a reference count. Thus, you will have to worry about reference counting whether you use CORBAs smart pointers or not! A further complication comes with out-parameters, which means that in addition to *_ptr, you will also need *_out for function out-arguments. All to keep the reference-counting (before we add smart pointers (the *_var types)) "sane".
True enough, using the *_var types make CORBA look almost sane, but they are optional (for performance reasons), and this complicates the CORBA C++ binding a lot. Actually, I'm yet to be convinced that the *_var types actually work sane enough, or get a clear explanation of when they work, because everything in the C++ binding remains nonintuitive. With typical implementations of smart pointers, such as e.g. boost::shared_ptr, new objects will have a reference count of zero, untill they are managed by a smart pointer, and when the reference count decreases to zero, the object will be free'd. Given the obtuse semantics described above, this is not possible with CORBA, as each new object will have a reference count of 1
Ok, maybe this explanation was as obtuse as the CORBA C++ bindings themselves, but it serves to illustrate my point. It would not be particularly hard to create a C++ CORBA binding that was as easy to use as Java's. It just happens that the CORBA C++ binding was designed by a committe that worried more about performance, multithreading, pre-standard-C++-compatibility, and the NIH-syndrome, than something clean and useful. IMHO, they should have left the micro-optimize-the-hell-out-of-it to the C binding, and left a clean C++ binding, but they didn't. Of course, all of this is in hindsight, at the time the bindings were created, I'm sure all the decisions made perfect sense!
... LOL. Comparing malloc to a memory manager is an early indicator of bias which I wouldn't point out if they had bothered to do so themselves (because it is valid to point out that C++ people tend to marginalize Java based upon performance out of hand and that's wrong.)
But, to compare oranges to oranges, my texture resource manager (written in C++) returns batches of pre-allocated memory (like the Java system mentioned in the article) in less than 6 machine instructions.
Loading...
So Java isn't slow anymore.
It just lacks a decent FOSS implementation.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
it would be funnier if you'd stfu
The idea of a garbage collector for C has been around for a lot longer than 11 years.
Hans-Juergen Boehm and Mark Weiser, "Garbage collection in an uncooperative environment", Software Practice and Experience, 18, 807-820 (1988).
"Weiser experimented with a special version of the collector for tracing storage leaks; typically, the collector does a better job than programmers."
Here's an even earlier reference from 1984 to a garbage collector for C, in a paper by Bjarne Stroustrup.
Newsgroups: net.lang.c
From: mark@umcp-cs.UUCP
Date: Sat, 2-Jun-84 21:37:41 EDT
Local: Sat, Jun 2 1984 6:37 pm
Subject: garbage collection in C
A footnote on page 11 of the AT&T Bell Labs Memo 109 entitled Data Abstraction in C, by Bjarne Stroustrup, says that a garbage collector version of the malloc function exists. Any one else ever heard of this? Know where I can get one?
--
Spoken: Mark Weiser ARPA: mark@maryland
CSNet: mark@umcp-cs UUCP: {seismo,allegra}!umcp-cs!mark
-Don
Take a look and feel free: http://www.PieMenu.com
I'm not a hard-core Java or C programmer, myself, so maybe there are fine technical details that I'm not privy to. But it seems to me that the primary lesson of the "Java is slow legend" is that proves the truth of the old saying:
You never get a second chance to make a first impression.
When Java first came out in the mid-90s, programs written in it ran sloooowly. This was especially true for the types of client-facing programs that people would notice were written in Java (things like applets).
Today the JVM has been massively improved, hardware has gotten a couple of orders of magnitude faster, and Java programs aren't slow anymore. But people still think "Java == slow".
Why? Because that was their first impression of Java. And it will take many years of contrary experience to overcome the power of that first impression.
From my layman's point of view, Java has really only seemed to be adequate performance-wise for a few years now (I remember Eclipse being the first Java app I saw that really felt as snappy as a native app, and it launched in what, 2001?). So a lot of people still probably have a lot of hours they need to log working with modern Java apps before the "myth" gets completely dispelled...
Read my blog.
"The common code path for new Object() in HotSpot 1.4.2 and later is approximately 10 machine instructions"
While that sounds very good, they don't add that there is overhead introduced in the form of reference tracking in managed-style languages. When each variable loses scope, its reference count is decremented. That operation, while not hugely impactful, is not entirely free. It takes at least a single testandset instruction. So if you are managing a large number of references to that object, you are shifting the burden to other places in the code.
Nothing is free... you don't get 'bytecode portability' for free over native instructions. You can't compare a managed memory model new to a unmanaged memory model new because they aren't doing the same thing. You also can't compare program environments without also measuring startup and shutdown time.
The bottom line for Java and CSharp is that byte code doesn't come for free...and modern C/C++ developers use object pools, not malloc/free. You might new an object quicker in Java, but if you compare overall execution times the extra cycles shake out in other places. But to compare an object oriented allocator to a general purpose byte allocator is a bit silly.
Just remember...if bytecode were the fastest way to execute instructions on the processor, the processor would work with bytecode. But modern JVM's convert bytecode into native instructions, so they'll always be behind in performance no matter how optimized their memory management. Yes, simple repeated malloc/frees can be shown to be slow...but thats why concepts like reusable pooled objects came about. Thats why there are about 100 different malloc libraries, each claiming to be the fastest at some memory usage tradeoff.
I just don't buy the BS that Java is as fast as native languages...even in memory management. If java can manage its memory quickly, so can I. Java isn't written in Java, now is it?
You really have to love languages where a invocation "suggests" that the method "expend effort"
Good effort! You did your best, son! Good hussle out there. It's too bad you're still gobbling up 100MB of RAM, but don't worry tiger, we'll get 'em next time.
The GUI is the one big problem with Java. Swing is a dog, despite being a considerable improvement over AWT (which is a dessicated undead dog from the paleozoic). Azureus is pretty good in general for the simple reason that it is very minimalistic with the GUI. It keeps things simple, and so it doesn't suffer.
it uses SWT.
JIT compiles the Java bytecode to native machine code -- which is, at least theoretically, potentially faster code than a C or C++ compiler can generate because it has more information. Sure, you could say that you could just implement a JVM/JIT on top of C/C++ for every program you write and get the same performance, but that's just silly.
HAND.
Google IS running Java VMs. Java powers Gmail and Blogger, for example.
Those rules seem inflexible to me, and sound like rules a professor would tell his students when he is tired of reading their unreadable attempts at optimization. Optimization is really useful if you need your program to go faster. Of course, if you don't know how to optimize, you will have trouble. Here is a very good page by Paul Hsieh about optimization:
http://www.azillionmonkeys.com/qed/optimize.html
Qxe4
I don't see the problem
Suppose I have a class name and I create a subclass place-name by adding a slot for a location. Meanwhile I need colours, both for my paints and my objects so I create a colour. Finally a create a class coloured-place-namefor named things in that are put in places and have colours, by multiple-inheritance, taking first place-name and then colour.
At this point I have an inheritance ambiguity. Obviously place-name comes first, but what next, name or colour? What I don't see is why I should care.
It is only going to matter if I have a method, act, defined for both name and colour. But how could that happen? I'm only using multiple inheritance because all three of place-name,coloured-place-name, and colour make sense. If only two of them made sense I would use single inheritance. So the meanings of act on the two classes are orthogonal, I don't want one shadowing the other.
We really have a name clash, and need to sort out our names. Perhaps act on name should be speak, and act on colour should be paint
OK the inheritance graph isn't totally ordered, but each method is only defined on a subset and, for any particular method, its subset will be totally ordered. So I cannot see a problem that actually matters in practice
We have never encountered many problems with JNI interfaces, perhaps simply because we choose to keep this kind of interface as simple as possible and do not actually do it that often. Certainly I find it much less troublesome and time-consuming to generate and test a JNI interface than most others; although that may be largely down to experience.
I remember that we once had one server-side JNI call we had enormous trouble with, making us try all kinds of ways around it, including testing three or four different VMs. Some were indeed more stable than others, but we finally discovered that it was our own fault because our JNI implementation had a bug in its memory management. We fixed that and the system became capable of running for indefinite time (i.e. until the hardware fails or we have a power cut) without human intervention, one any Sun JRE after 1.3. Actually, I recently saw that it still has an UTF string release bug in it, but apparently this doesn't cause any trouble (yet).
Sometimes the system architecture calls for layering multiple interfaces -- as in PL/SQL calling Java calling C++ -- and that can be tricky, because you have to respect all the different 'boundary conditions'. But on the whole JNI is much better than some other interfacing technologies I have seen; especially the ones designed for specific systems.
I totally agree, someone should really rewrite Firefox. I have no idea what it is written in now but it really sounds like that java you mention.
An additional comment: One reason I like to work in Java is that some of my software is single-user software in the most literal sense: There is one person using them, besides myself.
Writing 15,000 lines of fairly complicated code for a single user, or four times as much for a dozen users, can make sense; although probably most software companies would disagree. However, I naturally want to do it in a language that offers rich libraries and is easy to troubleshoot. Java fits the bill almost perfectly; in many other languages I would be spending twice as much time on the same project.
I can perfectly understand that people who write application servers for eBay, or office applications for an user base of millions, feel that Java is not the best choice for it. However, the economics of that are entirely different.
I think that if you have to write an application that is too complicated or demanding for a script language, but also need to keep the investment in time and resources down, Java, mixed with a little C++ where necessary, is close to ideal. Before Java, I used a mix of Tcl/Tk and C++, and that was OK, but not great.
In Java, the auto garbage collection is as good as Perl's
It's just that Perl doesn't have GC, but shoddy reference counting, which is easily confused by cyclic references. If Java is as "good" as Perl there, that's not the best of advertisements.
Your stack pointer in inside the chip in a special dedicated register.
When a function is called it's stack frame is created to store the return address and storage for any registers that will be changed. It is allocated by simply subtracting a number from the stack register.
Since its always allocated and always freed, to allocate some space for your automatics costs zero cycles - you simply subtract a bigger number from the stack pointer register.
When you have something on a stack frame it is referenced using the stack pointer, so for example
int foo()
{
int y = 100;
}
The variable y is actually some offset plus the stack pointer, the offset is coded into the program instruction because it is fixed.
For example it may be the variable y will be something like (4+sp) and int y=100, becomes a "move 100 -> 4+sp".
Notice that you did not need to store the address of the block, because the variable is always at a fixed offset from the stack pointer.
Now consider the case of an allocated block, the address of that block has to be stored somewhere, normally IN THE STACK FRAME! Even if you made a really small program and the compiler was able to keep it in a register, because the register isn't dedicated to the purpose, the compiler would still have to save and restore it as part of the function entry.
Please step back from your position and see that your position is incorrect.
Well, let's see. My *bank* (TD Canada Trust) uses it for their online banking. It's never been anything but fast for me.
I also work on my company's team developing our online applications, all in Java on the server side. Whenever we'd had a performance issue, it'd been traced to bad code, not the JVM. But our modest hardware is supporting users from all over the country, and our customers are the medium-large (+ gov't) businesses, and we have no trouble supporting them with this setup. Now we don't use JSP (I vetoed that approach because it doesn't enforce MVC well enough for my liking), but rather a Servlets+Velocity templates approach works well for us.
You can accomplish anything you set your mind to. The impossible just takes a little longer.
Thanks for your thoughts.
I am talking about all 3 BSDs, complete unix operating systems, kernel and userland. They use CVS to maintain their code, cvs commits are sent to a mailing list so people can see what's going on. I get those messages. Memory leaks are very few and far between, despite development being very active, all the time.
Quite frankly I wrote a (thread-safe when necessary) reference counting handle template for C++ and so I don't need a garbage collector in the kind of applications that have non-trivial heap profiles.
MEANWHILE I have useful destructors instead of "maybe later" finialize methods. Fo _me_ the non-starter feature of java is that I have to reference count manually _on_ _top_ _of_ the garbage collector if I want to have my objects perform end-of-life actions when they move out of reference. In C++ I can put close-and-clean functions in a destructor, in Java I have to manually close the object "when I know it's ready" which is the same amount of work as freeing an allocation "when I know it's ready".
Tools have to match jobs. I do use Java on occasion, but only for toy-like applications that don't have to survive very long.
One of my company's (C++) products was written solely by myself (to version 1.1, then was handed over to a maintainer and feature crew) has multi-month runtime requirements that it meets quite nicely. I put the heap issues to rest so early in the development cycle. The application _could_ have been written in java, except the fast recovery (etc) features that a proper distructor give me would have been impossible in Java. In C++ I throw an exception and the stack unwinds and I _KNOW_ with certanty that I wont have to self-contend with any object was abandoned by the unwinding. The destructors were invoked and completed in proper context and in unwinding-order. Java simply _doesn't_ have the ability to do that.
An example you ask? Create a class that destructively accesses/updates a file at close time (lock files, db-journals, and state maps for instance). Now use a deterministic file naming system, so that thread X uses file name X. Now throw an exception from a point where the file is open, and catch that exception in a scope outside the file object's scope and then re-enter the scope after catching the exception...
OK, in java you _could_ catch the exception at the scope where the file was allocated, close the file, and then re-throw the exception. But then you need to do the same thing for each scope-of-object for each object that is dependent on the file. Which will only work if you refrain from building complex object-structures on the heap (q.v. trees, etc). Well unless you... (recurse as necessary)...
A reference counted handle object with proper destructors will traverse complex heap structures in depth first order, so objects can be written in closure (see "invariants" in OOD). Java finialize behavior only works in breadth first order, so the objects can and do not have closure without the programmer doing manual recursive cleanups.
So the garbage collection time can be as fast as you please but there are a non-trivial set of programs that simply will not function in java without paying the "clean up cost" twice. Once by hand, and once again to discard the memory. The cost is paid in complexity and dependence resolution, none of which is "easier" than heap management and all of which requires the same attention to, and possesses the same semantic pitfalls as, faulty heap management.
Software, and by extension, languages that help you when you _don't_ want the help are (IMHO) more harmful than languages that don't help you when you do.
It's "better" to have an additive environment, where you put in the features you want and need, then a subtractive environment where you ignore the features you don't need and _hope_ that they don't do you harm. (q.v. every object in java is a mutex but if you dont need it to be the execution environment... what exactly? just pretends it isn't?)
But I was having login problems at work...
/sigh
ah, technology...
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Si it's time for you to read about UTF-8:
Yes, you are absolutely right that memory leaks and pointer problems in C suck, and that dealing with them is a colossal waste of time. And Java's garbage collection is, in some ways, better than Perl's.
However, Java is neither the only, nor the first, nor the best language to offer garbage collection and runtime safety. Java's type system sucks, its implementation of generics is awful, its native code interface is slow and cumbersome, its libraries are bloated and saddled by backwards compatibility issues, and the platform is being designed by huge committees of self-appointed experts.
Do yourself a favor and use some other language. There are many choices; my personal favorites are Python, C#, and OCaml.
I'm so sick of this recurring "Java is as fast (or faster!) than C++" absolute nonsense. Java is provably slower than C (in other words, Java has overhead as compared to C). Consider an operation X.
... if you're an idiot.
My C++ program, doing operation X, has to perform the following actions, at the machine level:
X
An equivalent Java program, doing operation X, must perform the following actions at the machine level:
**A Bunch Of Stuff**
X
The part varies depending on the case. Heck, sometimes it's not even there (JIT and all that). But it is there, and it's not free.
Honestly, this is the most brutally, painfully, hit-you-over-the-head-with-a-sledgehammer obvious thing ever.
Yes, a given Java program can be much faster than a given C++ program... a given shell script can be much faster than an assembly program, too.
Clearly this implies that shell scripts are faster than hand coded assembly!