Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (575)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  C/C++, Python, C#, Java benchs. Results surprising  (Read 2402 times)
0 Members and 1 Guest are viewing this topic.
Offline xbrain

Senior Newbie




Java games are the Future


« Posted 2004-01-09 11:19:49 »

hello,

I found an interesting article on the net with benchmarks between all the most popular languages. Results are surprinsing. Especially JDK 1.4.2 results.

Here:

http://www.osnews.com/story.php?news_id=5602&page=1

XBrain - Don't let others control your Mind...
Offline Preston

Senior Duke


Medals: 4



« Reply #1 - Posted 2004-01-09 11:26:51 »

Yes, that's the same site which has been mentioned one topic earliear, named "for Jeff.... microbenchmarking."

BUT... since I love well named topics (and can't stand badly named ones) I clearly prefer yours. :-)
Offline shawnkendall

Senior Duke





« Reply #2 - Posted 2004-01-09 14:10:10 »

From the article:
"What lessons can we take away from all of this? I was surprised to see the four .NET 2003 languages clustered so closely on many of the benchmark components, and I was astonished to see how well Java 1.4.2 did (discounting the trigonometry score). It would be foolish to offer blanket recommendations about which languages to use in which situations, but it seems clear that performance is no longer a compelling reason to choose C over Java (or perhaps even over Visual J#, Visual C#, or Visual Basic)--especially given the extreme advantages in readability, maintainability, and speed of development that those languages have over C. Even if C did still enjoy its traditional performance advantage, there are very few cases (I'm hard pressed to come up with a single example from my work) where performance should be the sole criterion when picking a programming language. I would even argue that that for very complex systems that are designed to be in use for many years, maintainability ought to trump all other considerations (but that's an issue to take up in another article)."

- emphasis mine
As it says, excluding the Trig test, it finds Java and .NET C++ neck 'n' neck.
Nice :-)

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #3 - Posted 2004-01-09 20:58:50 »

It's still a couple of very limited cases (as most benchmarks are), but the article still helps in the general attitude towards java. I was happy with the results in the article too  Smiley

Erik

Offline K.I.L.E.R

Senior Duke




Java games rock!


« Reply #4 - Posted 2004-01-10 02:52:52 »

Why the hell is trig so slow in the benchmark?

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline Preston

Senior Duke


Medals: 4



« Reply #5 - Posted 2004-01-10 05:49:54 »

Quote
Why the hell is trig so slow in the benchmark?

From an article in the other topic about the same benchmark:
Quote


No prizes, but that is the problem. When reducing 'large' arguments Intel use a 66bit version of pi which is inadequate to maintain the precision required by Java. They also restrict the domain of the trig functions to rather less than the full range of double. Java requires that Math.sin(1.0e300) produce a result accurate to within 1 lsb.

http://developer.java.sun.com/developer/bugParade/bugs/4345903.html
Offline K.I.L.E.R

Senior Duke




Java games rock!


« Reply #6 - Posted 2004-01-10 07:22:48 »

Thanks.

I wouldn't class that as a bug though as high precision could be useful to some people. By default I believe it should use less precision but allowing an option for full precision for those who need it would be useful.

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline crystalsquid

Junior Duke




... Boing ...


« Reply #7 - Posted 2004-01-10 10:02:01 »

Precision is a big issue with Intel chips.
When writing PC games, the first few lines in my code always sets the FPU precision to 'single', as divides, trig, & sqrt calls are almost double the speed.

The dependance on doubles for some of the maths functions is irritating in Java. What is more common - Java Games, or high-precision Java mathematical & engineering applications? Which is the main focus for Java development at Sun?

- Dom
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #8 - Posted 2004-01-10 10:20:19 »

It would be nice to have a FloatMath to go next to what is currently a DoubleMath, if only to avoid having to cast the results back to floats constantly...

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Mark Thornton

Senior Duke





« Reply #9 - Posted 2004-01-10 10:45:56 »

I understand that float versions of the Math methods were originally omitted because the early compiler couldn't distinguish between methods which differed only in float vs double arguments. Why this defect still hasn't been fixed is another question.
As far as Intel processors are concerned, when using the  normal FPU instructions there is little performance advantage in float over double. You only get such an advantage if using SSE instructions which the JVM has only recently been enhanced to use. I gather that most RISC processors do show a significant performance benefit when using float instead of double.

