Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (482)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (547)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  PS3 and GCJ  (Read 7359 times)
0 Members and 1 Guest are viewing this topic.
Offline zero

Junior Member





« Posted 2005-11-27 16:07:41 »

Just a question I'm asking myself for a time:

Would it cost that much effort to write an Java AOT compiler for the PS3 based on GCJ?

If it is possible, we have to convince sony to to that, because porting a java title to Runtime(PC) or vice versa still should be eaiser  then with C++. Furthermore Sony can rely on well tested code (GCJ) for threading, ..

I mean, for PC I prefer a Runtime because it's JIT can optimize the code for individual CPU(s) in the gamer's pc, which even may not available during the engine developing. But to me a runtime for a console seems idioteque, since the hardware never changes and performance counts so much.

Any comments are welcome  Wink
Offline Vorax

Senior Member


Projects: 1


System shutting down in 5..4..3...


« Reply #1 - Posted 2005-11-27 17:04:50 »

The problem is there aren't enough quality games written in Java yet (or companies using Java for games) for the consoles to care to create a VM.  Consider yourself a pioneer Smiley  This generation of consoles probably won't have a VM (I hope I am wrong), but the next might.

Offline zero

Junior Member





« Reply #2 - Posted 2005-11-27 17:36:27 »

Oh, you got my wrong.

I don't want a VM on the PS3, a want an Ahead of Time compilier, like an ordinary one for C++, which compiles Java code to the PS3. Moreover, I am questioning myself, whether the GCJ (GNU compiler for Java) would be a good starting point.

The next point is that i don't believe on of us could the job, because you'll need to have many information on the ps3 hardware. Ideal would be to convince Sony to do that, arguing the Java langauge can solve developer problems, e.g. the threading issues. And perhaps some modificatinos of the well tested and stable GCJ compiler are sufficient.

Btw. I doubt that even the console generatino after x-box360,ps3 and the n-revolution have enough memory, .. to run a VM and and IMHO the benfits of a VM are not that great for consoles, at least in the near future.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Vorax

Senior Member


Projects: 1


System shutting down in 5..4..3...


« Reply #3 - Posted 2005-11-27 17:38:55 »

Oh - I see what you mean - but the same point still applies - not enough games and not enough companies developing with it.

Offline zero

Junior Member





« Reply #4 - Posted 2005-11-27 17:55:30 »

yes you're right! let's conquer the pc-market first, THEN make a strategy for the consoles.  Wink
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #5 - Posted 2005-11-27 18:11:37 »

You will still need some sort of runtime to do garbage collection, will you not?

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 76
Projects: 15


★★★★★


« Reply #6 - Posted 2005-11-27 21:48:59 »

ps3's blu ray drive will have a java vm, but whether software can use it that i'm not sure! also ps3 will have an opengl variation, so a binding to that and the java vm could make an excellent and attactive choice but its all just speculation atm.
Offline Jeff

JGO Coder




Got any cats?


« Reply #7 - Posted 2005-11-28 01:49:49 »

SWp hits it on the head.

The hardest pasrt of implermenting Java in any form is getting an acceptable GC, particularly one aceptable for games work.

Hotspot has *just* reached that point after many years of rocket-science development by soem of the best VM gusy in the business.

GCJ has a crappy basic mark-sweep collector which is totally unsuited to games.

Next?


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Online princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2005-11-28 09:38:23 »

Jet's collector and compiler are pretty much state-of-the-art too Smiley Seeing as Jet can build a dll... presumably... it's a matter of just a bit of jiggery pokery to get it to compile for Xbox, at least?

(Anyone with problems with GC might just consider going back to the Old Ways and using object pools - worked a treat for Flux)

Cas Smiley

Offline zero

Junior Member





« Reply #9 - Posted 2005-11-28 10:38:21 »

Well, don't know much about Java AOTs, I have just mentioned GCJ because its open source and I thought of the  pricing barrier. But if gcj isn't suitable because of the gc and JET is, fine. Anyway, if we can't get a VM for a console, at least the Java language should be there. And at a time when consoles hae enough memory for a VM these will follow.

