• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
MasterQ

Java is fast?

111 posts in this topic

Quote:
Original post by MasterQ
I think people need to realize that Assembly, C++, and Java are all COMPILED to the SAME language (machine). This is what makes it possible for java to outperform assembly. It depends on if that java compiler generates better code than the assembly programmer.

So they all use the same language. If the Java compiler is superior to the C++ compiler, then java wins. And vice versa.

Now if interpreted java is used, then it's going to be slower than C++. Also the article mentions the server vs. client JVM. If your using the client JVM it will be slower than C++.

And runescape IS a commercial java game. You can buy a prem account and get extra featrues. They let you play for free to attract customers and end up getting more paying people than if they required payment from the start. Tibia is a C++ game and uses the same business model. The language has nothing to do with it.


then why did you make this topic if you already your answer?
0

Share this post


Link to post
Share on other sites
The question I asked was "Will languages like java, C#, and VB.NET take over the game industry in the coming years?"

I already know that java outperforms C++, but that was not the question really.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by MasterQ
I already know that java outperforms C++


Notice how that benchmark didn't touch java's floating point [wink]
0

Share this post


Link to post
Share on other sites
Quote:
Original post by The Reindeer Effect
JIT code can outperform statically compiled code in certain situations specifically because there is runtime information present...

Not in practice. It sounds cool in theory but it's totally impossible to implement efficiently. They would have to continuously profile the application and recompile. While that's actually possible it adds an overhead that definitely makes it slower than well optimized C++ code. Only in specially constructed 'lab' situations it might outperform modestly optimized C++ code by half a percent.

By the way, it's possible to do a great deal of 'runtime optimization' in C++ as well: Not so long ago I had a significant bottleneck where I had to copy a few million structures. But depending on the operation(s) being performed on them I only needed a few fields. So I wrote a few specialized routines that copied only the needed fields, and used a function pointer to call the specialized routine with minimal overhead. The copying was suddenly about five times faster. Try that with Java! (Note that copying fields in separate loops is not optimal because of cache thrashing).
0

Share this post


Link to post
Share on other sites
Ok, I just hafta chime in here. First of all someone said that assembly is slower than c because c handles scheduling? No, but you were dead on about the assembly programmer needing to know what the hell he's doing, because in that case, C indeed will perform better. Now just to clarify things, i'm going to assume your experience in assembly has been "console" programming. Generally what is done with assembly under windows in the "console" is essentially interacting with emulated BIOS. This is pretty close to how the computer would act when it first starts up (past the bootloader) however, again, its all emulated. Its PROBABLY interpreted by some half ass VM. If you were to compare a perfect C compiler's output with a perfect assembly programmer's code, you should end up with the same results.

OpenGL: Games arent the only applications that use a graphics API. Someone mentioned scientific applications. I'd venture to say that nearly EVERY scientific app uses openGl, along with NEARLY every CAD program. When you're talkign about strictly games, I agree, I do believe Direct3D probably has a majority of the market, but there are other things to consider as well (not to say that CAD apps and scientific apps can tip the scales, I'm just bringing them up)

cheers
-Dan
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Ademan555
Ok, I just hafta chime in here. First of all someone said that assembly is slower than c because c handles scheduling? No, but you were dead on about the assembly programmer needing to know what the hell he's doing, because in that case, C indeed will perform better.

That wasn't what I said (or at least, what I meant. I can't remember what I actually said [wink]).
I was trying to say that if the OP wrote something in ASM, the result would be a lot slower than if he wrote the same program in C.
Of course, C isn't "faster" than ASM. Of course it depends on the exact machine instructions both programs are compiled to. So neither is ASM faster than C.

I was just arguing that it's definitely not true that "low level is faster". Whatever the language, the result is a sequence of machine code. What it's generated *from* doesn't make a scrap of difference. What matters is the resulting code.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by MasterQ
I already know that java outperforms C++...

That's entirely false.

