• 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.

Archived

This topic is now archived and is closed to further replies.

Thaynx

[java] Java Speed tests

9 posts in this topic

OK, to all of you that keep singing the party song about java will always be slower that c++ because it is not compiled code, stuff this in your compiler! Here is a site that did some serious speed comparisons with matrix math. http://www.intergalact.com/java/speedtest/speedtest.html (I would say that that is a good testing ground) and the following is the results! Matrix inversion Compiler/runtime N = 50 N = 100 N = 150 N = 200 MS VC++ 4.0 0.88s 2.97s 8.57s 20.49s MS J++/MS Jview 0.33s 2.31s 6.7s 15.65s Cafe/Cafe Java 0.55s 3.24s 10s 23.07s Sun Javac/Sun Java 4.51s 32.03s n/a n/a Matrix multiplication Compiler/runtime N = 50 N = 100 N = 150 N = 200 MS VC++ 4.0 0.16s 1.2s 4.34s 12.36s MS J++/MS Jview 0.16s 0.88s 3.18s 9.61s Cafe/Cafe Java 0.22s 1.37s 4.99s 14.28s Sun Javac/Sun Java 1.86s 15.1s n/a n/a For the people that sing the party line (and the ones that are praying for better performance) here is great news (or bad, depending on how you look at Java), the new generation JIT compilers are getting great performance! This test didn''t even use the fastest JIT! Granted, the graphics speed may not quite be there, I will concede that (for now). But by the time we start releasing our games (year or two from now) the added machine speed and better JIT''s will more than make up for the that. Happy Java programming! If you can''t win, make sure the one that beats you breaks the record!
0

Share this post


Link to post
Share on other sites
Good, I think it will happen in a year when Java becomes faster than C++, See? Java is developed by Sun and it is still going on AND it is multiplatform language. C++ is developed by many companies like Microsoft and Inprise, what makes it interesting is that C++ syntax and basic features won''t change(much) anymore. I would say that Java''s development is just in the beginning let''s say 10% done. When Sun replaces AWT components with Swing, I mean good and fast Swing Java''s speed increases too. When Java is faster than C? I don''t know, but I''m sure that it will happen.

Time comes, time goes and I only am.
0

Share this post


Link to post
Share on other sites
Wow hey, those numbers are only 4 years old. If that guy could write working Java code I would run the programs now and see what the new numbers are (J++ hasn''t been faster than sun''s reference for quite a while now).
0

Share this post


Link to post
Share on other sites
After reading the home page, I think that the results should be taken with some reservation.

1. The most important is already noted on the page itself, namely that the numbers are achived using non optimized debug versions of each of the compilers. C++ allows (in the
current compilers with my own tests) much better optimization.

2. The JIT-compilers at run-time normally tries to optimize the code when compiling it to machine code. This gives the Java an unfair advantage.

3. By using native code compilers for Java the speed of Java can be increased somewhat. This has not been done in the test.

I would like to see some newer benchmarks and possibly using optimized code. Is there anybody out there how would like to make some?

The very informal tests that I made myself compared Visual C++ 6.0 and Symantec Visual Cafe 3.0 native code compiler. I cannot find my number data so here is some very approaximate estimation according to my memory.
No I/O was made during the tests.
When there where not set for optimization the tests that I made was from 30% slower to 10% faster in Java. When optimization was enabled then C++ became significantly faster than Java and was about 40%-60% faster.


B.Sc. Jacob Marner
Graduate Student of Computer Science, The University of Copenhagen, Denmark.
http://fp.image.dk/fpelisjac/rolemaker/


0

Share this post


Link to post
Share on other sites
Jim_Ross - I just did the tests myself. With both unoptimized and Java having the debug information the JIT was still twice as fast. With the JVM it was ten times slower (just as expected). Even if you tweaked the C code every way possible, how much better would it get? Maybe twice as fast as the original C code? Well, ok, that means it is as fast as the debug version of the Java!

felonius - I am laughing my head off (and other parts of my body that I won''t mention)!
>2. The JIT-compilers at run-time normally tries to optimize the code when compiling it to machine code. This gives the Java an unfair advantage.
I can''t believe that with your "B.Sc. Jacob Marner
Graduate Student of Computer Science, The University of Copenhagen, Denmark" (from your signature, what ever) that you actually though that, but you actually wrote it for all the world to see! Wah, wah, wah, cry, cry, cry.... I just walked away from my computer, got a cup of coffee, and came back. I thought I might have been seeing things and wanted to give and inteligent person like you a fair chance! But it was still there when i got back! So I have to debunk it. Here it goes.... All the people that have been slamming Java for so long keep saying that it will never be as fast as compiled code because it has to be interpreted, so C will always have the advantage. So as soon as that interpretted code is faster, it is an unfair advantage? What in the world are you thinking (or smoking)? You can''t argue it both ways. Each language has its own advantages and disadvantages, each one is the beauty of the individual language. Each characteristic is not "unfair", it is just an advantage. Just as being interpretted was at one time a disadvantage, it is slowly becoming an advantage. Don''t insult our intelligence by throwing a "title" in your signature and then say stupid things. You should be ashamed of yourself.

To everyone else, I am sorry if I came across to harsh (and to the two I raked over the coals) maybe I was too harsh. The problem is that we are in a world where everything is changing and people don''t want to change along with it. People, in a world of rapid developement demands, embrase the good changes!



If you can''t win, make sure the one that beats you breaks the record!
0

Share this post


Link to post
Share on other sites
>"...(and to the two I raked over the coals) ..."

I''m sorry, was I one of the coal-dregged? I don''t understand. If not then please, nevermind.
0

Share this post


Link to post
Share on other sites
To Thaynx,
I think that before you flame people you should take a moment and maybe consider if you have misunderstood something.

I am not against JIT compilers, interpreters or anything like that and I see no principal reason that they cannot be as fast as compiled code.

What I mean by:
"2. The JIT-compilers at run-time normally tries to optimize the code when compiling it to machine code. This gives the Java an unfair advantage."
is that the tests that are used in the samples are using a an unoptimizing debug version of the Java compiler and of the C++ compiler. But when the Java program is run, it is run on a JIT compiler that compiles the byte code to machine code and this compiler is optimizing no matter the optimization settings. This means that you are comparing the speed of optimized Java execution with unoptimized C++ execution. That is unfair.
The test should be optimizing for both C++ or Java or not at all.

If indeed I am wrong in some respect (I am not perfect you know) then flaming is a very childish thing to do. You should rather ask me if a really mean it an correct me if I really am wrong.

Edited by - felonius on May 9, 2000 10:32:38 AM
0

Share this post


Link to post
Share on other sites
I must offer my most humble oppoligies to you two. I took what could have been a very profitable discussion and turned it into a flame. I have been getting an incredible amount of heat over all this and just lashed out at the two of you. I do hope you can see past this mistake and realize my intentions were not to be ugly, but to further the understanding of what I have seen. Please forgive.

If you can''t win, make sure the one that beats you breaks the record!
0

Share this post


Link to post
Share on other sites
The test should of course be performed using optimized C++ and optimized Java. However, the fact that Java can optimize at runtime to the specific platform that it''s running on (using particular processor features etc.) should not be considered an unfair advantage, it''s a feature for JIT compiled languages. In other words, to make the testing fair one should just use the fastest compilers/VMs for both systems.

Btw, I hope you have all noticed that JDK1.3 was released for Windows yesterday. YAY!

Henry
0

Share this post


Link to post
Share on other sites