Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
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  
  Blogpost about Java for Game Programming  (Read 4005 times)
0 Members and 1 Guest are viewing this topic.
Offline peter_cc_heil

Junior Newbie





« Posted 2013-05-02 07:43:45 »

Hi there,

I just wrote a small blog post about my experience in working with Java for game programming. It is mostly things I stumbled upon while working on Caromble! for the last few years.
Check it out: http://www.goo.gl/GD7nm

Grts!

Peter
Offline Rakso

Junior Duke


Medals: 1



« Reply #1 - Posted 2013-05-02 08:06:47 »

Intresting read, thank you!
Offline HeroesGraveDev

JGO Kernel


Medals: 269
Projects: 11
Exp: 2 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #2 - Posted 2013-05-02 09:58:10 »

I think this might be the wrong section to post this.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 136
Projects: 4
Exp: 3 years



« Reply #3 - Posted 2013-05-02 16:52:06 »

Yes, articles&tutorials is for tutorials not links to tutorials.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 816
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #4 - Posted 2013-05-03 06:45:11 »

Moved from Articles & Tutorials to General Discussions Pointing

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline gimbal

JGO Knight


Medals: 25



« Reply #5 - Posted 2013-05-03 10:35:50 »

Really nice article focusing on the primary pain points without digressing into off-topic ramblings. I also like the concluding message (at least my interpretation of it): the tool does not do the job, you do.
Offline gouessej
« Reply #6 - Posted 2013-05-05 09:12:55 »

What you wrote about Java and C++ in terms of performance is simply wrong, these are just prejudices. Java has been able to become even in some cases a bit faster than C++ during the last 10 years. Don't blame Java. If you get worse performance, it will be probably mainly your fault. I used a lot C and a bit C++ before switching to Java once for all; if it was really slower, I would still code in C.

Objects pooling is often inefficient since Java 1.4 except in a few very particular cases and I get excellent performances without using Java 1.7 try construct. You advise to call System.gc() between levels which is a really bad idea even in this case, it can cause a lot of troubles in the JVM cache. What you wrote about direct NIO buffers is very incomplete, you must release the native memory they use by yourself if you don't run out of memory on the Java heap, not on the native heap, I already wrote about that in my blog. Moreover, I modified Ardor3D so that you can free the memory allocated by this kind of buffers when used in VBOs in the renderer, you can simply override the method deleteVBOs(final AbstractBufferData<?> buffer) and call it between levels for example.

Offline peter_cc_heil

Junior Newbie





« Reply #7 - Posted 2013-05-06 13:23:24 »

Thank you for your feedback.
What you wrote about Java and C++ in terms of performance is simply wrong, these are just prejudices.
I really didn't want to go into discussions about Java vs other programming languages -there's already enough information to find on that elsewhere. I merely wanted to help people that are (planning to) write games in Java with things I learned along the way.

Objects pooling is often inefficient since Java 1.4 except in a few very particular cases
Agreed, you only need to consider pooling objects once you have problems with garbage-collector-stutters in your game. And even then, you probably only need to implement pooling in a hand full of methods to solve these issues.

I get excellent performances without using Java 1.7 try construct.

We use the Java 1.7 try construct purely for convenience, it makes sure that once the temp object goes out of scope its gets returned to the pool (instead of manually calling pool.push()). This is especially useful when you have multiple return statements within the scope of the temp object.

What you wrote about direct NIO buffers is very incomplete, you must release the native memory they use by yourself if you don't run out of memory on the Java heap, not on the native heap, I already wrote about that in my blog. Moreover, I modified Ardor3D so that you can free the memory allocated by this kind of buffers when used in VBOs in the renderer, you can simply override the method deleteVBOs(final AbstractBufferData<?> buffer) and call it between levels for example.

Well that is all a bit out of scope of the article. The only point I was trying to make is that you need to be more careful with Directbuffers in Java than with ordinary objects; garbage collecting them will lead to stutters in your game a whole lot sooner than with normal Java objects (and they are harder to find with the Java Visual VM as well).

Grts,

Peter
Offline gouessej
« Reply #8 - Posted 2013-05-07 14:32:54 »

In my humble opinion, if you're unable to prove that, don't write than Java is really slower than C/C++/whatever. There is no consensus about that. Doug Lea's (biased?) microbenchmarks and the reactions it caused illustrate what I mean.