You can rewrite Java and C++ programs to use only the most basic constructs. This way they will both look extremely much like C. The only difference remaining is how that code gets translated to machine code. Java uses an intermediate step, bytecodes that have to be further compiled at run-time, and adds a few security checks even if your code is perfect. C++ translates directly to machine code, and won't add any extra overhead, just exactly the code you wrote.

JIT-code will never win from native code. The run-time compilation takes extra time and optimization isn't a fast operation. C++ can spend minutes on optimization without a problem, while Java only has fractions of seconds to perform processor specific optimization. Else the user will notice the slowdown too much. The end result is that the C++ code will be more optimized, without any run-time overhead.

Additionally, Java does things behind your back that add some more overhead. So there is simply no way it can run faster than C++. Also note my comment above about using runtime information.
0

Share this post


Link to post
Share on other sites
I was a little suprised earlier that even C++ has a runtime, although it's quite smaller than the size of Java/.NET:

http://www.microsoft.com/downloads/details.aspx?FamilyID=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en

The fact is everything you do these days will have some kind of runtime in there, and benchmarks will vary. It's really a good idea to not come to conclusions with Java or whatever because it changes as a fast as computer technology does. At the end, you need to know them all. The question you'll learn later is "is this language needed for this project?" Thus, you'll have to know them all in order to come to that conclusion. Java may be fast enough for project1 but may be horribly slow for project2. Each project varies.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by C0D1F1ED
That's entirely false.

You can rewrite Java and C++ programs to use only the most basic constructs. This way they will both look extremely much like C. The only difference remaining is how that code gets translated to machine code. Java uses an intermediate step, bytecodes that have to be further compiled at run-time, and adds a few security checks even if your code is perfect. C++ translates directly to machine code, and won't add any extra overhead, just exactly the code you wrote.

JIT-code will never win from native code. The run-time compilation takes extra time and optimization isn't a fast operation. C++ can spend minutes on optimization without a problem, while Java only has fractions of seconds to perform processor specific optimization. Else the user will notice the slowdown too much. The end result is that the C++ code will be more optimized, without any run-time overhead.

Additionally, Java does things behind your back that add some more overhead. So there is simply no way it can run faster than C++. Also note my comment above about using runtime information.


Java vs. C++

Or use this link:
http://java.sys-con.com/read/45250.htm?CFID=388847&CFTOKEN=9460D898-B6BB-AC8B-3C74121E272A4D92

In these tests java outperforms optimized C++ even with the initial JIT delay at the beginning.
0

Share this post


Link to post
Share on other sites
yeah, great source for benchmarks "The World's Leading Java Resource", with fun qutotes like:

"Some of the C++ tests would not compile. "I've never been very good at decoding GCC's error messages," he admits, "so if I couldn't fix a test with a trivial modification, I didn't include it in my benchmarks." "

LMAO

And btw, artificial micro-benchmarks are good for absolutely nothing, If you want to show how fast Java is, make some complex application written entirely in Java where the CPU performance matters (so no GPU limited graphics stuff).

Some examples:
Real-time raytracer
Physics simulation with lots of objects ( or something simpler like massive cloth simulation)
etc...

And provide the source of course. If you can achieve good (similar to c++ apps) performance, without sacrificing abstraction ( so no raw byte buffers instead of objects ), THEN people might believe you.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by MasterQ
Java vs. C++

Or use this link:
http://java.sys-con.com/read/45250.htm?CFID=388847&CFTOKEN=9460D898-B6BB-AC8B-3C74121E272A4D92

In these tests java outperforms optimized C++ even with the initial JIT delay at the beginning.

For every fact I think you can find one webpage disclaiming that fact. That doesn't prove (or disprove) anything.
Quote:
The results he got were that Java is significantly faster than optimized C++ in many cases.

I'd like to hear ONE reason why that is even possible. An EXPLANATION, not just a statement.
Quote:
Some of the C++ tests would not compile. "I've never been very good at decoding GCC's error messages," he admits, "so if I couldn't fix a test with a trivial modification, I didn't include it in my benchmarks."

