Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
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  
  Can the current Java 2 SDK compiler optimise for..  (Read 2063 times)
0 Members and 1 Guest are viewing this topic.
Offline K.I.L.E.R

Senior Devvie




Java games rock!


« Posted 2004-07-01 05:55:35 »

64 bit computing?

I've recently bought an AMD Athlon 64 and want to take advantage of the 64 bit instructions as they have shown remarkable increases in apps that support both 32b/64b processors.

Does Java Hotspot pick this up and optimise for it?

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

Jeff:
Unemployed. Wink
Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2004-07-01 07:09:18 »

No.

Cas Smiley

Offline Bombadil

Senior Devvie





« Reply #2 - Posted 2004-07-01 07:12:59 »

The SDK compiler doesn't do anything for 64 bit CPUs: please remember, it produces platform neutral Java bytecode and knows nothing about Amd, Intel, Arm, Sparc, etc. :-)

However the HotSpot does know them, in case you use a 64 bit JVM. Unfortunately I didn't find many docs explaining what benefits a 64 bit JVM will bring, aside the obligatory http://java.sun.com/j2se/1.4/performance.guide.html doc.

I too would be interested in finding out more about 64 bit JVMs.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline crystalsquid

Junior Devvie




... Boing ...


« Reply #3 - Posted 2004-07-01 07:41:46 »

With any luck a 64bit VM would make the double maths nearly as fast as float - or is that just crazy optimism...

Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2004-07-01 07:50:35 »

64 bit will make double and long operations as fast as their 32-bit counterparts. It will also likely come at the expense of a lot of wasted RAM as many things work best when aligned on word boundaries.

Seeing as we don't need double and long ops in games programming it's not going to have any useful effect for us.

Cas Smiley

Offline crystalsquid

Junior Devvie




... Boing ...


« Reply #5 - Posted 2004-07-01 09:02:56 »

It won't be quite as fast, as the memory bandwidth in the main bus will be the same as 32bit.

As to using doubles - we've had the issue mentioned before that some of the Java maths calls use doubles internally.

Sadly I wouldn't hold my breath that divides and sqare roots will be as fast as their speed is dependant on the number of bits of accuracy. We can always hope though...

- Dom
Offline K.I.L.E.R

Senior Devvie




Java games rock!


« Reply #6 - Posted 2004-07-01 09:11:56 »

Several things that have been shown with AMD A64 processors while they compile a C program to 64bit and 32bit and pitted them against each other:

*64b there tends to be an increase in program size.
*64b is faster under all circumstances
*64b code is more efficient

Using AMD's "beta" compiler.

http://www.cpuid.com/K8/index.php

Click to Play

Click to Play


*Note, these 64b scores only relate to AMD's CPUs, not Intel CPUs.

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

Jeff:
Unemployed. Wink
Offline crystalsquid

Junior Devvie




... Boing ...


« Reply #7 - Posted 2004-07-01 10:16:08 »

The more common case (for now) would be 32bit code running on the 64bit processor, so how does that compare?

It would be a real feather in Javas cap if the JITs start producing nice 64bit code - real possibilities to show significant speed improvements over 'blended' 32bit C++ code which most people will be using (except for the few purists who will still make optimised assembler 64bit inner loops, but they will be few & far between).

- Dom
Offline cfmdobbie

Senior Devvie


Medals: 1


Who, me?


« Reply #8 - Posted 2004-07-01 11:47:49 »

Well, yes, benchmarks are all very well and good, but you're missing the really important bit:  64 is twice as much as 32 - it's a much bigger number!  It's gotta be better because of this!

For that reason alone, my next machine will be an Athlon64.


(Actually I'm only half telling the truth.  The other reason I'm buying an Athlon64 is because it comes in a shiny box...)

Hellomynameis Charlie Dobbie.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #9 - Posted 2004-07-01 12:28:27 »

Quote
It won't be quite as fast, as the memory bandwidth in the main bus will be the same as 32bit.


Quote
Several things that have been shown with AMD A64 processors while they compile a C program to 64bit and 32bit and pitted them against each other:

*64b there tends to be an increase in program size.


It is a long-known problem (for many many years) that moving from 32-bit to 64-bit stresses your buses, because now you have to send twice as much data on each data-transfer (except where you were already using 64-bit in software, of course).

