Java is fast?

Started by
110 comments, last by rip-off 17 years, 11 months ago
Quote:Original post by Lazy Foo
When the whole industry is taken into account and OpenGL is used widely, "OpenGL is not used widely in the industry" is proven to be false.
Is it? OSX and Linux are sideline players that don't register on the meter. PSX, PS2, and the GC don't use it. (They use similar looking APIs, but those APIs are not OGL.) I'm not up to date on the APIs that the NDS and PSP use, but even if they are OGL, they form a fairly small segment of the market (certainly they're dwarfed by the home entertainment consoles). Neither Rev or PS3 are out yet, so they don't represent the state of the industry now.

In fact, if you run the numbers, you'll find that the PS2 API is the most used, simply due to the sheer vastness of the sales figures and the number of published titles. Again, this says nothing about the quality of their API (and indeed most of the stories I've heard from the trenches are somewhat grim).
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
Advertisement
Quote:Original post by Promit
They use similar looking APIs, but those APIs are not OGL.


If you completely seperate OpenGL ES from OpenGL.

Learn to make games with my SDL 2 Tutorials

Quote:Original post by Lazy Foo
Quote:Original post by Promit
They use similar looking APIs, but those APIs are not OGL.


If you completely seperate OpenGL ES from OpenGL.
The PSX and PS2 do not natively use OpenGL|ES.

[EDIT] I'm seeing vague claims that the GCN does use OGL|ES. Until that claim is verified or debunked, I will make no assumptions either way. Even if it does, it's still not that significant. Furthermore, the lack of mention of OpenGL on wiki's page for Gamecube leads me to seriously doubt that the system uses it.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
There is also an article there, that Java is faster then normal C.
How is this possible? C is very close to assembly.
Also by JavaVM they refer to a virtual machine? How can a virtual machine language can beat assembly machine language?
Is java faster then assembly too?
This sounds redicoules.
What is the explaination that java is faster then normal C?
It's all about the wheel.Never blindly trust technoligy.I love my internal organs.Real men don't shower.Quote:Original post by Toolmaker Quote:Original post by The C modest godHow is my improoved signature?It sucks, just like you.
Quote:Original post by nullsmind
Java is definitely fast for most modern desktop games. For example, here are some links to some great 3d games developed in Java:

http://www.runescape.com
http://www.bytonic.de/html/jake2.html
http://www.oddlabs.com/
http://www.megacorpsonline.com/
http://www.wurmonline.com/
http://www.flyingguns.com/


I think the discussion is not if you can make in Java nineties games with todays hardware, the problem is if you can make today games in Java. Java VM has many advantages and lots of disanvantages. JIT generated code, can be, in some situations as fast or maybe faster than C++ native code, but the cost in terms of launching time is enormous, an gargantuan memory footprint and a lot of time to get a large app running with compiled and optimized code.
I did a benchmark using jake2, comparing native version and java one. Java version used 10 times C memory. Exactly 100 megs compared to 10 megs of process image. And we are talking about a 7-years old game with a really small code if compared with today games. It also lost about a 10 percent of performance of C version, running a GPU constrained game.
Chrome used Java for game logic, i tried it, and the time needed to launch a level was intolerable. I think non compiled Java code wont be ever used to make state of the art games.
Quote:Original post by The C modest god
There is also an article there, that Java is faster then normal C.
How is this possible? C is very close to assembly.
Also by JavaVM they refer to a virtual machine? How can a virtual machine language can beat assembly machine language?
Is java faster then assembly too?
This sounds redicoules.
What is the explaination that java is faster then normal C?


There could be a number of reasons. One could be the codesize, JavaVM bytecode can be smaller compared to compiled C++ code. So there will be a bigger chance for Java bytecode to run out of the processor cache. The same goes for the memory model of Java.
This is a general rule for interpreted code compared to compiled code. In former days the CPU cache was to small, by today this is different.


How do you get the time in miliseconds from the hardware in java?
It's all about the wheel.Never blindly trust technoligy.I love my internal organs.Real men don't shower.Quote:Original post by Toolmaker Quote:Original post by The C modest godHow is my improoved signature?It sucks, just like you.
Quote:Original post by Anonymous Poster
Quote:Original post by The C modest god
There is also an article there, that Java is faster then normal C.
How is this possible? C is very close to assembly.
Also by JavaVM they refer to a virtual machine? How can a virtual machine language can beat assembly machine language?
Is java faster then assembly too?
This sounds redicoules.
What is the explaination that java is faster then normal C?


There could be a number of reasons. One could be the codesize, JavaVM bytecode can be smaller compared to compiled C++ code. So there will be a bigger chance for Java bytecode to run out of the processor cache. The same goes for the memory model of Java.
This is a general rule for interpreted code compared to compiled code. In former days the CPU cache was to small, by today this is different.

I think I know why it might be faster, but I need to check it.
Perhaps the one that checked the performance of tje java application, checked only the time the actuall java code was running.
However, it didnt take into consideration the time the VM code was running and doing all sort of stuff.
However, I need to know how you measure how much time was passed in java.
The code size does not count, because you need to take into consideration also the code of the virtual machine running the java application
It's all about the wheel.Never blindly trust technoligy.I love my internal organs.Real men don't shower.Quote:Original post by Toolmaker Quote:Original post by The C modest godHow is my improoved signature?It sucks, just like you.
Quote:Original post by The C modest god
How do you get the time in miliseconds from the hardware in java?


Use System.nanoTime();

[from the JDK1.5 docs]

nanoTime

public static long nanoTime()

Returns the current value of the most precise available system timer, in nanoseconds.

This method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. The value returned represents nanoseconds since some fixed but arbitrary time (perhaps in the future, so values may be negative). This method provides nanosecond precision, but not necessarily nanosecond accuracy. No guarantees are made about how frequently values change. Differences in successive calls that span greater than approximately 292 years (263 nanoseconds) will not accurately compute elapsed time due to numerical overflow.

For example, to measure how long some code takes to execute:

long startTime = System.nanoTime();
// ... the code being measured ...
long estimatedTime = System.nanoTime() - startTime;


Returns:
The current value of the system timer, in nanoseconds.
Since:
1.5

Quote:Original post by Anonymous Poster
There could be a number of reasons. One could be the codesize, JavaVM bytecode can be smaller compared to compiled C++ code. So there will be a bigger chance for Java bytecode to run out of the processor cache. The same goes for the memory model of Java.
This is a general rule for interpreted code compared to compiled code. In former days the CPU cache was to small, by today this is different.


That has no sense. You will always execute compiled code, thats obvious, bytecode is going to be compiled to native code or interpreted by a native progam, ¿whats the difference?. So bytecode size is not an issue when talking about cache sucess. And please, do not take too seriously all that java vs c++ stuff, usually there is a clear will to alter the benchmark.

This topic is closed to new replies.

Advertisement