P.S. I'd be lucky, if anyone can convince me that the perfomance of a VM on the ps3/x-box360/nintendo revolution could ce compared to native code.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2005-11-28 11:33:51 »

Performance of a VM on normal XBox will be identical to any other x86 VM if it uses Hotspot, won't it? But that new PowerPC based one, I don't know... I do know that the VM on my G5 seems considerably slower than the equivalent on Windows but it might be my imagination.

Cas Smiley

Offline zero

Junior Member





« Reply #11 - Posted 2005-11-28 19:28:27 »

Performance of a VM on normal XBox will be identical to any other x86 VM if it uses Hotspot, won't it?

Form the CPU's point of view of course, but a PC often has much more memory. A normal X-Box has 64 MB Total Memory, I doubt that enough for a Java VM and all its optimizations. I assume the same for the ps3 with its 256MB. If the the X-Box 360  has 512MB, as I believe, that should be enough, but Java on a MS console before .NET?  Wink
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #12 - Posted 2005-11-28 19:38:46 »

I do know that the VM on my G5 seems considerably slower than the equivalent on Windows but it might be my imagination.

Try some benchmarks that don't involve UI.

Offline Alan_W

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #13 - Posted 2005-11-28 19:44:13 »

I do know that the VM on my G5 seems considerably slower than the equivalent on Windows but it might be my imagination.

Try some benchmarks that don't involve UI.

The one thing that really crawls on the mac is rendering to a BufferedImage that has had GetRaster applied to it.   I got around 40fps on the PC and less than 1fps ( yes thats 'one' fps)  on the mac. 

Time flies like a bird. Fruit flies like a banana.
Offline danielmd3000

Senior Newbie





« Reply #14 - Posted 2005-11-28 19:52:33 »

I do know that the VM on my G5 seems considerably slower than the equivalent on Windows but it might be my imagination.

Try some benchmarks that don't involve UI.

The one thing that really crawls on the mac is rendering to a BufferedImage that has had GetRaster applied to it.   I got around 40fps on the PC and less than 1fps ( yes thats 'one' fps)  on the mac. 

WOW, that is in need for some serious tweaking  Undecided

VMs are very nice and wend we all have 10+GHz with 1T Ram and no hard discs they will be the only option (a bit of sci-fi Wink ), but One thing that i hate about VMs is the constant tweaking that one has to do  Angry
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #15 - Posted 2005-11-28 19:55:22 »

Yep, The Mac JRE is overly sensitive to the image type,  I think images are converted to a type that is compatible with Quartz, the Apple UI rendering engine. Getting the raster probably means that any sort of behind the scenes acceleration is gone, so if the BufferedImage isn't already TYPE_INT_ARGB_PRE  or whatever it is that the Mac likes, there is probably an ugly software loop that converts it every time it's drawn.

Or was this using a "compatible" image type?  In which case that really stinks.  In ANY case if you aren't happy with that performance file a bug report with Apple.  Apple engineers have stated publicly that Apple uses their bug database as an indicator of what the developers want and they may adjust their priorities accordingly.

Graphics operations in general have always been a sore spot on the Apple JRE... it's actually a lot better now than it was.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #16 - Posted 2005-11-28 21:28:53 »

VMs are very nice and wend we all have 10+GHz with 1T Ram and no hard discs they will be the only option (a bit of sci-fi Wink ), but One thing that i hate about VMs is the constant tweaking that one has to do  Angry

Nothing to do with VM's. Ask any commercial game developer what they spend most of their time doing (answer: constant tweaking to make it work fast on all the different hardware Wink).

One of the advantages to VM's is that you can do this tweaking once only, and because it's a VM all machines will behave that way, instead of doing it once for every conceivable machine.

EDIT: the problem hilighted above is that the VM itself is not being implemented consistenly from machine to machine; that is normally considered a "bug" Smiley