Ok so what we have here is a lame C++ programmer claiming Java is faster? Give me a break. He probably also doesn't know how to turn inlining on or off (to start with).
0

Share this post


Link to post
Share on other sites
And none of the games listed are very impressive. A java "port" of quake2 that take advantage of modern graphics hardware, where the original version was written before the time of GPUs (so not optimized for T&L at all, and probably dont do any batching). Yeah thats a really fair comparison.

Why do java game programmers go on about how great java is for game development, while nobody actually make any modern-looking games? It this just a general lack of good java programmers? Hobby teams can achieve very impressive games when using c,c++ etc, and if java is actually so much more productive, wouldnt similar teams using java create even more impressive games?
0

Share this post


Link to post
Share on other sites
Quote:
Original post by MasterQ
Java vs. C++

Or use this link:
http://java.sys-con.com/read/45250.htm?CFID=388847&CFTOKEN=9460D898-B6BB-AC8B-3C74121E272A4D92

In these tests java outperforms optimized C++ even with the initial JIT delay at the beginning.


Java is not faster than C++, how can it be? C++ can always be optimised down to the fastest code possible, whereas Java is always going to contain extra overhead.

Ignoring the worst Java/C++ comparison page I have ever seen, for any real world application writing it in C++ will almost always produce a faster application than a Java one. In my experience writing graphical applications with Swing always seem to run *painfully* slowly, especially when compared to a C++ version written in QT or something.

I don't mind people discussing how Java can be as fast as a C++ application. It pains me inside however when somebody comes out with a comment like:

Quote:
Original post by MasterQ
I already know that java outperforms C++...
0

Share this post


Link to post
Share on other sites
Quote:
Original post by MasterQ
Java vs. C++

I tried the methcall tests, which they claim is about 7 times faster with Java versus C++.

My results were that the C++ version ran for 7 seconds, while the Java version took 14 seconds, for n = 1000000000 on an Athlon 64 2.4 GHz. I'm actually impressed by that, seriously, but it's still 14 times slower than what they claim. And it makes me wonder how the other tests really compare. Some of them should be more than 14 times slower with Java, using the same math...

The C++ test was built with Visual Studio 2005, default Release build with no extra optimizations! The Java version was built using NetBeans 4.1 and the runtime that came with it.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by C0D1F1ED
The C++ test was built with Visual Studio 2005, default Release build with no extra optimizations! The Java version was built using NetBeans 4.1 and the runtime that came with it.


To be 'fair', you should use the server Java VM, because it is reportedly faster than the client version.
0

Share this post


Link to post
Share on other sites
Quote:
Why do java game programmers go on about how great java is for game development, while nobody actually make any modern-looking games? It this just a general lack of good java programmers? Hobby teams can achieve very impressive games when using c,c++ etc, and if java is actually so much more productive, wouldnt similar teams using java create even more impressive games?


I believe that is because most people is worried about getting a job in the industry. Java developers usually have a normal job and program games in their spare time.

I really believe Java is a better way of developing software in this current point in time (things may change in the future) because it provides a complete environment: excellent tools, an impressive standard library which is 100% sure to be found in all platforms that runs a JVM, loads of open source software, etc.

My personal opinion regarding game programming is that in a more dynamic environment like the JVM we can move on from the "engine" paradigm (I'll build ALL you will ever want for programming a game) to a more service oriented paradigm.

This is not putting functions in DLLs, this is providing self contained services.

This is the advantage of Java that can be used in game programming, and I'm doing it in my spare time.

PS.: Please don't come with "we can do it in language X", you can do it in assembly if you want, that's not the point. The point is that in Java we can explore its technological characteristics in game development. Instead of being "as fast as C++" we should use Java by its own merits.
0

Share this post


Link to post
Share on other sites
Arguing about the speed of a language (rather than the code) is like arguing about the speed of a road (rather than the car).
0

Share this post


Link to post
Share on other sites
But both the performance and code associated with java are lackluster ;)