Well that is all a bit out of scope of the article. The only point I was trying to make is that you need to be more careful with Directbuffers in Java than with ordinary objects; garbage collecting them will lead to stutters in your game a whole lot sooner than with normal Java objects (and they are harder to find with the Java Visual VM as well).
They will be garbage collected if and if only you run out of memory on the Java heap whereas they allocate memory on the native heap. If you run out of native memory, your game will simply stop working which is worse than some stutters  Sad. You say in your article that we need to be more careful with direct NIO buffers but you miss the main point. Reusing direct NIO buffers is a good idea but it is not enough and it is not always possible. Several JMonkeyEngine and Ardor3D users already ran out of native memory. However, I have to admit that explaining how to handle direct NIO buffers is not easy. I would advise to avoid unnecessary duplication of data (not only in this kind of object) including mesh data (you already wrote that), use slicing when it is possible, favor indirect NIO buffers when direct NIO buffers are not absolutely necessary (for example when they are not used for OpenGL) and to free the native memory they use when you're sure of what you're doing. My last suggestion is very important especially if your game doesn't use a lot of memory on the Java heap.

Offline gimbal

JGO Knight


Medals: 25



« Reply #9 - Posted 2013-05-08 08:47:07 »

The performance in Java depends greatly on how well the compiler and runtime can optimize your code and application. A recent Minecraft fix greatly improved performance because a certain piece of code that was basically executed for every drawn block was head-butting with the optimizer. If the optimizer can do its job well, you might even see more sparks flying than a similar native application.

The question is: how do you make sure you do not get in the way of the optimizer? That requires intimate knowledge I'm afraid, which hooks back into my favorite saying: programming is and will always be hard. You just don't get it for free.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Grunnt

JGO Wizard


Medals: 83
Projects: 8
Exp: 5 years


Complex != complicated


« Reply #10 - Posted 2013-05-08 09:02:11 »

What you wrote about Java and C++ in terms of performance is simply wrong, these are just prejudices. Java has been able to become even in some cases a bit faster than C++ during the last 10 years. Don't blame Java. If you get worse performance, it will be probably mainly your fault.

I don't think he's writing a scientific paper here, just a blog post. If the engineers at Google draw the same conclusions in a benchmark that looks pretty good to me I have no trouble believing that highly optimized (i.e. requiring a LOT of effort and expertise) C++ code can blow Java out of the water in some cases. Here's some quotes from the benchmark which give a great summary IMHO:
Quote
C++ provides the best performance by far, but it requires the most extensive language-specific tuning.
Quote
The algorithm was simplest to implement in Java, but garbage collection settings make both Java and Scala difficult to benchmark accurately.

The most important point I think is: who cares? Maybe for some highly specific cases in which you have to squeeze out every last drop of performance this may matter. But I don't think it matters at all for 99.99% of the games out there, and people should choose the language they like and are most productive with.

Offline gimbal

JGO Knight


Medals: 25



« Reply #11 - Posted 2013-05-08 09:24:52 »

The most important point I think is: who cares?

Excellent question, often goes side by side with "you ain't gonna need it".
Offline matheus23

JGO Kernel


Medals: 109
Projects: 3


You think about my Avatar right now!


« Reply #12 - Posted 2013-05-08 13:29:33 »

I don't think he's writing a scientific paper here, just a blog post. If the engineers at Google draw the same conclusions in a benchmark that looks pretty good to me I have no trouble believing that highly optimized (i.e. requiring a LOT of effort and expertise) C++ code can blow Java out of the water in some cases.

Yay for scala being the second! Smiley

Some quotes from the PDF (and some reasons for learning scala):
Quote
A. Code Size
 [...]
 Code is
 an important factor in program comprehension. Studies have
 shown that the average time to recognize a token in code
 is a constant for individual programmers. As a result, less
 tokens means goodness. Note that the Scala and Go versions
 are significantly more compact than the verbose C++ and Java
 versions.

Also, in the graph the 'scala pro' version (written from an experienced scala programmer, 2nd fastest code in the benchmark) had the least lines of code. Only 297. Almost 3 times less than C++ and almost 4 times less then Java (java was the worst, btw)...

Another interesting quote - not about 'use scala' this time:
Quote
C. Tuning Garbage Collection
 Originally the Java and Scala benchmarks were run with
 64-bit Java, using -XX:+UseCompressedOops, hoping to
 get the benefits of 64-bit code generation, without incurring
 the memory penalties of larger pointers. Run-time is 134 secs,
 as shown in above table.
 To verify the assumptions about 64/32 bit java, the bench-
 mark was run with a 32-bit Java JVM, resulting in run-time of
 290 secs, or a 2x slowdown over the 64-bit version. To evaluate
 the impact of garbage collection further, the author picked
