Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (517)
Games in Android Showcase (123)
games submitted by our members
Games in WIP (578)
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  
  Why You Might Want To Consider Java For Your Next Project  (Read 5926 times)
0 Members and 1 Guest are viewing this topic.
Offline Corvinex

Senior Duke


Projects: 1


Work Hard, Go Pro.


« Posted 2011-07-07 18:19:32 »

http://www.gamasutra.com/view/news/35700/Opinion_Why_You_Might_Want_To_Consider_Java_AndOr_Clojure_For_Your_Next_Project.php?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+GamasutraNews+%28Gamasutra+News%29

This is an article on Gamasutra, maybe we should back him up the comments have not been too positive.

"Do what you love and you'll never work a day in your life."
Android: Pac-Ball
Web Applet: Virus Effect
Old Games
Offline pitbuller
« Reply #1 - Posted 2011-07-07 18:34:03 »

It's quite odd that he start "I am speaking to anyone but console/mobile/AAA developers here."
Androis is biggest mobile platform now and it's still growing fast. So why rule all mobile developing with Java at start.
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #2 - Posted 2011-07-07 18:54:33 »

A pretty bad article, in my opinion. Mostly hearsay and not very well structured.

See my work:
OTC Software
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2011-07-07 22:35:27 »

Couldn't quite see the purpose to that article.

Cas Smiley

Offline Corvinex

Senior Duke


Projects: 1


Work Hard, Go Pro.


« Reply #4 - Posted 2011-07-08 00:58:10 »

Yeah I agree, poorly purposed. Although he admits in the article that he forgot to mention who he was speaking to:

"... unfortunately, I stupidly left out the real target audience for my article: hackers and hobbyists"

Just thought we should mention some positives. For some reason it was ranked high on Hacker News so it got some views because of it.

"Do what you love and you'll never work a day in your life."
Android: Pac-Ball
Web Applet: Virus Effect
Old Games
Offline Gudradain
« Reply #5 - Posted 2011-07-08 03:29:21 »

When I read the article I felt like the guys writing it just realized a week ago that there was a language named Java...
Offline ReBirth
« Reply #6 - Posted 2011-07-08 04:41:02 »

Not only on Android, Java is also featured on Nokia Qt.

Offline namrog84

JGO Ninja


Medals: 46
Projects: 4


Keep programming!


« Reply #7 - Posted 2011-07-08 05:07:04 »

good intentions for supporting Java

Though I feel like it was written poorly, quickly, and with little actual research or knowledge.


Its unfortunate

"Experience is what you get when you did not get what you wanted"
Offline gouessej
« Reply #8 - Posted 2011-07-08 10:24:55 »

Quote
some tests suggest that Java can actually exceed the speed of C/C++ in certain cases
I have said that for years  Grin

Online princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2011-07-08 11:03:04 »

Quote
some tests suggest that Java can actually exceed the speed of C/C++ in certain cases
I have said that for years  Grin
We do reasonably have to concede though that 99% of the time C++ is considerably faster most of the time. Java 7 will narrow the gap a little more. Riven's sneaky Unsafe code could further narrow it where it counts for games developers.

Cas Smiley

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

JGO Kernel


Medals: 78
Projects: 15


★★★★★


« Reply #10 - Posted 2011-07-08 11:17:22 »

Quote
some tests suggest that Java can actually exceed the speed of C/C++ in certain cases
I have said that for years  Grin

You do realise that the JVM is written in C++, so its odd saying that Java is faster Smiley
Java's main advantage is that you have to work less for better or equivalent results.
Offline gouessej
« Reply #11 - Posted 2011-07-08 12:21:26 »

You do realise that the JVM is written in C++, so its odd saying that Java is faster Smiley
It is not odd as I studied the way of implementing programming languages during my (unfinished) Master degree, I know a bit what I'm talking about. I have read several times some parts of the source code of Java, I noticed that there is some C source code some years ago, I have only noticed some C++ code recently when trying to recompile OpenJDK. Java uses both C, C++ and assembler, I don't understand why it is odd to say that it is faster than C++ as Java is not C++, Java uses these other languages cleverly which explains why several IBM researchers in high performance computations told that Java can be faster than C/C++, especially in terms of speed of allocation and method calls.

Online princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #12 - Posted 2011-07-08 13:08:42 »

Yeah, @kappa's argument isn't a good one really Smiley Though there are other factors such as the GC which are written in C, etc. but indeed, the bytecode compiler produces machine code, it's not C++.

It just doesn't produce machine code that's anywhere near as fast as natively written C++ code does... yet.

Cas Smiley

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 78
Projects: 15


★★★★★


« Reply #13 - Posted 2011-07-08 13:39:05 »

iiii knew that, just testing persecutioncomplex
Offline namrog84