*No const modifier.
*No operator overloading (except for the String class, which in itself should convice you that the language is really badly designed).
*Really bad support for generic programming (cant use it with primitives, generic classes storing different object types are actually same type etc).
*No support for call by reference on primitive types, so you need to wrap everything in objects.
*Lots of calls to new (like initializing an array, where you need to loop and use new afaik).
*Only very recent support for enumerations and not very flexible compared to c++ afaik ( I like to use enumerations when indexing arrays, makes everything much nicer to read and easier to comprehend).

I could go on...
0

Share this post


Link to post
Share on other sites
And the design of the language largly dictates the performance you can get, since it influences the programming style and the possible optimizations.
0

Share this post


Link to post
Share on other sites
Hi,

There are many claims flying around this topic. Figured it is time to add my own!

- Java is easy to reverse engineer

It is true Java Bytecode is easier to reverse engineer but Bytecode Obfuscators exist which make this a lot harder. Really good Obfuscators can even reduce the size of the Bytecode and make it more efficient.

- Java is easier to program

Studies (IDC 1998) have shown using Java as opposed to C++ resulted in a 25% overall time/cost saving which is about a 30% productivity increase.

- Java is faster!

As others have pointed out it can be, but generally is not. The newer JVMs are ridiculously clever using hotspot and JIT compilation on Bytecode. The real benefit comes because the JVMs are able to perform optimisations that could never be performed at compile time.

"You don't have to search through too many blogs or Slashdot postings to find confidently worded statements like "Garbage collection will never be as efficient as direct memory management." And, in a way, those statements are right -- dynamic memory management is not as fast -- it's often considerably faster."

http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html


- Chris

0

Share this post


Link to post
Share on other sites
Anybody can write "a program" that runs faster in Java. Give them enough knowledge and they can probably write a program that runs faster in Python than in C++! For example, overuse of "new" in C++ is bad, but it is optimized in Java and other languages that require constant use of it.

The question isn't whether or not you can run some piece of test code faster in Java, it's whether or not you can make some real-world app in both highly optimized Java and highly optimized C++ and benchmark the two together. Of course, the only people who would waste their time doing that are the Java-heads, and they wouldn't do it because it would prove that C++ is faster.

There is no question: C++ has NO overhead. The JIT compiler and runtime environment of Java is overhead.

Java users argue that the JIT compiler allows the program to optimize for the particular machine when it compiles. However, this optimizing is again more overhead. In C++ you can statically optimize for a particular machine at compile time (run different code paths on your assembly code for different processors) which has NO overhead.

Anybody can build a statistic. That doesn't make it true.


Note: Speed is not everything. My most recent game project was written in Java (for the Processing environment), both for web support and ease of development. It's just NOT faster.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
But both the performance and code associated with java are lackluster ;)

*No const modifier.
*No operator overloading (except for the String class, which in itself should convice you that the language is really badly designed).
*Really bad support for generic programming (cant use it with primitives, generic classes storing different object types are actually same type etc).
*No support for call by reference on primitive types, so you need to wrap everything in objects.
*Lots of calls to new (like initializing an array, where you need to loop and use new afaik).
*Only very recent support for enumerations and not very flexible compared to c++ afaik ( I like to use enumerations when indexing arrays, makes everything much nicer to read and easier to comprehend).

I could go on...



* final acts same as const when applied to fields.
* operator overloading was left out on purpose to make reading code easier. True this means more code is required but it is also true java code is easier to read.
For example if had class called Person. What would new Person() += new Person() be doing?

* generics were added to Java 5
* autoboxing and unboxing was added to Java 5
* enums in Java are just classes meaning they can contain methods


- Chris
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Konfusius
To be 'fair', you should use the server Java VM, because it is reportedly faster than the client version.

You're right, it's sigificantly faster. I got 34 seconds for 10 runs. Not bad at all.