malloc will be first against the wall when the revolution comes...
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #17 - Posted 2005-11-29 03:26:43 »

One of the advantages to VM's is that you can do this tweaking once only, and because it's a VM all machines will behave that way, instead of doing it once for every conceivable machine.

See my post above about the sensitivity of Mac to the pixel format of your images Smiley.   TI think you still have to tweak on multiple platforms even when you have a VM... though it may be less of an issue, since the Sun folks have already done some of that tweaking for you (e.g. enabling certian feturs in the Java2D pipeline based on the available graphcis hardware etc.)

Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #18 - Posted 2005-11-29 03:34:14 »

[...]
Form the CPU's point of view of course, but a PC often has much more memory. A normal X-Box has 64 MB Total Memory, I doubt that enough for a Java VM and all its optimizations. I assume the same for the ps3 with its 256MB. If the the X-Box 360 has 512MB, as I believe, that should be enough, but Java on a MS console before .NET? Wink

64mb would be just fine for "smaller" games (up to the size of Tribal Trouble I would say) and with 256mb you have *lots* of memory. Remember that there isnt an OS which grabs 128mb just for the fun of it.

If the PS3 allows me to run java stuff, I would buy it. Heck... I would even buy a xbox360 under that circumstances Wink

弾幕 ☆ @mahonnaiseblog
Offline Jeff

JGO Coder




Got any cats?


« Reply #19 - Posted 2005-11-29 05:48:18 »

Performance of a VM on normal XBox will be identical to any other x86 VM if it uses Hotspot, won't it?

Form the CPU's point of view of course, but a PC often has much more memory. A normal X-Box has 64 MB Total Memory, I doubt that enough for a Java VM and all its optimizations

COmmon misconception.

To hit equivalent spoeed to a JIT with an AOT you need to bloat the code significantly (basically create multiple evrsiosn of the code  in one executable to cover the same kinds of decisions that the JIT cna make at run time by recompiling to optimize the code paths.)

End result-- for equivalent speed, a VM and JIT is actually singificantly smaller then precompiled code.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #20 - Posted 2005-11-29 06:32:01 »

I think the increased memory requirement of Java has more to do with efficient garbage collection.

Offline zero

Junior Member





« Reply #21 - Posted 2005-11-29 07:33:30 »

Performance of a VM on normal XBox will be identical to any other x86 VM if it uses Hotspot, won't it?

Form the CPU's point of view of course, but a PC often has much more memory. A normal X-Box has 64 MB Total Memory, I doubt that enough for a Java VM and all its optimizations

COmmon misconception.

To hit equivalent spoeed to a JIT with an AOT you need to bloat the code significantly (basically create multiple evrsiosn of the code  in one executable to cover the same kinds of decisions that the JIT cna make at run time by recompiling to optimize the code paths.)

End result-- for equivalent speed, a VM and JIT is actually singificantly smaller then precompiled code.


Sorry, Jeff but you got me wrong. I don't talk about the program size, but the total memory consumed but the porgram and the VM at runtime. Probably swpalmer is right and it mainly has to do with GC.

For example take a look at the following benchmark comparing C++, Java and C#. I don't matter if the overall results are meaningfull (microbenchmarking or whatever), but the mentioned maximum memory usage (Java - 163 MB , C# - 111 MB, Cpp - 98 MB) fits into my experience.
(http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html)
Online princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #22 - Posted 2005-11-29 10:18:47 »

Bah! N00bs! Always looking at the wrong bits! JVM and JIT profiling information == tiny. Graphics & sounds == large. Just one single texture in Ultratron takes up as much room as all the jars combined. Etc. You're going to lose a little bit of space and have to lose a texture or downgrade a sound effect or some music but it's not really significant enough to prevent development of a proper classy game.

Cas Smiley

Offline danielmd3000

Senior Newbie





« Reply #23 - Posted 2005-11-29 15:12:30 »