JGO Ninja


Medals: 46
Projects: 4


Keep programming!


« Reply #14 - Posted 2011-07-08 13:39:26 »

I believe Watson, The worlds best Jeopardy player (the super smart conversation AI) was written in mostly Java.

Clearly he is super intelligent and calculating millions of words, tones, emphasis, and other variables all the time at super high speed!


As stated before,  honestly the difference in speed if less than 5% doesn't really matter that much in the grand scheme of things.  You can look at a console for example and see mind blowingly different capabilities within the same system, and it comes down to how much time and effort programmers came to push the system.

And as stated before, even if we stated C++ had a 5% better performance boost naturally over Java.  If you can write the same code in 30% less time(if you take into account the Java is supposed to make things easier for programmers),  that 30% time saved can then be converted into making "better" code and thus end up being faster than C++ given the same time constraints.

And if you are triple AAA big business and a particular form of calculation or method is faster in a specific language, I thought most "BIG BIG Companies and applications/games" usually had programs that utilized several languages at once because sometimes a different languages perform certain task significantly better.




"Experience is what you get when you did not get what you wanted"
Online princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #15 - Posted 2011-07-08 13:42:53 »

@namrog84 - it's more like about 50% not 5% for games, typically.

(I was going to say that this is a problem but really it's only a problem for the sort of games that need to use 100% of what's out there and that's basically AAA titles. And we all know how many AAA titles have been written in Java.)

Also, coding is a rather small part of the development budget these days. Saving 30% off of a mere 10% of the budget is barely worth it considering the huge tradeoffs a studio would have to make to switch to a Java toolchain. A bit of a catch-22 situation unfortunately. But largely brought about by senior Sun mismanagement. There should have been a shit hot JVM on PS3 and indeed 360 and iPhone but they f**ked every one of them up.

Cas Smiley

Offline namrog84

JGO Ninja


Medals: 46
Projects: 4


Keep programming!


« Reply #16 - Posted 2011-07-08 16:25:14 »

is it really a 50% performance increase? I didn't think it was nearly that high? (Java isn't that bad? is it )
What about non games?



Yeah I know a lot goes into content development, from level design, balancing, art, media, etc...
Sad

I was always quite discouraged that they didnt manage to get a JVM on the 360 or ps3 Sad

"Experience is what you get when you did not get what you wanted"
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 823
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #17 - Posted 2011-07-08 16:39:51 »

is it really a 50% performance increase? I didn't think it was nearly that high?

Lack of SIMD really hurts. On 'old' CPUs the performance difference was factor 2, now it's factor 4, as modern CPUs don't spread SSE2 operations over two cycles anymore.

When doing vector math, 90% of the CPU time is still spent in 0.5% of your code, and that 0.5% will not even be remotely as fast as hand-optimized assembler -- 50% doesn't even come close in *that* part of your engine.

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

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #18 - Posted 2011-07-08 17:01:21 »

Overall yes I'd say Java is about half the speed of C++ for games in typical situations, and that doesn't even take into account the lightning fast startup time of native code (which believe me does have quite an effect on perceived performance). Some sorts of stuff as Riven points out are tragically slow in Java, unfortunately the kinds of stuff that are very common in games programming. Some serious effort in SSE optimisation for the Sun JVM wouldn't go amiss. The other big bottleneck is bounds checking.

Cas Smiley

Offline tberthel
« Reply #19 - Posted 2011-07-08 17:03:01 »

I can get 60 fps on 30 dollar hardware new for 2d action games and next year it will be 25 dollars and 12 months from now it will be 20 dollars.

So Java is plenty fast.

Online princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2011-07-08 19:08:53 »

Well, it's fast enough for the piddly things we want to do, but I can't see myself writing anything utterly mind blowing any time soon Smiley

Cas Smiley

Offline philfrei
« Reply #21 - Posted 2011-07-08 22:33:33 »

I went to the Java 7 release meeting yesterday. (Did they show the audience in the live stream? I was the fellow with the plate of food on my lap in the first side row. Cheesy)

The new File system is touted to be an order of magnitude faster, if I read the charts correctly.

There are some cool things like fork/join (to send/split a task into two or more threads presumably on their own cpus) that also could lead to significant pickups in performance.

So we could be seeing some improvements, not that what we have is at all bad.

The estimation that Java is 50% slower than C++ seems overly pessimistic to me.

"It's after the end of the world! Don't you know that yet?"
Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #22 - Posted 2011-07-09 07:57:18 »

The biggest difference between C++/Java and even C and Java is the *programmer*. The Langs are close enough for the most part that its the quality and experience of the coder that makes the most difference. At whcih point one just needs to ask which lang lets the coder work on the important part of coding rather than tedious details. IMO all 3 languages suffer from forcing to work too much on tedium. But java is better if only because it has a half decent standard library.

