[java] Will Java ever had the speed/facilites of C++?
Quote:Original post by wyrzyQuote:Original post by psamty10
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
Whats especially interesting about this are the reasons given for Java being easier to optimize than C++.
Interesting article. Especially the part about "garbage collection is slow" is supposively a myth, and that it says it can be faster than new/delete in C++. In all the classes that I've taken in college, the professor would always preach how Java, do to the fact of the garbage collector, could never be used in real-time applications, and being a student, I believed it. But how can the garbage collector not be slow. What if it tries to delete objects when you want to render graphics or something. I have heard that there is some way to request that the garbage collector not run, but the article says the garbage collector can really delete objects whenever it feels like it, provided there are no remaining refrences attached to it.
The problem is that the GC is non-deterministic. Someone mentioned that the GC is fast and only takes a fraction of a millisecond; to a crtical RT system that's could be an unacceptable amount of jitter. Also, that's a millisecond of jitter on a multi-gigahertz CPU, not on a 60MHz ColdFire or 12MHz PIC. Recall that the program can do nothing else during the collection; this is unacceptable in the kernel which is often the nature of RT code as well (e.g. respond to an interrupt within 500us).
Quote:
But the only question I have is, if this article is correct and Java can be so fast, why haven't more programmers been using it. I know it has began to pick up in places, but I would say over 90% of games are still programmed in C++. I'm sure that one reasone for this is the fact that they already have so much code that can be reused from existing projects.
Java is very popular, just video games is just an area it's not so much. The GC wasn't always so fast, and JRE issues add another layer the developers have to deal with, but no more so than DirectX or .Net do.
[Edited by - Magmai Kai Holmlor on October 2, 2004 9:34:53 PM]
Quote:Original post by Magmai Kai Holmlor
Also, that's a millisecond of jitter on a multi-gigahertz CPU, not on a 60MHz ColdFire or 12MHz PIC.
Completely unrelated, but I thought Coldfire == Motorola 68000? They clocked those up to 60MHz? The one in my Mac Classic was only 7.83... :(
Quote:Original post by Magmai Kai Holmlor
The problem is that the GC is non-deterministic. Someone mentioned that the GC is fast and only takes a fraction of a millisecond; to a crtical RT system that's could be an unacceptable amount of jitter.
I always thought this was a cool quote from the Java SDK license:
"You acknowledge that Licensed Software is not designed or
intended for use in the design, construction, operation or
maintenance of any nuclear facility."
Java is clearly a server and applications programming language, not a systems language and obviously not intended for the highly specialised area of real-time systems, let alone critical ones. For the intended types of programs, GC is a fantastic way to free up programming time and prevent bugs.
Practically, non .NET C++ and Java have entriely different problem domains. Comparison is futile.
Quote:Original post by PnP Bios
C++ didn't kill Java. .NET did.
(A) Last I checked, Java is still widely used.
(B) Why do you post flame-bait in this forum? I almost feel like I should raise your warning level, but I'll let it go this once.
Quote:Original post by wyrzyQuote:Original post by psamty10
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
Whats especially interesting about this are the reasons given for Java being easier to optimize than C++.
Interesting article. Especially the part about "garbage collection is slow" is supposively a myth, and that it says it can be faster than new/delete in C++. In all the classes that I've taken in college, the professor would always preach how Java, do to the fact of the garbage collector, could never be used in real-time applications, and being a student, I believed it. But how can the garbage collector not be slow. What if it tries to delete objects when you want to render graphics or something. I have heard that there is some way to request that the garbage collector not run, but the article says the garbage collector can really delete objects whenever it feels like it, provided there are no remaining refrences attached to it.
But the only question I have is, if this article is correct and Java can be so fast, why haven't more programmers been using it. I know it has began to pick up in places, but I would say over 90% of games are still programmed in C++. I'm sure that one reasone for this is the fact that they already have so much code that can be reused from existing projects.
Simple - its easier to clean up a large block of memory than have to deal with each "delete" call separately. That's why the garbage collector can be faster. It waits until it has enough crap for running cleanup to be worth its while.
Now, as for the real-time implications, I think you've forgotten the whole point of real-time: you don't care about average performance. You care about beating your deadlines 100% of the time - worst case is key. Java GC destroys worst case, as it could kick in at any time to run cleanup. This means that any given operations worst-case-running-time is as long as a full garbage cleanup, which can be long.
Don't forget, too, that one benefit of garbage collection is that it not only decides what to delete, but when to delete it. Generally, it will try (to the best of its ability) to clean-up when your program isn't doing a whole lot of intensive work. This usually makes deallocation much more transparent than in a non-garbage collected program.
Also remember that if you are writing a real-time program, it is definitely good practice to prevent memory allocation to the best extent possible and reuse already allocated memory. For parts where rapid memory allocation/deallocation is absolutely necessary, a garbage collector may have better performance because it doesn't have to deallocate memory once the reference(s) to it is gone, it can hang onto it and wait to see if it can be used for something else.
This isn't so much a Java over C++ advantage, but a memory managed over non-memory managed advantage. A memory management system (in this case a garbage collector) has a better idea of what the "big picture" is as far as memory usage is concerned. Rather than have methods (or funtions if you like that term better) take care of the creation and immediate clean-up of their own little piece of memory, a garbage collector governs all of the memory the program uses, and can manage resources at a global level instead of little pieces at a time.
Also remember that if you are writing a real-time program, it is definitely good practice to prevent memory allocation to the best extent possible and reuse already allocated memory. For parts where rapid memory allocation/deallocation is absolutely necessary, a garbage collector may have better performance because it doesn't have to deallocate memory once the reference(s) to it is gone, it can hang onto it and wait to see if it can be used for something else.
This isn't so much a Java over C++ advantage, but a memory managed over non-memory managed advantage. A memory management system (in this case a garbage collector) has a better idea of what the "big picture" is as far as memory usage is concerned. Rather than have methods (or funtions if you like that term better) take care of the creation and immediate clean-up of their own little piece of memory, a garbage collector governs all of the memory the program uses, and can manage resources at a global level instead of little pieces at a time.
"Java" with directx? Microsoft Visual J#.NET with Managed DirectX.
I don't know why, just thought I'd mention that. Someone said they liked coding in Java, but missed powerful gaming capability.
I don't know why, just thought I'd mention that. Someone said they liked coding in Java, but missed powerful gaming capability.
Quote:Original post by Pxtl
Now, as for the real-time implications, I think you've forgotten the whole point of real-time: you don't care about average performance. You care about beating your deadlines 100% of the time - worst case is key. Java GC destroys worst case, as it could kick in at any time to run cleanup. This means that any given operations worst-case-running-time is as long as a full garbage cleanup, which can be long.
Non-deterministic behavior is truly the reason Java has struggled for real time applications, but if you are willing to add a little to the learning curve a solution does exist:
http://javolution.org/
btw, the author has used this library along with a homegrown OpenGL interface to write hard realtime air traffic control software for the airline industry. There is a pdf presentation on a NASA site:
http://spacecom.grc.nasa.gov/icnsconf/docs/2003/05_B2/B2-07-Naqvi.pdf
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
