@WASD said:
Really? I've heard that Java is slow. Someone said that Java is fast on benchmarks but slow in practice.
Many java applications are slow as the simplicity of java allows complete fools to write (bad) software.
Many java applications are slow as the simplicity of java allows complete fools to write (bad) software.
The best programming language will always be the one you know and likes the most. This is just like asking “What is best, that blond or the brunette over there?” Each one will pick one for a different reason!
@normen said:
Lol, how you compare languages, you can only compare execution time or binaries..? Also was that code JIT'ed? I think this table is very misleading.
Dunno, just heard stuff as I said. Don't remember when and where.
@shirkit said:
The best programming language will always be the one you know and likes the most. This is just like asking "What is best, that blond or the brunette over there?" Each one will pick one for a different reason!
I disagree to an extent. I tried making my own language in java by letting it parse my custom syntax. I got simple if-statements and for-loops working. From my benchmarks it was 100 times slower than Java. Obviously my own language is not the best language however you think of it.
If this is an independent game development project or a hobby project then your biggest enemies will be time and motivation.
Pick whatever has reasonable performance but is something that you like to code and provides many of the building blocks you already need. Otherwise, a month into the project when you are having trouble finding the motivation to work on it, it’s the “still having to constantly look things up” and “still having to hand-implement missing thing X” or the “60th time I’ve hit that same compiler error” that will make you want to go play video games instead. 
Well lets start simple:
Scientific 1#
That benchmark table is not scientific, is the source code shown? Can anyone else reproduce it? NO!
→ A good an acceptable benchmark always gives you the abilities to verify yourself, everything else is just a pile of shit.
Scientific 2#
Can your firend by any way with ANY scientific sources show, that java is slower than other languages? Note due to improvements in Java language, only version 1.6 or newer should cound as not obsolete.
Logic 3#
Rendering and shader processing is gpu only! The only difference there might be is, the used shaders and foraward vs deferred rendering. Defered redering will be integrated in jme however with time. (and probably way before you finish your game in even a rough version)
Programming 4#
Only the game logic and the networki~ng runs in java, this is usually only minimal. The processing amount highers when physics is used. However you can even use the bullet c++ version with jme. (The main advantage here is mostly, that it is faster, but due to newer, better implemented algorithms, than due to language advantages
Big O 5#
If you have a method with exponential cost, like n clients cause n² processing costs, a 10!!! times faster language would ONLY allow you to have around 3 times more player. (at a fixed maximum processing cost) → Even with the show difference of 1.7 , this is nearly nothing in comparison to 10. → It is way more important, that you use good algorithms that scale well, instead of the language choise.
One problem remains:
Sometimes when suing lots of stuff, unreleased direct buffers can be a problem.
There are some ways to handle that problem, but also a alternative way, I will probably try out sometime in the future.
(useing one extreme large direct buffer, and only work with slice to get parts of it, and this way have a own memory management, that is able to free sliced buffers accordingly, this would also reduce allocation and dealloction costs to practically zero)
@Jme Team, I will try this when I have time, it might be worth a shot or?
Hm ? I wonder in the current svn version there is that method neither in jme nor in the lwjgl bufferutils? Did I miss it somehow? (Just updated before posting this, to make sure it’s not there)
Actually the signature is “public static void destroyByteBuffer(ByteBuffer toBeDestroyed)”
@normen said:
Lol, how you compare languages, you can only compare execution time or binaries..? Also was that code JIT'ed? I think this table is very misleading.
That benchmark table is not scientific, is the source code shown?
Yes it is very scientific, it's the only reliable benchmark available on the net, and is very seriously done.
This is one of the benchmarks source used, you can get the sources for all benchmarks in all languages if you look the them.
http://shootout.alioth.debian.org/u32/program.php?test=binarytrees&lang=javasteady&id=1
The reported "Java 7 averaged" program CPU secs and program Elapsed secs are averages that approximate performance after "warm-up".
/usr/local/src/jdk1.7.0_02/bin/java -server -XX:+TieredCompilation -XX:+AggressiveOpts binarytrees 20
More information here :
http://shootout.alioth.debian.org/help.php#java
Yes, i agree, that site looks way more scientific (still not perfect, I miss much information), had not noticed that there is more information via the combobox aviable, still the other mentioned arguments still count.
As we talk about it there are some more or less unusual runtime flags, I cannot see if only these were tested, or all combinations and only the best were used.
for example ->TieredCompilation
Also printcomilation is actiavted, this will slow the jvm minimaly down
XX:+AggressiveOpts is very questionalbe, since it makes no gurantees what exactly it even does. ( suppose usually it would increase performance, but there is no prove that it does or that it does not given)
→ Only linux is tested, what about windows? the oracle jvm might have different performance depending on platform
→ The exact machine specifications! Either I cant find them or this one is quite serious!
→ Is a swap partition enabled or not? (even when ram is free there are situations that do swapping)
Btw is a 32bit or 64 bit jvm used? this one puzzles me a bit.
Don’t get me wrong, I don’t say its complelty crap anymore, its probably the best you can find, I agree, however it states itself, that it does only compare implementations in languages, not languages.
I somewhat wonder how a openjdk would perform (i wonder if it has much different performance).
Last but not least, the Site itself says, don’t jump to conclusions. I suggest to first set a target for your game, (like 300 player per cpu core, and then make specific tests, if this is possible with every framework you might want to use (like physics, network, ect))
Checked this thing out. They see how the different languages stack up when doing normal “traditional” brute-force scientific computing stuff; transcribing DNA, solve the N-body problem, generate fractals, calculate digits of pi etc. Basically the same kind of stuff they use when comparing/testing processors etc.
C++ wins across the board, but interestingly (to me), Java wins the chameneos-redux test pretty comfortably, which is apparently some kind of concurrency test. It also seems to be the test where a jit compiler would most likely win? Lots of weird branching and stuff. It’s based on some sort of finite state machine simulating animal behavior.
Also javascript stepped up and beat c++ with a 4:1 ratio in that regex thing. Hah!
Glad I looked into this. If i have a DNA string i need to transcribe some time, now I know what language to choose.
Between java vs c++ speed. ok java has the same speed, none complains.
But java Jme vs c++ opengl :
a) opengl has native c++ bindings. Jme’s jogl or lwjgl uses jni = [has to copy the method arguments, return values]= slower. if jme uses many small jni methods then it will be slower.
b) same thing for bullet
b1) c++ version uses jni.
b2) java version doesn’t use hardware.
The actual overhead for the JNI calls themselves is tiny compared to the execution time of the actual OpenGL calls, same for bullet. So this is really not an issue.
if people want to create games 10x longer, and have 1% more fps… then ok.
its my opinion reading all the posts.
@oxplay2 said:
if people want to create games 10x longer, and have 1% more fps... then ok.
its my opinion reading all the posts.
Thing is you can't really use the Java code to port to consoles, where you can use the C++ code (at least a part of it) to do so.
@shirkit said:
Thing is you can't really use the Java code to port to consoles, where you can use the C++ code (at least a part of it) to do so.
Sure you can, you can even run a JVM if you like. GCJ compiles all of jME3 just fine.
@normen said:
Sure you can, you can even run a JVM if you like. GCJ compiles all of jME3 just fine.
So you mean I can run a JVM in a PS3? I've never heard of that.
@shirkit said:
So you mean I can run a JVM in a PS3? I've never heard of that.
Sure you can, its just a PowerPC running on a bsd system and as said you can use GCJ to cross-compile (also to PPC) just fine. Or run OpenJDK on any platform you like.
Edit: Ofc you need to buy a developer kit from Sony.
@normen said:
Sure you can, its just a PowerPC running on a bsd system and as said you can use GCJ to cross-compile (also to PPC) just fine. Or run OpenJDK on any platform you like.
Edit: Ofc you need to buy a developer kit from Sony.
Do you have any test cases? Googling a bit and found none. Maybe Sony itself doesn't approves games like that.
sigh Why would they? As soon as you pay for the SDK you are basically allowed to do anything that does not mess with sony’s stuff as long as it makes your game work. How you think UDK compiles its UnrealScript or Unity their javascript on the PS3?