Since the major bottleneck in modern PC's is ... the bus ... there's been some scepticism about the benefits of moving to 64 bit ever since it was first commercially viable (many years ago). Of course, one of AMD's big wins over Intel was moving to a bus architecture for multi CPU's that was less than 20 years old Tongue. Last time I checked in detail, it looked as though AMD's bus architecture sufficiently made up for the problem in real programs - but it's still a point to bear in mind: 64 bit systems are inherently slower than 32 bit systems, unless you had to work in 64 bits anyway. There were many 16-bit programs that were "upgraded" to 32 bits just "because they could" (or, nowadays, because MS no longer allows 16 bit programs to run on their OS...c.f. next release of windows) - but if the extra bits were unnecessary, you've literally just reduced performance Sad.

So, personally ... as a games developer, I don't really care what the hardware does, so long as I can demand that they have a mode which accepts 32 bit data over the bus. Which, IIRC, is/was one of the problems with Itanium - it demands data in 64 bits, which is quite a bummer if you don't WANT to run in 64 bits?

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mark Thornton

Senior Devvie





« Reply #10 - Posted 2004-07-01 12:49:05 »

Quote

Of course, one of AMD's big wins over Intel was moving to a bus architecture for multi CPU's that was less than 20 years old Tongue.

Or rather not a bus architecture at all but point to point hyperlinks. This does add the complication of NUMA (non uniform memory access) where each CPU has directly attached memory which can be reached faster than that attached to some other CPU.

Offline Mithrandir

Senior Devvie




Cut from being on the bleeding edge too long


« Reply #11 - Posted 2004-07-01 14:26:51 »

Quote
So, personally ... as a games developer, I don't really care what the hardware does, so long as I can demand that they have a mode which accepts 32 bit data over the bus. Which, IIRC, is/was one of the problems with Itanium - it demands data in 64 bits, which is quite a bummer if you don't WANT to run in 64 bits?


You realise the fallacy that you've fallen into here? Since when do applications actually work in single 16/32/64/... bit data across the bus (any bus in the system)? Think of fetching something from main memory, there's at least 2, probably three levels of caching between the instruction on the CPU and the system memory. In all these cases, the computer never fetches a single word because that is way too inefficient. It will fetch it in page sized chunks, which are typically 4 or 8 words, sometimes bigger depending on the cache prediction strategies in use.  The only time you'll ever use 32 data directly is going to and from a register. Even then, with out of order execution, it's very likely the CPU will  fetch it in a page sized piece of data and queue up the instructions and data on a best-fit principle.

Then, we get into the next issue of running 32 bit code on a 64 bit native architecture. Pentium Pro ring a bell?

What you are talking about is way into the realm of premature optimisation that is so frowned on. It's even worse in the Java world where you have a VM sitting between you and the CPU doing all sorts of stuff you don't expect it to. In our experience, doing the sort of "optimisations" you're advocating here actually causes the code to run a heck of a lot slower than it really should, simply because of some really uneducated understanding of the higher level systems design and implementation.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #12 - Posted 2004-07-01 14:55:51 »

Quote

You realise the fallacy that you've fallen into here? Since when do


Chuckle. I thought the best way of finding out would be to stick my neck out far, and make it to tempting for anyone *not* to reply...

Quote

applications actually work in single 16/32/64/... bit data across the bus (any bus in the system)?... It will fetch it in page sized chunks, which are typically 4 or 8 words, sometimes bigger depending on the cache prediction strategies in use.  The only time you'll ever use 32 data directly is going to and from a register. Even then, with


But I don't understand how *that* is relevant. If the data being fetched is 64 bit words, that's going to be 4 or 8 words of data. If it's 64 bit words, it's going to be 2 or 4 words of data.

If I were being more cautious, I would merely have said that whilst bus throughput continued to be a signficant bottleneck that 64 bit hardware has downsides. What I was expecting was that perhaps someone might point out that latency bus bottlenecks are now entirely dominant, so I should quit worrying over bandwidth (but...for graphics intensive stuff, bandwidth still seems to be an issue, in as far as you cannot just go downloading just-in-time content from the gameserver, decompressing, and streaming it to the card - which I know more than one game currently in dev would like to do, and is trying to hack around)

Quote

What you are talking about is way into the realm of premature optimisation that is so frowned on. It's even worse in the Java world where you have a VM sitting between you and the CPU doing all sorts of stuff you don't expect it to. In our experience, doing the sort of "optimisations" you're advocating here actually causes the code to run a heck of a lot slower than it really should, simply because of some really uneducated understanding of the higher level systems design and implementation.


