Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Java is fast?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
111 replies to this topic

#21 jfclavette   Members   -  Reputation: 1058

Like
0Likes
Like

Posted 16 April 2006 - 06:35 PM

Quote:
Original post by Lazy Foo
Quote:
Original post by jfclavette
Says who ? Works pretty damn well for me.


Says the industry. You can switch tools whenever you want, but companies can't afford to gamble.

DirectX, Java, you-name-it wheren't adopted overnight. A technology has to prove itself first.


The same industry that just recently switched to C++ (and indeed not completely, as C is still widely used and assembly often rears its ugly head) ? I'll take another barometer thank you.

Plus, the industry don't give a crap about mono anyway. No one even use OpenGL anymore. They're already tied to Windows.

Sponsor:

#22 Lazy Foo   Members   -  Reputation: 1105

Like
0Likes
Like

Posted 16 April 2006 - 06:43 PM

Quote:
Original post by jfclavette
The same industry that just recently switched to C++ (and indeed not completely, as C is still widely used and assembly often rears its ugly head) ? I'll take another barometer thank you.


Which goes to show how resistant it is to change. C# isn't going to have a chance to stick it's foot in the door for years.

Learn to make games with my SDL 2 Tutorials


#23 Lazy Foo   Members   -  Reputation: 1105

Like
0Likes
Like

Posted 16 April 2006 - 06:47 PM

Quote:
Original post by jfclavette
No one even use OpenGL anymore. They're already tied to Windows.


The DS, PSP, PS2, GC, Rev, and PS3 all use some form of OpenGL and don't use the windows operating system.

Learn to make games with my SDL 2 Tutorials


#24 jfclavette   Members   -  Reputation: 1058

Like
0Likes
Like

Posted 16 April 2006 - 07:06 PM

Quote:
Original post by Lazy Foo
Quote:
Original post by jfclavette
No one even use OpenGL anymore. They're already tied to Windows.


The DS, PSP, PS2, GC, Rev, and PS3 all use some form of OpenGL and don't use the windows operating system.


Of course. I was talking about the PC.

Quote:
and it's not like OpenGL is underdeveloped and undersupported like Mono.


[lol] Of course not. That's why you have to use an extension for pretty much anything that doesn't have its roots back in the nineties and why the studios go trough the pain of converting their OpenGL code to D3D on the PC. The OpenGL review board is probably the most innefficient organization on the planet.

Meanwhile, I'd still like to see how Mono is underdevelopped.

#25 The Reindeer Effect   Members   -  Reputation: 211

Like
0Likes
Like

Posted 16 April 2006 - 07:15 PM

JIT code can outperform statically compiled code in certain situations specifically because there is runtime information present, even all the whole-program analysis in the world cant provide the sort of procedure-branch statistics that allow a hotspot compiler to optimize. I'm not sure how much this applies to game development, it really depends on the particular game's performance profile.

And Lazy Foo, you need to keep in mind this is website is populated mainly by hobbyists who do not have access to DS, PSP, PS2, GC, Rev, or PS3 devkits. Windows is the most common target platform, likely followed by linux. PC developers can take advantage of existing infrastructure (such as Java), whereas I'm supposing that a console developer is very limited and has to make a choice between additional systems programming or just getting to work on the game.

I can't honestly recommend Java for game development ... but I do recommend taking advantage of tools that increase productivity and if Java works for a developer, then it's all gravy. Java is not nearly slow enough to ignore it as a viable choice, doing so is by definition 'premature optimization'.

#26 Lazy Foo   Members   -  Reputation: 1105

Like
0Likes
Like

Posted 16 April 2006 - 07:21 PM

Quote:
Original post by jfclavette
Of course. I was talking about the PC.


That's not an excuse to ignore the industry as a whole.

Quote:
Original post by jfclavette
That's why you have to use an extension for pretty much anything that doesn't have its roots back in the nineties


There's no correlation between the use of extensions being underdeveloped.

Quote:
Original post by jfclavette
Why the studios go trough the pain of converting their OpenGL code to D3D on the PC.


It's the major 3D API on windows. It doesn't mean that OpenGL isn't undersupported just look at OpenGL at the GDC.

Quote:
Original post by jfclavette
Meanwhile, I'd still like to see how Mono is underdevelopped.