Seriously after 15+ years of internet and C++/C doesn't have sockets as as part of its standard library? What are they thinking?

Of course there are exceptions to all this and sometimes java is not the right tool. But may times neither is C/C++.

Yes i put C/C++ together because there are lot of coders who just won't code C++ and you are left with C looking C++. At least in commercial circles.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline Spasi
« Reply #23 - Posted 2011-07-09 12:28:47 »

I disagree with most of the above. First an interesting link:

The Ubiquitous SSE vector class: Debunking a common myth

The answer to the question "Is Java as fast as or faster than C++" is: it depends. On so many factors actually that there's no point trying to do any general comparisons, outside the context of a real-world application.

Memory access is so much more expensive than most calculations that happen in between. This is a fact that applies to 99% of the code in 99% of the programs ever written, it's true for both CPUs and GPUs and will be true until a radically different micro-processor architecture is invented. There's only one way to get around this bottleneck and that's by designing your data structures and memory access patterns in a way that gives compilers and, more importantly, CPUs themselves (x86 CPU pipelines do this independently of whatever language you've written your program in) an easy way to identify what you're trying to do. The first obvious benefit is that you properly utilize the memory caches and the second is the memory prefetching that can happen, when the access pattern is clear enough to be predictable. As a side note, console CPUs don't have the necessary circuitry to detect access patterns, that's why programmers need to use compiler hints to make it happen (another reason we haven't seen Java on consoles so far).

This basically boils down to linear data structures and simple loops. That's why JVM engineers keep asking people to write the simplest code possible. Simple == optimizable and this has nothing to do with Java. None of the above is any more special in Java than in C++. It just so happens that software people writing in C++ usually have the experience to design their code with all that in mind, whereas Java programmers tend to ignore it. Data-orientation is much more important than object-orientation and not only for performance. It's much easier to parallelize a simple loop on a simple data structure (e.g. with fork/join), than a calculation happening on a complex object graph.

Bounds checking is also dirty cheap on x86. For the same reason actually, the array memory access is orders more expensive than the conditional jump before it, which the CPU has already predicted will not happen for the next X iterations (that is, it's almost free, simple noise compared to the rest of the code). Some Java programmers think "crap, it's bounds checking again, I need to fix this" and they go ahead and redesign their code. Which is good! Bounds checks occur on every iteration when the JVM cannot understand your code.. which is basically when you've written cache unfriendly code. "Fixing" the bounds checks doesn't yield a performance increase because you've removed the conditional jump, it's because you've started utilizing the precious cache properly.

Finally, because always "it depends", when you've tried everything and you're sure you have a bottleneck than can't be fixed any other way, there's a thing called OpenCL available. It's here and it works (heck, it's already in browsers too). There's no reason to go down to JNI and assembly hacks to get top of the line performance, when it's so easy to use OpenCL through Java. All you need is LWJGL and Riven's magic mapped objects. Wink

Btw, AAA titles means amazing graphics (= GPU, the expensive engines do their best to minimize CPU usage - few draw calls etc) + physics (= GPU, else you get the simple version of it) + absolutely brilliant pre-baking of game data (= offline work, performance doesn't matter). Most games use scripting for their game code too. Again, nothing to do with language or performance, but it has to do with the platform. Java isn't an option because it cannot run on consoles, not because of the few disadvantages it has compared to C++.
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #24 - Posted 2011-07-09 22:40:17 »

Brilliantly worded, Spasi. That's the article should have said.

See my work:
OTC Software
Offline Spasi
« Reply #25 - Posted 2011-07-10 11:43:39 »

Some resources for people that want to know more about data-oriented programming:

Pitfalls of Object Oriented Programming (pdf)
Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP)
Data-Oriented Design Now And In The Future
Data-Oriented Behavior Tree (heavy read, especially the 3rd part, but really useful insight on the process of going from OO to DO)

These should get you started, google is your friend after that. It's kind of a hot topic for game devs (and, not only) lately and there's plenty of info available. I've recently implemented a benchmark to test the theory behind the first article, mainly to see the effects it would have to the way code is written. The result was much much better code clarity; in the OOP case in order to have a complete understanding of what's happening you need to navigate the object graph, jump from method to method etc, it's really taxing on your short-term memory even with good IDE support. In the DOP case, the code is right in front of you, as a series of simple steps. As for performance, close to 3x faster for the Java implementation, 40x (!) for the OpenCL implementation (including the GPU readback).

Note that neither me nor the people that wrote these articles suggest that OOP is inherently bad. It's just that data should always come first. Design for data, not code. Have the code go to the data, not the other way around. It's simple and applies equally well to both OOP and procedural programming.
Offline avm1979
« Reply #26 - Posted 2011-07-10 21:11:58 »