VMs are very nice and wend we all have 10+GHz with 1T Ram and no hard discs they will be the only option (a bit of sci-fi Wink ), but One thing that i hate about VMs is the constant tweaking that one has to do  Angry

Nothing to do with VM's. Ask any commercial game developer what they spend most of their time doing (answer: constant tweaking to make it work fast on all the different hardware Wink).

One of the advantages to VM's is that you can do this tweaking once only, and because it's a VM all machines will behave that way, instead of doing it once for every conceivable machine.

EDIT: the problem hilighted above is that the VM itself is not being implemented consistenly from machine to machine; that is normally considered a "bug" Smiley

I know i know Smiley

That is why the idea of a VM is so good to me, and if there was faster hardware to make startup time (the areas where VMs still show disadvantages vs Native).

In theory there would be no need to tweak java code, in practice we spend all the time tweaking especially in J2ME, because in practice almost no one respects the standards or implement them correctly and sometimes the standard is not the best solution, also competitive advantage, etc... all make the VMs break the so called java mantra: “write once run anywhere” (yeah right!) code once tweak many is more like it (still it is better than having to write X completely different versions because of hardware) so java did not solve completely the hardware (architecture compatibility) problem with it's VM, it helped but there are still many tweaks that one has to do  Embarrassed the advantage you mention is unfortunately not real in many cases (but we all know this).
Offline Jeff

JGO Coder




Got any cats?


« Reply #24 - Posted 2005-11-29 21:07:29 »

Performance of a VM on normal XBox will be identical to any other x86 VM if it uses Hotspot, won't it?

Form the CPU's point of view of course, but a PC often has much more memory. A normal X-Box has 64 MB Total Memory, I doubt that enough for a Java VM and all its optimizations

COmmon misconception.

To hit equivalent spoeed to a JIT with an AOT you need to bloat the code significantly (basically create multiple evrsiosn of the code  in one executable to cover the same kinds of decisions that the JIT cna make at run time by recompiling to optimize the code paths.)

End result-- for equivalent speed, a VM and JIT is actually singificantly smaller then precompiled code.


Sorry, Jeff but you got me wrong. I don't talk about the program size, but the total memory consumed but the porgram and the VM at runtime. Probably swpalmer is right and it mainly has to do with GC.

No you got me wrong. Thats EXACTLY what I meant.  As a datapoint when Sean compield his game using JET the total in memory footprint (including VM) literally doubled

We got the answer as to why from one of the guys who worked ON Jet.  and its exactly what I described to you.

Clearly you need more detail.  I've explained this before but I will do it once more.

Java, unlike C, is late bound.  This means that most dispatach points cannot be inlined because you cannot gaurantee one and only one destination.  Hostspot does what we call "agressive inlining."  If, at run time, there is one and only one class loaded that can meet the target rquirements we go ahead and inline it.  We then watch what is loaded and, should another be loaded that can meet the requirements we back out the inlining.

Thsi is just one of a number of examples of where we use the abaility to morph code at run-time to improve hotspot performance.

JET achieves similar performacne, but only be precompilign EVERY version and building them ALL into the executable.

here endeth the lesson.


Quote
For example take a look at the following benchmark comparing C++, Java and C#.

Irrelelvent data point.  This has to do with what the *different* envirionments do for you, not the compilation technology.  Java provides a great deal of run-time functionality., This has over-head no matter how you implement it. As SWP points out, howeverm, Its relatively insignificant in today's world.  (About 4K worth for a console hello-world.)  Reflection information can also get quite large, but you can always run an obfuscator if you want that back.

You need to comapre apples and apples.  Go get yourslef a Java compiler and see for yourself.  For any significantly compelx program you will either get slower code, or bloated code.  Its a physical law.


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #25 - Posted 2005-11-29 23:03:58 »

[...]
That is why the idea of a VM is so good to me, and if there was faster hardware to make startup time (the areas where VMs still show disadvantages vs Native).
[...]

Startup time could be masked in this case. Eg you could start showing the loading screen and progress meters (as a static image) prior to actually starting the vm. Once the vm is loaded you can continue to draw it yourself. The felt startup time would be zero then. Wink