As general practice, developers should use double until they know they have a performance problem and they should check their calculations very carefully for numerical instability when converted to float. It is far easier to get wrong answers due to the lack of precision with float than with double.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline crystalsquid

Junior Duke




... Boing ...


« Reply #10 - Posted 2004-01-10 13:21:15 »

Quote
As far as Intel processors are concerned, when using the  normal FPU instructions there is little performance advantage in float over double


Intel FPU timings (PII+):

FDIV:
   Double: 32 cycles
   Float:    17 cycles

FSQRT:
   Double: 57 cycles
   Float:    28 cycles

FSIN/FCOS timings are dependant on the number you are using, but in general float code is near double the speed.

SSE instructions (PIII) only deal with float. You need SSE2 to get multiple double precision calcultions.

For 99% of games, I would reccomend using float precision at all times. In fact the PS2 doesn't even have a double precision FPU!!

the only cases where errors were noticable were during complex collision & physics, but then again for games we only need perceptible quality - not mathematical rigour. The near-doubling of the maths performance is definately a win for games development.

Quote
but it seems clear that performance is no longer a compelling reason to choose C over Java (or perhaps even over Visual J#, Visual C#, or Visual Basic


C / C++ has one major advantage for performance critical code - Inline assembler. Sadly, performance & readibilty/maintainability/portability rarely go hand in hand.

- Dom
Offline Mark Thornton

Senior Duke





« Reply #11 - Posted 2004-01-10 13:33:45 »

Quote


Intel FPU timings (PII+):

FDIV:
   Double: 32 cycles
   Float:    17 cycles


On the other hand the timings for multiplication and addition/subtraction are nearly identical. It is common to arrange calculations to avoid division as far as possible. So unless your code consists entirely of the slower ops like division, then a more typical mix will show no great advantage for float.

The performance difference between addition/multiplication and division is partly because division is more complicated, but more importantly because Intel (and other processor designers) put less effort into optimising it.
Offline crystalsquid

Junior Duke




... Boing ...


« Reply #12 - Posted 2004-01-10 14:55:11 »

You are absolutely right - with careful pipelining the adds/muls can be executed at nearly one instruction per clock cycle. However, the cases I am considering are inner loops for perspective transforms. These would typically involve a div or sqrt, and would account for 30-40% of CPU time. The whole loop per vertex including clip testing would need to be <100 cycles, and the difference of 18 cycles non-pairable you get with a divide really hurt.

As with all optimisations, it only matters in the parts of the code that are run the most, and so 90% of the maths doesnt matter. It's the other 10% of cases (the inner loops) where lowering the precision can make a significant difference.

Other instructions we found 'troublesome' are the float to int conversions needed to get from our maths to screen coordinates, and the float comparison operations (very nasty in x86). This is where C++ unions (or inline assembler) can give you a nice speed up as well.

Personally I would love to see an 'inline bytecode' facility for Java so we could use instructions that were not available via the standard C-like language (bitwise roll, add/subtract with carry spring to mind), as well as being able to reduce the bytecode counts for certain inner loops (my sprite rendering routines would benefit immensly from this).

- Dom
Offline Mark Thornton

Senior Duke





« Reply #13 - Posted 2004-01-10 15:48:24 »

Division is so slow relative to multiplication that when accuracy requirements aren't high it might be worth computing the reciprocal using a few terms of a series expansion and then multiplying by that.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (34 views)
2014-10-17 03:59:02

Norakomi (25 views)
2014-10-16 15:22:06

Norakomi (24 views)
2014-10-16 15:20:20

lcass (26 views)
2014-10-15 16:18:58

TehJavaDev (50 views)
2014-10-14 00:39:48

TehJavaDev (50 views)
2014-10-14 00:35:47

TehJavaDev (40 views)
2014-10-14 00:32:37

BurntPizza (63 views)
2014-10-11 23:24:42

BurntPizza (36 views)
2014-10-11 23:10:45

BurntPizza (74 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!