When I said "demand a mode" I meant in a vague, generic sense. I didn't mean I wanted some kind of API for pro-actively demanding it, I meant I just wanted a complete system that had that capability, which the JVM could then take advantage of when it realised that I wasn't using any 64 bit variables. I don't want to be dipping my toes into cpu tweaking! I left that hell behind a long time ago Wink.

malloc will be first against the wall when the revolution comes...
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #13 - Posted 2004-07-05 01:49:51 »

Has anyone tried the 64bit VM to see how it compares to the 32bit VM??   I don't have access to a 64 bit machine to try this myself.

Also note that on PowerMac G5's (64 bit) the Apple VM will produce 64 bit code.  With Panther (OS 10.3) or later.  So on the Mac platform there is no special VM to install.

Offline Mithrandir

Senior Devvie




Cut from being on the bleeding edge too long


« Reply #14 - Posted 2004-07-05 14:30:40 »

(Forgot all about this thread, coming back to it now... )

Quote

But I don't understand how *that* is relevant. If the data being fetched is 32 bit words, that's going to be 4 or 8 words of data. If it's 64 bit words, it's going to be 2 or 4 words of data.


Note that you're still within the size of data that is fetched with a single memory access by the caching mechanism. Say you have a single 32bit piece of data - a class var or (in C) static variable.  If your word size is 32bit, that's a single fetch. If your word size is 64bit, it is still a single fetch. If you were to fetch no other data around that one variable, there would be no performance penalty to pay regardless of whether you are using a 32 or 64bit CPU because that actual amount of data fetched is greater than what you requested. (you request 32bits, but the cache strategy always fetches blocks of 256bits of data).  

The one assumption made in my argument is that you're accessing just a single variable. Of course, if you're doing processing on a large array of data, then yes, we can assume a better response from the smaller data size if we're interating through a large array.

An additional factor to weigh in here is the nature of your C compiler. That int may be compiled as 32bit or 64bit depending on the platform. Unlike Java, that states an int shall always be 32bits, C does not have this restriction. The int may be 16,32 or 64 bits depending on the compiler and platform.

Quote

If I were being more cautious, I would merely have said that whilst bus throughput continued to be a signficant bottleneck that 64 bit hardware has downsides.


If this were a C or C++ programming forum, I might be inclined to agree with you, but would focus more on the caching side of the argument. Still for them, bus issues are less of an issue than just trying to keep as much stuff cached as possible so that the bus doesn't come into play. However, since we're in the Java world, we don't really even have that level of control. The VM is inclined to do all sorts of tricky stuff that we just have no control over, particularly with regards to caching strategies.

Quote

When I said "demand a mode" I meant in a vague, generic sense. I didn't mean I wanted some kind of API for pro-actively demanding it, I meant I just wanted a complete system that had that capability, which the JVM could then take advantage of when it realised that I wasn't using any 64 bit variables.


Remember that due to the strict data size requirements of the Java language that unless you are using longs or doubles, this will always be the case.  Also, take note of my first reply -  running the wrong size data on the CPU can cause very significant performance problems.  Forcing the use of 32bit data on a 64bit machine probably will cause that code to run slower than if it had just used the native word size. That's the root of my points - just because the machine is 64bit, doesn't mean that 32bits is going to be more efficient and thus there should be some way of telling the JVM to "only deal with 32bit data". Given past history and the benchmarks that are coming out now for the AMD64/Ia-64 machines, it's almost guaranteed to perform worse than if you'd just stuck with the machine's native word size and not tried to force "optimised" code execution onto it.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
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.

rwatson462 (33 views)
2014-12-15 09:26:44

Mr.CodeIt (23 views)
2014-12-14 19:50:38

BurntPizza (51 views)
2014-12-09 22:41:13

BurntPizza (84 views)
2014-12-08 04:46:31

JscottyBieshaar (45 views)
2014-12-05 12:39:02

SHC (59 views)
2014-12-03 16:27:13

CopyableCougar4 (58 views)
2014-11-29 21:32:03

toopeicgaming1999 (123 views)
2014-11-26 15:22:04

toopeicgaming1999 (114 views)
2014-11-26 15:20:36

toopeicgaming1999 (32 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

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
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!