弾幕 ☆ @mahonnaiseblog
Offline Jeff

JGO Coder




Got any cats?


« Reply #26 - Posted 2005-11-30 00:10:00 »

In theory there would be no need to tweak java code, in practice we spend all the time tweaking especially in J2ME,

We need to be careful when we talk to seperate J2SE and J2ME as tpoday theya re very doifferent beasts.

Furthermore you need to destinguish between J2ME/CDC and J2ME/CLDC.  What you really are talking about is J2ME/CLDC.

(Technically, J2ME/CLDC isn't even Java by the Java VM spec as floating point i opstional in J2ME but required by the JVM spec.)

The initial crop of J2ME/CLDC devices were probably the worst possible environment to try to run Java code.  No memory, slow processors, highly inconsistant hardwware.  Ina  very real sense, no J2ME/CLDC program COULD be :"signficantly complex" and thus frankly it brought all of the potnetial weaknesses of Java to the fore while removing most fo its benefits.

What J2ME  people generally see still lags behind the desktop badly in Java technology HOWEVER this is changing as those devices grow into the more capable CDC profile. which is much closer to true desktop Java.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #27 - Posted 2005-11-30 00:15:21 »

I don't want a VM on the PS3, a want an Ahead of Time compilier, like an ordinary one for C++, which compiles Java code to the PS3.
I think this is completely against Sun's philosophy and therefore they don't allow it. This is why the only ways to do that even on PC are through GNU open source means. Java doesn't like it.

See my work:
OTC Software
Offline Jeff

JGO Coder




Got any cats?


« Reply #28 - Posted 2005-11-30 00:31:35 »


I don't want a VM on the PS3, a want an Ahead of Time compilier, like an ordinary one for C++, which compiles Java code to the PS3.

Actually, you don't.  You just thought you did.  Cool

 I hope I've helped clear that misconception up.

JK

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline danielmd3000

Senior Newbie





« Reply #29 - Posted 2005-11-30 02:50:21 »

We need to be careful when we talk to seperate J2SE and J2ME as tpoday theya re very doifferent beasts.

Furthermore you need to destinguish between J2ME/CDC and J2ME/CLDC.  What you really are talking about is J2ME/CLDC.

(Technically, J2ME/CLDC isn't even Java by the Java VM spec as floating point i opstional in J2ME but required by the JVM spec.)

The initial crop of J2ME/CLDC devices were probably the worst possible environment to try to run Java code.  No memory, slow processors, highly inconsistant hardwware.  Ina  very real sense, no J2ME/CLDC program COULD be :"signficantly complex" and thus frankly it brought all of the potnetial weaknesses of Java to the fore while removing most fo its benefits.

What J2ME  people generally see still lags behind the desktop badly in Java technology HOWEVER this is changing as those devices grow into the more capable CDC profile. which is much closer to true desktop Java.

CDC or CLDC that's just the profile, the VM implementations are always going to differ (even with almost all companies using ARM processors), the only way to solve this would be to have a downloadable and installable VM for mobile phones (like we have for the desktop VM - JRE), that way one could chose to have the Default (possibly SUN Mobile VM) or the phone brand Mobile VM.

CLDC is here to stay for a long time.... and even wend CDC devices start to overtake, that will only bring more fragmentation to the market, so basically you end up programming like a low-level programmer (the fragmentation problem is never going to go away) for much worse performance, the java high level abstraction brings nothing of value, in fact it only degrades performance, this solution is broken...
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

atombrot (26 views)
2014-08-19 09:29:53

Tekkerue (24 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (13 views)
2014-08-16 06:20:21

Tekkerue (20 views)
2014-08-16 06:12:11

Rayexar (59 views)
2014-08-11 02:49:23

BurntPizza (38 views)
2014-08-09 21:09:32

BurntPizza (30 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38

BurntPizza (67 views)
2014-08-03 02:57:17
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!