Is there any chance, now or in the future there will be a card to accelerate java code? A card might help in certain areas. For example, could you have a accelerated GC? or accelerated bytecode? what about a accelerated hot spot compiler? I know theres a certain limit with what you can do with hardware, but are there any parts at all in java that a company like sun or nvidia can speed up?
Chris 
Sure, it’s called the CPU! ;D
The only real way to use hardware to speed Java up would be a hardware implementation of the virtual machine - that way Java code would be running “natively”. However, HotSpot compilers translate Java into machine code already, so Java is essentially running natively today.
What speed problems are you seeing? Or is this just whimsy?
mainly whimsy wouldn’t it be great if someone could make something as graphical as doom III and have it run fast? Java is already fast for most apps, I guess it will just take sometime for c++ programmers to realise that.
Java’s already perfectly capable of being used to code something exactly like Doom 3, and it has been for at least two years.
Cas
the only prob is the memory usage 8)
Structs! Structs! Structs! Structs!
Actually you could do it without structs, it’d just a little slower and a little fiddlier than the C++ equivalent. But not so much slower and fiddlier that it would make a significant difference.
Cas
[quote]Structs! Structs! Structs! Structs!
Actually you could do it without structs
[/quote]
…and several of us around here (including me) already have, but it’s usually a bitch (of medusa-proportions) to maintain the code :(.
[quote]the only prob is the memory usage
[/quote]
So exactly how much more memory does the java version of Doom III take compared to the C version making the java version unplayable?
I don’t think memory would be a problem at all, because I’m guessing that the majority of memory is eaten by textures of all forms (color, normals whatever). And textures are not managed by the JVM, so the memory hit is the same for C++ as for java.
I’m thinking that any reasonably coded implementation of a BSP tree capable of storing an entire Doom3 level is going to have megs and megs of overhead and of course there’s the 6-8MB JVM overhead and the JITted code overhead but I suppose really we’re talking about, what, 16MB on top of the C version? Woo, big deal. The main problem’s coding the bugger efficiently.
Cas
Sounds like you need a jni interface to a natively implemented bsp… How dirty would that java be? :o
I was thinking the newer engines had moved away from bsp to portals and octrees. I could be mistaken…
BSP, oct-tree, portals & sectors, whatever - you still end up with some kind of tree structure which needs lots and lots of little objects. With C++ each object has zero overhead, but every Java object comes with an overhead (4 bytes if I remember right). When you get tons of objects that starts to add up rather quickly. :o
Could it be done without sacrificeing portability? I just looked at the game Chrome on amazon, and it’s system requirements:
Windows 9x/ME/2000/XP
Pentium II 500 MHz
128 MB RAM
Wheres linux or macOSX? Did the creators of Chrome not write it in 100% pure java? What will stop this from becoming the fate of a game like Doom 3 in java?
[quote] - you still end up with some kind of tree structure which needs lots and lots of little objects. With C++ each object has zero overhead, but every Java object comes with an overhead (4 bytes if I remember right). When you get tons of objects that starts to add up rather quickly. :o
[/quote]
How many objects is “lots and lots”? I mean 10 thousand objects has a 40k overhead in Java - and I think that only applies when you are comparing to C++ objects that don’t have virtual methods and it does not use C++'s runtime type information. (in other words - plain structs)
That’s not a significant overhead really. Specially given that it allows for some of Java’s nice features (polymorphism, runtime type info …).
No, it’s more like millions of objects, and you forget the extreme time it takes to load t’bugger into memory from disk in the first place (try deserializing a structure with 4m objects in it). We must remember the original Quake ran in 8mb of RAM and managed to fit a BSP in there as well as all the textures.
Not to mention that it creates a huge load of references that the GC has to keep track of.
Cas
Chrome is NOT a java game, its a C/C++ game. The scripting language is Java. There is a big difference there.
DP
[quote]With C++ each object has zero overhead, but every Java object comes with an overhead (4 bytes if I remember right). When you get tons of objects that starts to add up rather quickly. :o
[/quote]
The obvious C++ implementation for objects also has overhead on each object; how much depends on the memory allocator and whether the object requires a vtable. While you can get the overhead down to zero (in C++), there is a price for that.
see
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=Offtopic;action=display;num=1055068121
</hijack thread>