What an astonishing time capsule this is...
I have been around these forums for a pretty long time (as you can probably see). As you can also see, I don't make many posts here, usually because I simply haven't got that much free time, but I will ask a question or make a comment from time to time, particularly where I feel I may have any useful knowledge. This is a conversation that has taken place many 'elsewheres' and years ago, and those with demanding applications have already 'hit the wall' over - meaning- the wall between Accountancy and Marketing on one side, and technical capability on the other.
I understand (better than you can possibly imagine) that not all technical roads lead ineluctably to 64 bit solutions (in the short run), but eventually one must state a few facts that are causing some of the witnesses here to be misled.
It is entirely understandable to people in the business that one has to look at market size overall (and bigger is better for the people on the money side) and market size for the demographics specific to the title at hand (because it doesn't make any sense to make a sewing kit for your grandma's demographic that requires a barcode reader to understand the instructions). Of course, maybe that means MY grandma, since I am a pretty old guy, but, maybe you get the picture.
So, first a number of technical points have been made in the thread, some quite true, some less true, some irrelevant. I will simply state here where the rubber meets the road, and ignore cases where people are apparently driving off-road without 4-wheel vehicles.
1)An application in 32 bits may or may not demand enough
physical ram that
overall system use MUST be >4g of system ram, where a 32 bit OS is then a limiting factor. In most cases, not (to be honest, in
32 bit gaming, I do not think you will find one, and for good reason). Of course with various kinds of virtual memory available, that is not where the rubber meets the road first, and is, in effect, a straw man. A 32 bit OS will on an overall basis limit your accessible system ram to 4g, sure, but it is the application being in 32 bits that creates an earlier likely bottleneck for 32 bit OS environments:
2)This is of course the user side's 'application virtual memory address' limit. 32 bit _applications_ have internal addressable memory limits for resources that can 'be used to work on them'. This space includes a number of things, but most important to this discussion, 'memory' that has been committed to the application's use. The default setting for userva, or the user's half, of that space is only 2G in a 32 bit OS. Of course, the dev can set LAA flags (Large Address Aware) to indicate more can be used, but the 32 bit OS user must manually increase their userva client-side to take advantage of that LAA flag.
This can temporarily relieve the the ever-expanding demands on the limited addressable virtual memory space in a 32 bit application but only to a point. This is because 32 bit _applications_ have two further limitations: total 'addressable virtual memory' is only ~4g, and a significant proportion of it is required for kernel operations in a 32 bit _OS_ environment - which we may simply regard as 'system needs'. This effectively limits the 32 bit OS user side to somewhere in the < ~3g of application addressable virtual memory space. Getting closer to that limit leads to increasing chances of instability and sometimes even 'reasonable' increases above default userva can cause problems due to bad system drivers.
The good news for 64 bit OS environments is that they don't have to do any manual client-side userva command-line mucking about to take advantage of LAA flags or worry about any instability for more virtual space, and rather importantly, kernel operations (system needs) are handled OUTSIDE the application's virtual memory addresses, freeing up the sum total of ~4g of the application's virtual memory address space. Well. Of course, that's huge.
3)Now for some bad news, the 'virtual memory addresses' in the application also have to 'address' any graphic memory used, and that contributes to filling up that space like system memory. Memory isn't just system-side. The more graphically rich you make a product, the more graphic memory you will cause to be addressed in the limited space you have. Of course that is bad for both 32 bit OSs, and 64 bit OSs, but the latter of course have access to an additional ~1g+ and this was more often than not, enough to put them beyond trouble, or at least it used to be.
4)The question is first, then, one of addressable application virtual memory.
Effectively, the micro seconds one may save or waste in one OS versus the other is of a minor concern against the backdrop of the ultimate barrier 32 bit applications face (and particularly 32 bit OS limitations with a 32 bit application), which is namely that faced by a title series I directly support, and this is the decision to either move to 64 bit, or limit the upper boundary of application capability and/or eye-candy. This DOES NOT MATTER if virtual application memory addresses used (by system AND video memory and the odd driver and cache) never exceeds 2G. It is does, then the warning light is on. Paradox will be setting that LAA flag and 32 bit OS users will be looking for the userva command line, and hope that needs don't exceed somewhere in the 2.5 to 2.9g range. 64 bit users will be at least ok until the space used or needed begins to approach ~4g, although they would benefit more from a 64 bit OS, but this is a minor issue if more virtual space is not really needed
It seemed however, to be honest, an ingenuous discussion to be 'taking care of the shrinking minority' of 32 bit OS owners and a complete disconnect to have a discussion about 32 bit OS's operating better on 32 bit applications, without addressing the fact that I) if this is so, it requires the vast majority who own 64 bit OSs to have to possibly suffer any speed loss no matter how minor; or II) 32b applications limit everyone to smaller addressable application memory space, 32 bit OS owners most of all, if there is any likelihood of pressure on the application addressable virtual memory... No? If the case is that there is no pressure right now on the app. virtual memory addresses, there is little enough need for 64 bit in any real sense, and we are mostly arguing about very minor factors indeed.
Apologia
(I have completely ignored all sorts of details, and abstracted wildly to try to get the point across to non technical readers.
I am well aware that some video tasks can be done outside addressable vm, that there are a number of ways that registers outside that space may be
theoretically capable of handling additional tasks in exchange for a speed-hit, but at the same time I have not discussed memory manager limitations, the vagaries of what happens when things get left up to video drivers for how much video memory will be reserved and the issues that may arise from the differences arising amongst free, guaranteed, and reserved memory addresses versus overall system vm guarantees etc.
I have not discussed double point precision, or why, despite its speed disadvantages, it is in the 64 bit CryEngine variant currently under development by CIG with direct help from Crytek. I concur that it might help some of the potential Vic. has but is not without its costs as well. I have left off so many things... Its a shambles I've set up, really, but I only wanted to make those basic two points about how we may be leading ourselves into some false premises, and should get the priorities straight.)
Ultimately, we know that the game is already being programmed, and is therefor in 32 bits.
It can't be in 64 bits, because if so, 32 bit clients would be unable to play it at all.
I can already say that unfortunately, the truth of the matter is that it makes no financial sense to write both a 64 and a 32 bit code because it is nearly a complete rewrite to change code to 64 bit, and therefor doubling the effort at every stage (writing, testing, supporting). I can say that multiplayer between 32 bit and 64 bit clients are currently somewhere between extremely unlikely to impossible to get to work with one another, and where even possible, far beyond double the cost, trouble, and risk.
Ultimately, I tend to trust that the studio knows what in hell it is doing, and generally it proves this over the long haul. I should know.
