| View previous topic :: View next topic |
| Author |
Message |
404FileNotFound
Joined: 20 Aug 2005
Posts: 18
|
 Posted: Tue Aug 30, 2005 3:48 am Post subject: |
 |
|
| hmm my laptop does 644 fps on it without even making your changes! (java does 500 fps). It has an ati vid card, maybe that has some influence on it. Oh and after making the changes it stays about at that level but I guess that's quite enough fps already. Anyway thanks for all the effort you put into this and I guess my problems are now gone (Ill let you know what happens when I get back to my parents place this weekend) |
|
| Back to top |
|
 |
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Tue Aug 30, 2005 4:05 am Post subject: |
|
|
| 404FileNotFound wrote: | | hmm my laptop does 644 fps on it without even making your changes! (java does 500 fps). |
Java might do more than 500 fps if you comment out the call to Display.sync in Game.java (you are passing a value 500 to it).
| Quote: | | It has an ati vid card, maybe that has some influence on it. Oh and after making the changes it stays about at that level but I guess that's quite enough fps already |
Perhaps the drivers don't support wglSwapIntervalEXT (i.e. calling it has no effect). |
|
| Back to top |
|
|
404FileNotFound
Joined: 20 Aug 2005
Posts: 18
|
| Posted: Tue Aug 30, 2005 7:31 am Post subject: |
|
|
yep you're right  Now java does more fps than D again, but 740 against 640 in D isn't that much difference. It still amazes me that java can get this much speed with all those JNI calls, you'd expect it to be really slow. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Tue Aug 30, 2005 8:33 am Post subject: |
|
|
| 404FileNotFound wrote: | | yep you're right Now java does more fps than D again, but 740 against 640 in D isn't that much difference. It still amazes me that java can get this much speed with all those JNI calls, you'd expect it to be really slow. |
Well, I wouldn't expect it to be really slow. Even with JNI overhead, Java is quite performant these days. But really, you aren't making so many calls through JNI to make much of a difference. And I suspect the real reason you're seeing such a difference in framerate has to do with HotSpot optimizations on the bits that aren't running on the native side .
Java still has a bad rep because of its early years (I've seen quite a bit of Java bashing even here in the dsource forums and the D NG), but the reality is that the HotSpot runtime compiler has been tuned so well since it was first introduced that it is not uncommon to get better performance from a Java app than that of a natively compiled language like C++. Of course, one can never make a direct comparison in execution speed because a performant Java app is structured differently than a performant C++ app - and that's something these 'performance benchmark' authors generally don't get.
To be honest, I would have put my money on D to have a higher framerate as well. And although now I do believe it's the HotSpot compiler that's making the difference in this case (not sure how aggressive the -O option is for DMD, while HotSpot will take advantage at runtime of whatever features your processor supports), there may be other factors at work here. At anyrate, you're right. At framerates that high (and with code that isn't really doing a whole lot) the difference is negligible. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Tue Aug 30, 2005 12:19 pm Post subject: |
|
|
Well, Java might be competitive in the performance arena these days, but I think it still stinks when it comes to file size, load times, and memory footprint. These details are what cause it to seem slow even now that other optimizations have improved Java's competitiveness. But then again, if you compare it to MS .NET, it ain't so bad... 
-JJR |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Tue Aug 30, 2005 3:15 pm Post subject: |
|
|
What's going to be interesting is Java 6. Currently, there are two seperate hotspot VMs, called 'client' and 'server'. The server VM is not distributed with the JRE, but is included with the JDK. The reason is because it takes much longer to do the runtime compilation than the client VM. It analyzes the running code more thoroughly and therefore can make a Java app seem more sluggish than usual at startup. It is intended to be used server side or for long running programs - hence the 'server' name. But running an app, particularly a game, with the server VM can show dramatic overall performance increases when compared to the client VM.
Supposedly in Java 6 (or perhaps a release or two after), the client and server VMs will be combined in the JRE. When an app starts, it will go through the faster runtime compilation of the client VM, then the server VM will kick in with the in-depth analysis and compilation. It's going to be interesting to see where that goes. I really, really wish we could get something like that in D! Then D would almost be the perfect language in my book. The only thing lacking (again in my book) would be reflection/introspection/dynamic instantiation on par with Java. |
|
| Back to top |
|
|
404FileNotFound
Joined: 20 Aug 2005
Posts: 18
|
| Posted: Tue Aug 30, 2005 3:59 pm Post subject: |
|
|
What I don't like about java is that it's easy to decompile into readable code. Also the GUI stuff still feels kinda slow compared to other languages.
If they can get that gcj thing to work properly with swing GUI's I can see it become pretty popular though. It should fix the slow startup/big memory usage and easy decompilation problems all at once, while also removing the requirement to have a VM installed on the users machine. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Tue Aug 30, 2005 5:03 pm Post subject: |
|
|
| 404FileNotFound wrote: | What I don't like about java is that it's easy to decompile into readable code. Also the GUI stuff still feels kinda slow compared to other languages.
If they can get that gcj thing to work properly with swing GUI's I can see it become pretty popular though. It should fix the slow startup/big memory usage and easy decompilation problems all at once, while also removing the requirement to have a VM installed on the users machine. |
Honestly, I haven't notice a huge problem with the Java GUI's performance, except on older and slower machines. Frameworks like SWT do a good job of solving any lingering problem in that area anyway. For me it's still the slow loading/big memory footprint issue. Like Mike said, it will be interesting to see if Java 6 can improve things.
When I heard about projects that use gcj, I got interested, though... until I noticed that there didn't seem to be any performance improvement with the compiled java code. The executables were still large and slow to load. The interface didn't seem to be much more snappy either. Maybe it was just the particular application, I don't know (the gcj-compiled eclipse project). It made me wonder how big an advantage gcj really was.
-JJR |
|
| Back to top |
|
|
404FileNotFound
Joined: 20 Aug 2005
Posts: 18
|
| Posted: Wed Aug 31, 2005 1:05 am Post subject: |
|
|
| Well gcj is a relatively new project, maybe when it's more mature they'll be able to optimize speed/memory footprint a bit more. Right now the fact that something as big as eclipse works with it is a big enough accomplishment. |
|
| Back to top |
|
|
lgoss007
Joined: 13 Oct 2005
Posts: 20
|
| Posted: Thu Oct 27, 2005 7:59 pm Post subject: continuum? |
|
|
Not on topic, I know... but I didn't know if 404FileNotFound was a regular. Anyways, 404FileNotFound, are you a continuum developer? I have a friend who plays all the time but he really wants a Linux version (I don't play because I don't even have windows  ). |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
