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

#41 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 16 April 2006 - 10:01 PM

Quote:
Original post by Anonymous Poster
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.


Well, it's a matter of statictics, good designed Java programs compared to good designed C++ programs have a bigger chance of getting better cache results. Due to their tighter class structures.
But I surely argee that comparing ordinary "middle-of-road" programs, C++ programs will finish first.
But then.... I remember the time (I am getting old :-( ) when I had the same discussion while defending my assembler programs against those new C programmers...... tja...

Speed isn't everything..... Java programs are much easier to program and to maintain....
But that's my opinion ;-).





Sponsor:

#42 Fella   Members   -  Reputation: 102

Like
0Likes
Like

Posted 16 April 2006 - 10:22 PM

Quote:
C#: Doubt it. A proprietary language will never take over an entire industry so unless microsoft allows an open standard I don't see it happening.


.NET is an open standard.
http://www.mono-project.com/ECMA

Quote:
Ok an open standard that doesn't suck.

and by doesn't suck, I mean something where I can easily take a language's code and use it where ever I want.


You can use it on many platforms.
http://www.mono-project.com/Supported_Platforms


Quote:
Mono is in it's infancy, and needs much more support.


It is a stable release 1.1.13.6. It has support form Novell.

At LinuxWorld 2006 in Boston, Mono won the award for "Best Application Development Platform or Tool".
http://www.mono-project.com/news/archive/2006/Apr-05-1.html





#43 DrGUI   Members   -  Reputation: 402

Like
0Likes
Like

Posted 16 April 2006 - 10:31 PM

Just to note, J# is a .NET language and will therefore compile to IL and be JIT compiled, and will run as fast as any other .NET language.

I don't know much about java but presumably it wouldn't take too much effort to port it to J#?

#44 The C modest god   Banned   -  Reputation: 100

Like
0Likes
Like

Posted 16 April 2006 - 10:32 PM

The code for fibunachi given in that article is really faster on java.
But who does recursion in a place that needs performance?
I checked a non recursive fibunachi function in both java and Visual2003 C++, made it run 10000 times.
The result is that it took java 6.1 seconds and C++ 5.8 seconds
Maybe I dont know how to optimze java, I just ran it using JBuilder.
Are there super optimization to java? or the way I ran it is almost the most optimzed way to run a java application?


#45 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 17 April 2006 - 12:10 AM

Quote:
Original post by Anonymous Poster
Well, it's a matter of statictics, good designed Java programs compared to good designed C++ programs have a bigger chance of getting better cache results. Due to their tighter class structures.
But I surely argee that comparing ordinary "middle-of-road" programs, C++ programs will finish first.
But then.... I remember the time (I am getting old :-( ) when I had the same discussion while defending my assembler programs against those new C programmers...... tja...

Speed isn't everything..... Java programs are much easier to program and to maintain....
But that's my opinion ;-).


I dont see so easy the cache results performance advantage in the case of java apps. In fact the very large memory use in java implies lesser spatial reference, and thus a larger set of cache blocks, and that means more cache faults.

Of course, java development is faster than C++, but in games the performance is a fundamental constraint, and if it isnt fulfilled, the productivity gain doesnt matter.



#46 KittyRa   Members   -  Reputation: 259

Like
0Likes
Like

Posted 17 April 2006 - 12:28 AM

I like C# but I like C++ more. I will be very upset if it's replaced by C# or Java.

#47 Beer Hunter   Members   -  Reputation: 712

Like
0Likes
Like

Posted 17 April 2006 - 12:51 AM

Quote:
Original post by The Reindeer Effect
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.
Some C++ compilers can also use branching statistics to optimise code, using what they call profile-guided optimisation. It takes an extra compile and a test run, and I suspect that JIT compilers can do a better job of it, but I'd be interested if anyone knows of any benchmarks comparing their performance.

#48 Shiny   Members   -  Reputation: 456

Like
0Likes
Like

Posted 17 April 2006 - 12:57 AM

Hm, a page over or so, someone (forgive me for not bothering to check...it's getting late) said something about -why- runescape is programmed in Java. Along the lines of that it is not a commercial game, yadda yadda yadda.

Truth is, Java is just so much easier to use for cross platform web apps -- It -is- what it was designed for after all. Runescape is a cunning application and has decent load times as long as the user has even modest broadband. Considering the amount of kids etc who play it, I'd say it's quite successful (even if that is because it is free).

~Shiny.

#49 Spoonbender   Members   -  Reputation: 1254

Like
0Likes
Like

Posted 17 April 2006 - 02:36 AM

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.

So? Who said assembly is fast? Try writing a small program in ASM, do the same in C, and see which ends up fastest. I'm willing to bet C will win. Because the compiler is a lot better at managing the complexities of code scheduling on todays cpu's.
ASM *can* be fast, just like C or Java *can* be fast. Anything running interpreted code has extra overhead, so it can never be quite as fast, but with JIT, there's nothing to stop Java from being fast.

Quote:

Is java faster then assembly too?

Again, why not? Depends on the java code and the asm code you're comparing. Writing in asm can produce terribly inefficient code if you don't know *exactly* what you're doing.
Writing in Java makes it a lot easier to get acceptable performance.


#50 MasterQ   Members   -  Reputation: 100

Like
0Likes
Like

Posted 17 April 2006 - 04:11 AM

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.

#51 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 17 April 2006 - 04:17 AM

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?

#52 MasterQ   Members   -  Reputation: 100

Like
0Likes
Like

Posted 17 April 2006 - 04:22 AM

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.

#53 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 17 April 2006 - 04:41 AM

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


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

#54 C0D1F1ED   Members   -  Reputation: 456

Like
0Likes
Like

Posted 17 April 2006 - 04:42 AM

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

#55 Ademan555   Members   -  Reputation: 361

Like
0Likes
Like

Posted 17 April 2006 - 04:49 AM

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

#56 Spoonbender   Members   -  Reputation: 1254

Like
0Likes
Like

Posted 17 April 2006 - 05:24 AM

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.

#57 C0D1F1ED   Members   -  Reputation: 456

Like
0Likes
Like

Posted 17 April 2006 - 05:27 AM

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.

#58 [deleted99599]   Banned   -  Reputation: 100

Like
0Likes
Like

Posted 17 April 2006 - 05:55 AM

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.

#59 MasterQ   Members   -  Reputation: 100

Like
0Likes
Like

Posted 17 April 2006 - 05:55 AM

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.

#60 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 17 April 2006 - 06:18 AM

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.




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