It a new technology. C++ used to just be C with objects and it took time to reach its current level of development.

...Man this topic has been derailed.

Learn to make games with my SDL 2 Tutorials


#27 Lazy Foo   Members   -  Reputation: 1105

Like
0Likes
Like

Posted 16 April 2006 - 07:25 PM

Quote:
Original post by The Reindeer Effect
And Lazy Foo, you need to keep in mind this is website is populated mainly by hobbyists who do not have access to DS, PSP, PS2, GC, Rev, or PS3 devkits. Windows is the most common target platform, likely followed by linux. PC developers can take advantage of existing infrastructure (such as Java), whereas I'm supposing that a console developer is very limited and has to make a choice between additional systems programming or just getting to work on the game.


It doesn't really matter who or what has access to it when the argument is whether or not OpenGL is used in the industry.

Learn to make games with my SDL 2 Tutorials


#28 Promit   Moderators   -  Reputation: 7572

Like
0Likes
Like

Posted 16 April 2006 - 07:30 PM

Quote:
Original post by Lazy Foo
It doesn't really matter who or what has access to it when the argument is whether or not OpenGL is used in the industry.
On a console, you do not have a choice. On Linux or OSX, you do not have a choice. Therefore, examining OpenGL or the other respective APIs for those platforms is a meaningless and ultimately pointless exercise.

We then come to the Windows x86 platform, where you'll find Direct3D dominates. Draw your own conclusions as to why. I have my beliefs, but they're not terribly relevant.

#29 Lazy Foo   Members   -  Reputation: 1105

Like
0Likes
Like

Posted 16 April 2006 - 08:00 PM

Quote:
Original post by Promit
Therefore, examining OpenGL or the other respective APIs for those platforms is a meaningless and ultimately pointless exercise.


1) All internet arguments are pointless.

2) When the claim "OpenGL is not used widely in the industry" it doesn't not matter why or how, all it matter is that it's used widely period.

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.

Learn to make games with my SDL 2 Tutorials


#30 Daerax   Members   -  Reputation: 1207

Like
0Likes
Like

Posted 16 April 2006 - 08:10 PM

Quote:
Original post by Lazy Foo
Quote:
Original post by Promit
Therefore, examining OpenGL or the other respective APIs for those platforms is a meaningless and ultimately pointless exercise.


1) All internet arguments are pointless.

2) When the claim "OpenGL is not used widely in the industry" it doesn't not matter why or how, all it matter is that it's used widely period.

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.


Things are a bit (as in significantly) more complex than you paint them. There is no one language or API that is used, rather, what gets the task done most cleanly efficiently is used. Python, lua, xml, C++, proprietary language with C derived syntax, to name a few all find their place in the development of modern games. On the x86 PC you will find that the only people who still bother with/focus on OpenGL are academics who feel it necessary to make everything as difficult for themselves as possible.

MasterQ, do not worry about which language will dominate the market in x years, increase your skill by learning programming [concepts] in languages such as C# or Python (if games i suggest managed direct x 9 with c#)...when the time comes, you will find that it does not matter what language is in vogue, because you see, you will be able to program in a truer sense of the word. :)

#31 Promit   Moderators   -  Reputation: 7572

Like
0Likes
Like

Posted 16 April 2006 - 08:11 PM

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

#32 Lazy Foo   Members   -  Reputation: 1105

Like
0Likes
Like

Posted 16 April 2006 - 08:25 PM

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


#33 Promit   Moderators   -  Reputation: 7572

Like
0Likes
Like

Posted 16 April 2006 - 08:27 PM

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.

#34 The C modest god   Banned   -  Reputation: 100

Like
0Likes
Like

Posted 16 April 2006 - 08:55 PM

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?

#35 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 16 April 2006 - 09:03 PM

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.

#36 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 16 April 2006 - 09:17 PM

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.




#37 The C modest god   Banned   -  Reputation: 100

Like
0Likes
Like

Posted 16 April 2006 - 09:17 PM

How do you get the time in miliseconds from the hardware in java?

#38 The C modest god   Banned   -  Reputation: 100

Like
0Likes
Like

Posted 16 April 2006 - 09:22 PM

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

#39 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 16 April 2006 - 09:28 PM

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



#40 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 16 April 2006 - 09:44 PM

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.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS