I've been designing a card game in Java on Windows. It runs really well on my laptop and a few others, but on a lot of other systems (even a few newer ones both Mac and Windows) the animation is incredibly slow.
I've found User Interface Toolkits for Java to be the best resource so far, but haven't been able to make a significant improvement. I'm using the AWT/Swing libraries.
Question:
Looking at my game, (<1.5Mb), how could it be that on some computers (of similar spec) the performance seems to be significantly less that what it is on my laptop? The entire app is event-driven and I've done most of the optimization that I reckon could be done given the implementation.
I have a feeling it is memory-related. I create (compatible) and then store all my images into an array at the start, and then reference them there.
Note: I decided to make this game so that I can learn and practice some new ideas, so I'm not just trying to share it - I'm really interested to find out what's going on here.
On not all operating systems, the Java 2D rendering pipeline supports hardware acceleration by the GPU. It depends on the Java implementation that you're using.
One of the new features for Oracle's Java SE 7 implementation (which is coming out at the end of the month) is this: XRender pipeline for Java 2D which means that it will have much better performing 2D graphics on Linux.
For Windows, in Java SE 6 update 10 there were some improvements to make Java 2D perform better by using Direct3D hardware acceleration (source).
For the Mac, you should try the system propeties and rendering hints described in this document, particularly the one that tells Java to use the native Quartz renderer rather than the Sun renderer.
..why could it be that on some computers the performance seems to be at least half of what it is on my laptop?
Video drivers. I was involved in a thread on usenet a long while ago, where there was a phenomenal difference in rendering speed on machines with similar spec. Ultimately it was concluded that some machines were using outdated video drivers, and that was the root cause of the difference.
If that turns out to be the case here, your best bet is probably to do a rendering test. Check the FPS, and if it is too low, advise the user to update the drivers.
Try popping it in a profiler and see what comes up. I'd do it on both windows and mac and compare where exactly you're getting the problem. JProfiler is my favorite, but YourKit is good as well. You can get a trial version for 30 days which should be plenty of time to figure this out.
It's probably graphics hardware related, hardware acceleration vs software, since there is such a difference between Mac and Windows noted on this thread.
Related
I was wondering if anyone have gotten Java up and running on a BeagleBoard or Cubox? I'm thinking about buying one for a project I'm working on on my spare time, but as parts of this project is written in Java I first wanted to know if these tiny computers can run a JVM at all?
From what I read on http://www.oracle.com/technetwork/java/embedded/downloads/javase/index.html there are editions for ARM, and Solid-Run (the manufacturer behind Cubox) have also written some info on their wiki: http://www.solid-run.com/mw/index.php/Oracle_Java_on_CuBox.
However, what I would need to know is:
Can I consider ARM JVM == x86/x64 JVM in terms of functionality (a.k.a. "will my code run without changes") (my code is pretty non-graphical, mainly a HTTP API)?
Are there any license "problems" with JVM on ARM (compared to JVM on x86/x64)? That is, if I suddenly want to mass-produce my little spare-time hobby project and sell Cuboxes, will Oracle sue me?
Anyone have any experience with Hibernate/HSQLDB on ARM?
Perhaps too many questions in one, but I think they're all related enough to be put in the same thread. In general, I want to know more about JVM on ARM and how developed and mature it is.
Thanks!
Answers to 1 and 2 are on the Oracle page. "development is free, but royalties are required upon deployment on anything other than general purpose systems. In all cases, these products are fully Java SE compliant"
As for 3, I don't know about Hibernate (which shouldn't be a problem), but HSQLDB has been used on ARM by Symbian and others at least since 5 years ago.
I've always used java for developing cross platform applications, however, this time java can not solve my problem. The problem is, I have to develop an application which is computationally expensive. More precisely, in my application there is a simulation which is a little too heavy. I made a java prototype app but it's not fast enough and I have some lag in my simulation so I started to think to switch to c++.
My application has a GUI and I was wondering if I want to switch to c++ for a cross platform application, what should I do with GUI?
My questions are:
If I use Qt framework, is my application going to be significantly faster?
If I deploy my jar file to native os executable (.exe, .app, etc) is my application going to be significantly faster?
p.s. Mac OSx, Windows and Ubuntu are target platforms for my software.
This Article may Help You, I Face the same questions a couple of years ago. I decided to stick with Java for my own programming experience, since I'm not that good in C++ and my project was to be honest, very simple. As you know, Java is a very spread / wide around the world, tons of docs and libraries ready for you to use, Qt is faster, but you will need to get your hands dirty to do the job. If performance is your goal, Go Qt. Or redesign your application to hava Java/Swing GUI and C++ programs server side. Anyways here's the link.
http://turing.iimas.unam.mx/~elena/PDI-Lic/qt-vs-java-whitepaper.pdf
Java/Swing may be appropriate for certain projects, especially those without GUIs
or with limited GUI functionality. C++/Qt is an overall superior solution, particularly for GUI applications.
Using C++ instead of Java improves CPU performance, sometimes as much as 10-30%. However using multiple threads also increases the amount of CPU you have available. Given using multiple threads didn't help, I suspect your bottleneck is not in CPU and switching language is unlikely to help.
Where C can help is in programming graphics cards, e.g. CUDA. You can get dramatically faster results for certain types of problems using a high performance processing card. http://www.nvidia.co.uk/object/cuda_home_new_uk.html There are JOCL libraries to use CUDA from Java, but the code which does the real work is in a C-like language.
I suggest you determine where your bottle neck really is as switching to C++ will not increase the size of your cache, your memory bandwidth, IO bandwidth or the size of your main memory.
I just read this (one) study in which Tomcat under Linux outperformed Windows.
From your experience, is this generally true? Any deep reason that could explain the performance difference?
I don't thing such benchmarks can be so informative, then this one is 4 years old.
By the way these differences usually reside in certain choices related to how the operating system manages memory, cache and threads..
I take any benchmark with a grain of salt. It's possible to game any comparison.
I find that one key is to try and spot any bias that the person doing the comparison might have. There was an infamous comparison of the Java EE Pet Store done with .NET several years back. The group doing the study had been paid by Microsoft. They didn't do all they could to optimize the Java EE solution, putting it in a bad light. The results were discredited as a result.
Does WebPerformance.com have any Linux bias?
If not, there are a lot of factors that enter into such a result. I'd compare all of them carefully, and try to see if I could spot anything important that might have been left out.
Few points (mostly speculation):
Tomcat developed by FOSS on FOSS software, so it is reasonable that it would perform better on FOSS software.
Linux is better operating system ;-)
Generally. It depends on fine tuning experience... If you know windows well you'll tune it better for windows and if you know Linux better then...
I'm considering opening up a project to create an i-phone virtual machine for android 2.0 (read motorola droid) before i do so i have some questions:
Does one already exist that i just missed?
Can the the Droid's Arm Cortex A8 down-clocked to 550MHz (thanks wikipedia) handle an I-Phone abstraction layer?
Performance wise the best thing to do is write the app in C++, but for the health of the system, would it be better to put the iphone vm on top of the dalvik vm? Which approach would be better and why.
Does one already exist that i just
missed?
No.
Can the the Droid's Arm Cortex A8
down-clocked to 550MHz (thanks
wikipedia) handle an Iphone?
No, but the CPU is not strictly the issue.
Performance wise the best thing to do
is write the app in C++, but for the
health of the system, would it be
better to put the iphone vm on top of
the dalvik vm? Which approach would be
better and why.
It is conceivable you could create an Objective-C implementation in C/C++ that could run on Android via the Android NDK, but NDK libraries have limited system access, meaning you would not be able to do much in Objective-C.
It is conceivable that your Objective-C implementation could run as a standalone application on rooted hardware, and therefore have access to more of the system, but then you pretty much aren't running Android anymore.
It is inconceivable to create an Objective-C implementation that will run on the Dalvik VM and have performance similar to a native implementation of Objective-C on the iPhone.
Note that I have not even discussed implementing the Cocoa libraries and such, as I have no idea how you could do that in reasonable time without copyright infringement, which will get you sued into oblivion (see: Apple v. Pystar). The only way to avoid this is a total cleanroom implementation, and the WINE folk will point out how they have been trying to do this for Windows for around 17 years and have had incomplete success.
If your goal is to write applications once that run across Android and iPhone, consider PhoneGap, Appcelerator Titanium Mobile, and similar toolkits.
No
No, not even close
Its moot, frankly regardless to the language you write it in, you won't even get close to a usable speed. I suppose to actually answer the question, as close to the metal as possible. Again, its a fools errand anyways.
I have a request for a contracting gig and one of the requirements in the first draft of the specs says the software (a GUI application for end-users) should run on Win 2000 and Mac OS 7.5. I have no idea why they would want to support such ancient systems, but I guess it leaves me with Java as the only option other than raw C, or doesn't it?
So if it would be Java, are there restrictions on what Java version I can use on those targets?
Also, though it wouldn't be strictly on topic, I'd appreciate comments on strategies for making software run on both targets. Actually, supporing those ancient systems as well as modern ones might even be harder than supporting Mac and Win, right?
As another sideline, I'd also appreciate facts that could be used to talk the client out of this and make him go with OS X and XP. Like "hey, only 2% of all Macs in use today still use OS older than X".
Edit: My main purpose here is to be well prepared technically to negotiate what the specs really should be.
Things like that are often the result of some manager thinking "gee, my aunt still uses OS 9 and I bet, there's people even more old-fashioned, so let's just play it safe and write down 7.5". There's no technical judgement whatsoever involved, and that's OK. It's just that, in those cases, you have to explain carefully what tradeoffs there are and if you succeed, it usually gets you much more realistic specs. It's not even unlikely that they'd ditch Mac OS altogether if they have to bet money on it.
With that kind of specs, if you don't actively help the client reshape them, what's going to happen is, you put the number in the offer that would pay for all the crazy stuff and then yet some, and less experienced competitors won't see all the implications and put a lower number in their offer, get the gig and it all ends in tears for everybody. You can go "heh heh, told you so", but don't get the cash, either.
Edit: Thanks for still posting facts and advice although I already accepted an answer to my original question. I'll keep upvoting that stuff, and it certainly helps. Also thanks for empathizing with me and trying to save me from signing a bad contract! But don't worry, I'm not actually going to code for Mac OS 7.5 ... ;-) Really, really overseeing all the implications would be well out of my depth anyway.
Unless this is a seriously lucrative contract, or you desperately need the money, I'd recommend running away from it as fast as possible. The chances are the client is not only targeting seriously old OS's, but also old hardware. That'll mean you'll have all sorts of problems with performance (for you can bet the entire value of the contract that they want an app with modern features and performance on this ancient kit). It's near guaranteed to end in tears...
The Java Runtime for MacOS 7.x was called Mac OS Runtime for Java (MRJ) and supported at least Java 1.1.8. If my memory servers me right, the Swing implementation was pretty bad - so you would need to use AWT.
At least on the ancient MacOS systems, you will have stability & performance problems. Don't take this contract, this is guaranteed to end in a fiasco.
Unless this is a seriously lucrative contract I would stay away from this one.
I've worked on contracts like this in the past and they are almost always more trouble than they're worth. Whilst I appreciate you are just trying to be prepared, you really need to find out more about why they want to do this - its pretty unusual.
OTOH. If the contract is a big one and they are only talking a couple machines - it might be worth your while to offer to buy and install machines for them!
Coding for an older VM such as 1.1 will force you to code to a lower common denominator and will add considerably to development and testing time - you need to take this into account. The machine will almost certainly be underpowered in terms of memory and cpu.
Win2k will support at least Java 1.4 and possibly 1.5.
It's up to 1.1.8 for all Mac OS Classic (not X)
One useful stat is that about 85-90% of all Macs run OS X 10.4 or 10.5. Most of the other 10% are running older versions of OS X.
I'm not definite on this, but I believe Mac OS 7.5 will only run versions 1 and 1.1 of Java.