the GC settings from a major Google application component
which is written in Java. Most notably, it uses the concurrent
 garbage collector.
 Running the benchmark with these options results in run-
 time of 106 secs, or a 3x improvement over the default 32-bit
 GC settings, and a 25% improvement over the 64-bit version.
 Running the 64-bit version with these new GC settings, run-
time was 123 secs, a further roughly 10% improvement over
the default settings.

And now - again about scala - that is very, very interesting:

Quote
F. Scala Tunings
 Daniel Mahler improved the Scala version by creating a
 more functional version, which is kept in the Scala Pro
 directories. This version is only 270 lines of code, about 25%
 of the C++ version, and not only is it shorter, run-time also
 improved by about 3x.

And finally, I like the conclusion:
Quote
We find that in regards to performance, C++ wins out by
a large margin. However, it also required the most extensive
tuning efforts, many of which were done at a level of sophisti-
cation that would not be available to the average programmer.
Scala concise notation and powerful language features al-
lowed for the best optimization of code complexity.
The Java version was probably the simplest to implement,
but the hardest to analyze for performance. Specifically the
effects around garbage collection were complicated and very
hard to tune. Since Scala runs on the JVM, it has the same
issues.

Now, thats enough for todays 'learn scala' screaming. Sorry for that, but ... yeah...
Cheesy

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline gouessej
« Reply #13 - Posted 2013-05-08 13:38:41 »

I don't think he's writing a scientific paper here, just a blog post.
It's not a reason to write approximate things. I give some references in my articles.

If the engineers at Google draw the same conclusions in a benchmark that looks pretty good to me I have no trouble believing that highly optimized (i.e. requiring a LOT of effort and expertise) C++ code can blow Java out of the water in some cases. Here's some quotes from the benchmark which give a great summary IMHO:
Quote
C++ provides the best performance by far, but it requires the most extensive language-specific tuning.
Quote
The algorithm was simplest to implement in Java, but garbage collection settings make both Java and Scala difficult to benchmark accurately.

The most important point I think is: who cares? Maybe for some highly specific cases in which you have to squeeze out every last drop of performance this may matter. But I don't think it matters at all for 99.99% of the games out there, and people should choose the language they like and are most productive with.
IBM draws different conclusions in HPC (IBM engineers conclude Java beats Fortran except in scalability) and I have no trouble believing that smart Java code can blow C++ out of the water in more and more cases.

Offline sproingie

JGO Kernel


Medals: 202



« Reply #14 - Posted 2013-05-09 01:36:35 »

An unsafe language like C++, or really more the C parts of it, can technically outrun any managed language runtime like Java, because they can bang on arbitrary memory to write almost any instruction sequence they want, and that's without embedded assembly.  The problem is, how much effort does that take for how much actual payoff, and what are the bugs that are created when the results of the effort aren't 100% perfect?
Offline Oskuro

JGO Knight


Medals: 40
Exp: 6 years


Coding in Style


« Reply #15 - Posted 2013-05-09 09:12:58 »

+1 to what sproingie just said.

Heck, in C++ you can even have assembler blocks if you're that kind of maniac, but again, requires more effort and care on the part of the programmer to avoid making the computer explode.

My personal philosophy regarding languages is that it's not the tool that makes the project, but the programmer's skill.

I'm kind of pressured into that mindset, since in my line of work, I'm actually forced to use specific programming languages for specific devices, and performance is expected to be the same regardless.

Offline gene9

Senior Duke


Medals: 10



« Reply #16 - Posted 2013-05-17 15:37:09 »

I just wrote a small blog post about my experience in working with Java for game programming. It is mostly things I stumbled upon while working on Caromble! for the last few years.
Check it out: http://www.goo.gl/GD7nm

Great article! Both entertaining and informative.
Offline gouessej
« Reply #17 - Posted 2013-05-17 17:21:00 »

An unsafe language like C++, or really more the C parts of it, can technically outrun any managed language runtime like Java, because they can bang on arbitrary memory to write almost any instruction sequence they want, and that's without embedded assembly. 
At the end of nineties, C/C++ fans gave the same kind of arguments to explain that as Java is written in C (Jikes was written in C++), it can't outperform C which is wrong. One of my teacher wrote a program that converted Java (1.3) to C code during his thesis and he only obtained a very small gain (less than 5%) after years of work. Brian Goetz explained that memory allocation and method calls are between 2 and 4 times faster in Java. I really think that almost no human being is able to write a better machine code or assembler code that a compiler like GCC except in particular cases on a small piece of source code and if you really believe you can be more efficient than the JVM, don't use Java. I'm sad to see these kinds of prejudices about Java even here on JGO.