For the C++ version I enabled some relevant optimizations and made some trivial code changes (without changing the actual behaviour of course). I got 28 seconds without effort.

Going back to Java I tried the same changes there (basically inlining everything). I got 29 seconds. Nothing short of impressive. Still not beating the C++ version by 7x though.

I think this actually tells the whole story. Java can't beat well optimized C++ code. It does have an impressive compiler (actually the server runtime) though, that turns shitty code into something that gets fairly close to the optimal. With bigger projects I wouldn't expect it to perform this well though. This particular test just happened to generate fast code. I am absolutely sure there is no test where C++ is slower after optimization, and I'm also sure there are tests where Java runs at a fraction of the C++ speed without any optimization being able to help it (unless rewriting the compiler/runtime).

The bottom line is that if you want optimal performance there's nothing better than C++ (where you can access all low-level constructs and even assembly). Java is nice for tools but it's not the language to write Doom 4 with.
0

Share this post


Link to post
Share on other sites
Quote:

* operator overloading was left out on purpose to make reading code easier. True this means more code is required but it is also true java code is easier to read.
For example if had class called Person. What would new Person() += new Person() be doing?


I don't want to get into the Java VS C++ "Which is better" argument, because neither is "better" (though my above post made it obvious what I think as far as speed goes).

However, only an idiot C++ programmer would make Person() += new Person(). This is dumb code, and I'd slap the programmer.

However:

Point2D p1(1.0f, 0.0f);
Point2D p2(0.0f, 1.0f);
Vector2D v1 = p2 - p1;

Is much more intuitive to read than:

Point2D p1(1.0f, 0.0f);
Point2D p2(0.0f, 1.0f);
Vector2D v1 = p2.minus(p1);

Not a huge difference, but it's a simple example. Operator overloading can make code much easier to read if you don't have a moron behind the wheel. Of course, a bad programmer can make a simple function call seem obscure...

0

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
But both the performance and code associated with java are lackluster ;)

*No const modifier.


Agreed

Quote:

*No operator overloading (except for the String class, which in itself should convice you that the language is really badly designed).


Strings always get special treatment. In c++ they just get less. You are allowed to do things like char str[] = "..."; which isnt entirely consitant either.

I have to say the only operator overload I make use of frequenlty is operator[] and operator= and operator==. I would like if the comparison and indexing operators were available in Java, but alas...

Quote:

*Really bad support for generic programming (cant use it with primitives, generic classes storing different object types are actually same type etc).


I believe java 1.5 goes some way to improving this.

Quote:

*No support for call by reference on primitive types, so you need to wrap everything in objects.


Agreed, although I have never really needed to do this in java (Disclaimer: I use java at college, I use c++ myself, so yes I am aware as to how it can be useful, and no the variety of programs I write in Java isn't much )

Quote:

*Lots of calls to new (like initializing an array, where you need to loop and use new afaik).


Agreed. But I have heard that in GC langugeas calls to new are virtuall free, so its just a syntactical thing.

Quote:

*Only very recent support for enumerations and not very flexible compared to c++ afaik ( I like to use enumerations when indexing arrays, makes everything much nicer to read and easier to comprehend).


I haven't used enums in Java, no comment ( although I'm suprised that you cannot use them for array indexing ).

Quote:

I could go on...


I will for you :)

*No Destructors!

This makes me sad. I have heard of finalisers and have also heard that they are not guarenteed to be called for some reason. Please, someone prove me wrong about this!


But enough of that, I'm in 2 minds over Java. I thinks its quite nice in some ways, and that many of the points most frequently made against it are not important enough to be considered in a language vs language discussion. I mean really most of them boil down into "why isn't Java c++" anyway.

But in general, most of the games I make could be made equally in Java or c++, and the end user probably wouldn't notice the difference. It could be easier on me ( in terms of dev time ) but I woun't make the switch.

Almost 2 years of c++ and I'm already stuck im my ways [grin].

Someday I will look at what c# can offer me, but not soon. Maybe when it has better cross platform support.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0