This is really, really interesting - thank you for posting it.

A question - suppose you're writing a particle system in a data-oriented way. So among other things, you're storing lots of x,y coordinates that you then plan to iterate over.

There are quite a few ways to represent that data:
1  
2  
3  
4  
5  
float [] coords; // x, y -> coords[i], coords[i+1]
float [][]coords;
Vector2f [] coords;
LinkedList<Vector2f> coords;
ArrayList<Vector2f> coords;


It seems pretty clear that the 1-dimensional array is the best way to go, but are the other choices still beneficial in terms of utilizing the cache well and allowing prefetching to happen (incidentally, what is trying to figure out the memory access pattern to prefetch - the jvm when it's compiling into native code, or something much lower-level?)

It seems like having an array or even list of objects would still be ok as long as they are allocated at about the same time, and thus probably contiguous in memory (can you count on the JVM to do that?). I guess that would break down when particles expire, and new ones get allocated elsewhere, while in the array case it'll stay contiguous. But, you could use pooling for the objects.

Am I thinking of this the right way? Is it mostly about keeping data in a contiguous chunk of memory, so that when a page is loaded into the cache, you get as much useful data from it as possible?

Online princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #27 - Posted 2011-07-10 21:51:42 »

I wonder what they did in JDK 7 that made my sprite engine so much faster - word has it they removed rather a lot of bounds checking though. So the noise argument may be true to some extent with the very latest chips and JDKs but everywhere else ... when you do something 100,000 times a frame and it's twice as fast in C++ ... there we go.

Cas Smiley

Online princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #28 - Posted 2011-07-10 22:05:14 »

The DOP way of doing things is so right though (if I recall correctly the PS3 absolutely forces you to think in terms of shoving data through it in this way). Java doesn't really make it particularly easy though Sad I hope that Riven's hackery will make it somewhat more viable.

Cas Smiley

Offline Spasi
« Reply #29 - Posted 2011-07-10 23:43:07 »

It seems pretty clear that the 1-dimensional array is the best way to go, but are the other choices still beneficial in terms of utilizing the cache well and allowing prefetching to happen (incidentally, what is trying to figure out the memory access pattern to prefetch - the jvm when it's compiling into native code, or something much lower-level?)

For such a simple example, float[] would be best, followed by float[][]. Note that the 2D array should be float[2][count] and not float[count][2]. For anything more complex, I'd use Riven's mapped objects for good performance and nice code. Without it you'd have naked data in arrays and even though performance would still be great, code would be a mess (and very hard to refactor). Especially if you want to interact with GL/CL and you're using NIO buffers instead of arrays.

There are x86 instructions for prefetching in different instruction sets (e.g. SSE has some), but I don't know if the JVM uses them. In any case, x86 CPUs can detect patterns in the instruction stream and do prefetching automatically. I guess this has lots of limitations and prerequisites, which supports the argument for simple loops even more.

It seems like having an array or even list of objects would still be ok as long as they are allocated at about the same time, and thus probably contiguous in memory (can you count on the JVM to do that?). I guess that would break down when particles expire, and new ones get allocated elsewhere, while in the array case it'll stay contiguous. But, you could use pooling for the objects.

Using objects won't work because of what I'm describing here, 3rd paragraph. With the way GC works, there's no guarantee your objects will remain contiguous in memory, even when you're not de-allocating or re-allocating anything. I can't find the source now, but I read recently that JVM engineers have acknowledged this and they're investigating ways to improve it. But honestly, I don't think you'll ever be able to get the exact behavior required, whereas with explicit allocations your data will be contiguous by definition.

An option for more OO code could be to use handles. Instead of references to objects you use references to handles. A handle contains the index where you can find the object data, meaning you have an extra indirection in exchange for potentially cleaner code. This is a good description, a bit C++ specific though.

Am I thinking of this the right way? Is it mostly about keeping data in a contiguous chunk of memory, so that when a page is loaded into the cache, you get as much useful data from it as possible?

Yes. Whenever you access a memory address, you want whatever sits next to it to be what you'll be accessing on the next iterations/instructions.
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.

DarkCart (12 views)
2014-10-31 21:44:48

DarkCart (15 views)
2014-10-31 21:43:57

TehJavaDev (40 views)
2014-10-27 03:28:38

TehJavaDev (30 views)
2014-10-27 03:27:51

DarkCart (44 views)
2014-10-26 19:37:11

Luminem (25 views)
2014-10-26 10:17:50

Luminem (30 views)
2014-10-26 10:14:04

theagentd (36 views)
2014-10-25 15:46:29

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

Norakomi (62 views)
2014-10-16 15:22:06
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!