Offline pitbuller
« Reply #18 - Posted 2013-05-17 18:03:10 »

An unsafe language like C++, or really more the C parts of it, can technically outrun any managed language runtime like Java, because they can bang on arbitrary memory to write almost any instruction sequence they want, and that's without embedded assembly. 
At the end of nineties, C/C++ fans gave the same kind of arguments to explain that as Java is written in C (Jikes was written in C++), it can't outperform C which is wrong. One of my teacher wrote a program that converted Java (1.3) to C code during his thesis and he only obtained a very small gain (less than 5%) after years of work. Brian Goetz explained that memory allocation and method calls are between 2 and 4 times faster in Java. I really think that almost no human being is able to write a better machine code or assembler code that a compiler like GCC except in particular cases on a small piece of source code and if you really believe you can be more efficient than the JVM, don't use Java. I'm sad to see these kinds of prejudices about Java even here on JGO.

No one use standard memory allocator for performance critical code and inlined method have zero method call overhead.
Offline Oskuro

JGO Knight


Medals: 40
Exp: 6 years


Coding in Style


« Reply #19 - Posted 2013-05-17 19:17:20 »

I'm sad to see these kinds of prejudices about Java even here on JGO.

And I'm sad about statements like this one, which implies two very wrong things:

  • That people approach languages based on prejudice rather than on rational assessment.
    If actual verifiable proof is presented of one language outperforming the other, then that's that. But way too often I see that proponents of either "side" are careful to ignore or outright dismiss whatever piece of evidence is presented that contradicts them.
  • That participating in JGO somehow makes you part of the "team" and your opinions have to conform to that of others.

Again, programming languages are tools, and discussing their strengths/weaknesses is fine. But when people start taking it personally, then it's time to take a step back.

Offline Cero
« Reply #20 - Posted 2013-05-17 19:42:27 »

Again, programming languages are tools, and discussing their strengths/weaknesses is fine. But when people start taking it personally, then it's time to take a step back.
Well I'm sure you know why is that way.
Basically the name Java has forever been tainted, wrongly so, with poor performance
you shouldn't associate your commercial products, especially games with java, because it can only hurt you - since there is this prejudice

... implies two very wrong things:

That people approach languages based on prejudice rather than on rational assessment.
Well most people are morons and approach everything in life based on prejudice.

Offline sproingie

JGO Kernel


Medals: 202



« Reply #21 - Posted 2013-05-17 19:44:15 »

An unsafe language like C++, or really more the C parts of it, can technically outrun any managed language runtime like Java, because they can bang on arbitrary memory to write almost any instruction sequence they want, and that's without embedded assembly. 
At the end of nineties, C/C++ fans gave the same kind of arguments to explain that as Java is written in C (Jikes was written in C++), it can't outperform C which is wrong. One of my teacher wrote a program that converted Java (1.3) to C code during his thesis and he only obtained a very small gain (less than 5%) after years of work. Brian Goetz explained that memory allocation and method calls are between 2 and 4 times faster in Java. I really think that almost no human being is able to write a better machine code or assembler code that a compiler like GCC except in particular cases on a small piece of source code and if you really believe you can be more efficient than the JVM, don't use Java. I'm sad to see these kinds of prejudices about Java even here on JGO.

Where Java is faster, you can of course implement Java in C and do it that way.  Kinda like how you can build anything out of raw materials, assuming you like working with only raw materials.  Actually, I rather stretched the truth saying that you can emit any instruction in C, but most modern compilers support "rawcall" conventions and of course embedded asm.  Not that you're really writing C at that point, of course.

Jikes is indeed in C++, but is merely a compiler (and an obsolete one at that).  The javac compiler is pure java.  Curiously though, the Jikes Research VM is itself in java (presumably with some native code to bootstrap itself).
Offline Oskuro

JGO Knight


Medals: 40
Exp: 6 years


Coding in Style


« Reply #22 - Posted 2013-05-18 13:19:33 »

Basically the name Java has forever been tainted, wrongly so, with poor performance
you shouldn't associate your commercial products, especially games with java, because it can only hurt you - since there is this prejudice

I'm not disagreeing with that, and I understand it. I just hope we could try to move past that.

Quote
Well most people are morons and approach everything in life based on prejudice.

I know, I know. I'm pretty aware I'm a total idiot myself and will sometimes ramble about things just based on my feelings about it. But hey, being aware of a flaw is the first step to overcoming it.

Online Roquen
« Reply #23 - Posted 2013-05-18 15:35:37 »

Language benchmarks are mostly useful to language implementors.  Let me quote the referenced benchmark: "A team at Google created a "simple and compact" benchmark that didn't take advantage of language-specific features. An algorithm was implemented using each language's "idiomatic container classes, looping constructs, and memory/object allocation schemes.".

"Simple & compact" = can't be testing much.
"memory/object allocation schemes" = using default malloc/free in C++ which is dumb if you want high performance.
"didn't take advantage of language-specific features" = WTF?  The not much tested is totally meaningless.

Every single time I've compared code that I've implemented in Java and C, the C version completely smokes the Java...no contest...not even close.
Offline gimbal

JGO Knight


Medals: 25



« Reply #24 - Posted 2013-05-21 07:16:24 »

Every single time I've compared code that I've implemented in Java and C, the C version completely smokes the Java...no contest...not even close.

In other words: you suck at Java  Grin
Online Roquen
« Reply #25 - Posted 2013-05-21 07:49:08 »

In other words: I'm realistic.
Offline gimbal

JGO Knight


Medals: 25



« Reply #26 - Posted 2013-05-21 12:15:31 »

Switching to serious mode: I can't agree or disagree with you, I've lost exactly what you are referring to. If I compare my C code to Java code that performs the same task, the Java code wins at all times. Because its far easier to read, often more compact and written and debugged in far less time. That's my personal reality.
Online Roquen
« Reply #27 - Posted 2013-05-21 12:54:40 »

Taking a step back, most folks really shouldn't care about the speed difference between C/C++ and Java.  They're smallish linear differences say between 4-20x.  And most people will only see the bottom end of that range because they aren't going to be taking advantage of SIMD and cache oblivious methods (to name a couple).  And more to the point most people don't need to push tons of computations.  And since the speed difference is linear, algorithmic improvement is much more important than the choice of language.  Likewise moving away from single threaded to multi-threaded should give a nice additional linear boost.   Now of course the same changes could be applied to a C/C++ version as well, so it boils down to your point:  which language (or some other choice) can you to get the job done in the least amount of engineering time (and to spec)?  Choose that language and run with it.

What am I referring to is simple.  I only benchmark very expensive computations and C/C++ exposes a closer to the metal feature set which allow for very significant performance gains.  We've covered what Java's (actually the JVM) missing to allow to help close the gap pretty much ad nauseam.  Sometimes some programming trickery (a la Riven's structure library) can help, but mostly we're SOL until some features are added to the JVM.

Not serious mode:  Java?  compact?  And you said that with a straight face?
Offline gene9

Senior Duke


Medals: 10



« Reply #28 - Posted 2013-05-21 15:23:08 »

Every single time I've compared code that I've implemented in Java and C, the C version completely smokes the Java...no contest...not even close.

If I may ask, what were you benchmarking, and where do you think the Java slowdown was? I am highly skeptical of these claims.

If you go http://benchmarksgame.alioth.debian.org/u64q/java.php, C does much better than Java.

Personally, I've ported some signal processing code between C, Java, C#, and Scala. C ran with 20% less time than Java. C# ran much slower than Java (Windows, Microsoft implementation). Scala actually ran ~5-10% faster than Java which surprised me because I thought they would compile to roughly the same bytecode and run on exactly the same runtime.
Online Roquen
« Reply #29 - Posted 2013-05-21 15:50:09 »

And that's what I said.  These benchmarks should java being between 2-37x slower than GCC, and GCC is a hunk of junk.
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.

Longarmx (44 views)
2014-10-17 03:59:02

Norakomi (34 views)
2014-10-16 15:22:06

Norakomi (27 views)
2014-10-16 15:20:20

lcass (31 views)
2014-10-15 16:18:58

TehJavaDev (61 views)
2014-10-14 00:39:48

TehJavaDev (61 views)
2014-10-14 00:35:47

TehJavaDev (51 views)
2014-10-14 00:32:37

BurntPizza (67 views)
2014-10-11 23:24:42

BurntPizza (39 views)
2014-10-11 23:10:45

BurntPizza (81 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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
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!