Gaming In 64-Bit: Tom's Tests, Microsoft Weighs In

Page 3 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Toggle sidebar Toggle sidebar
Status
Not open for further replies.
In a repeat of what we saw in Grand Theft Auto, shifting to a 64-bit platform results in lost performance in Left 4 Dead at both 1680x1050 and 1920x1200. It’s only when you step up to 64-bit that the speed is recovered—though the 6 GB platform is not any faster than the 3 GB, 32-bit configuration.

Don't you mean "6 GB"?
 
[citation][nom]truehighroller[/nom]The game GTA IV has a bad memory leak you guys should have played it longer and it would have crashed your system eventually. That would have been sweet to note in this article because then maybe R* would fix it for everyone. You can also just watch the memory being used with a monitoring program and see it taking more and more and then boom hard rebot or CTD.[/citation]
Reboot and CTD didn't happen to me after long hours of playing GTA IV under vista 64 bit OS..Nevertheless I noticed the game uses more and more RAM the longer I play till it eats up 3.7 of my 4 Gb (according to Rivatuner monitor)..I think the problem occurs in 32 bit environment only.
I vote for KEEPING GTA IV IN THE BENCHMARK SUITE..I know it isn't optimized but the game is very popular and it's the single most ddemanding title now, so it's logical to see how different setups can handle it..
Frankly I believe, by talking alot about crysis and its "successor" GTA IV, we're encouraging game developers to make their games madly demanding..
 
After reading some comments about a prophecy of a kick-ass game that will be optimized for multiple GPUs and CPU cores, and lots of RAM, what comes in my mind is DOOM 4, that is if ID software can do the fantastic job they did with DOOM 3.
Look to myself! Again glorifying demanding games!! In effect optimized games must have all the glamour and glory..
 
[citation][nom]curnel_d[/nom]"Given the very known nature of these virtual address space limitations, you’d think that game developers would be taking a more hurried approach to making the transition."This mainly has to do with resources. Most developers use the same engine they've built or bought for a span of many years. Take bioware, for instance, who used the Auroa engine for 9+ years, knowing that it was limited to single threads and low memory. To switch to 64-bit, these developers would have to take the time not just to modify their existing engines, but more likely rewrite the entire engine because of the changes involved. Something that some developers just cant afford.[/citation]

This is true. In the talk with Chuck, he mentions that it's also a support/publisher issue.
 
[citation][nom]amdfangirl[/nom]I say the benefit of having full access to 8GB of DDR2 is enough to make me switch to 64 bit. Not using a Page File and being able to use native 64 bit programs like those found in CS4, is worth it enough. The advantage of being able to execute native 64 bit instructions is absolutely heavenly powerful speed boost(CS3 vs CS4).[/citation]

We'll be taking a look at applications next--this one was just about gaming =)
 
[citation][nom]apache_lives[/nom]heh we forget the main concepts here with 64-bit:NO ONE uses a system with nothing bar windows a single game installed - they have a few security apps, torrent apps, messenger, keyboard/mouse apps etc - they all sap up resources, so 64 bit gives all apps all the memory they need - for example 8gb is useless to a 32-bit app, but when you got that hungry game ASWELL as a hungry background app etc they both get the full amount of memory!Also lessens the "thrashing" effect on HDD's and helps there lifespan etcAs for why there arnt any benifits for 64 bit games etc - there all still native 32-bit because all those morons still think there 2gb and XP is "sufficent and up to date" - move to 64-bit so we can all benifit![/citation]

The challenge there, Apache, is creating an environment that yields comparable results. One way to exaggerate the demands, I suspect, would be to open Word, Outlook, Skype, Vent, and so on. The fundamental issues addressed in the story don't change, though.
 
[citation][nom]joeman42[/nom]Interesting. However, you did not test the scenario expressed prior to the benchmarks. Mainly, x64 providing access to more complex scenes. I am curious if various detail levels would affect frame rate.[/citation]

Of course they would, but more as a result of the change in graphics demands, though.
 
[citation][nom]gamerk316[/nom]No Dev wants to support two versions of the same program (otherwise Linux would have a lot more games ), so until most everyone shifts to a 64-bit OS, you will continue to see lackluster 64-bit support. Its the same deal with DX10, you won't see any games developed soley for DX10 until XP loses more market share.We won't see many 64-bit games (let along games designed to be 64-bit from the start) until M$ kills of 32-bit OS's (Windows 8), so I think we need 4-5 years before 64-bit programming takes off.[/citation]

+1. I agree that the issue is largely one of supporting multiple executables.
 
[citation][nom]Waynerm[/nom]"We’ll even take our own medicine. Many of our most recent reviews already employ 64-bit environments, but in the weeks to come, expect to see a benchmark revamp, where we shift as many of our tests as possible to the latest 64-bit versions."Sure switch to evaluation metrics that most of us don't have.In the preceding tests you should have gone one step further and provided 2GB RAM benchmarks with 32 bit and for sure there would not be much difference with current games. It is my observation that many games will indeed crash when they hit the 2GB of memory mark on a 32 bit system with 4GB memory installed. However just having 2 GB installed this does not seem to happen and in fact the games run faster because better memory timings can be used.It's not that I am against 64 bit in fact I am looking forward to it but it seems that Tom's is losing touch with the reality of the home computing audience. As an example all this bally-who over the questionable Crysis engine and the claims of bloated hardware to run it is ridiculous. I mean come on Tom's! 50 bucks for the game and $3000 to play it? Crysis can be run on a modest system simply reducing the resolution and by not using Anti Aliasing.So please when touting 64 bit lets be factual and real for the average user too.[/citation]

😵 I'm not sure *anyone* has their Core i7 platform configured with 2GB.
 
[citation][nom]astro_16[/nom]This article completely ignores a chief benefit of having 64bit Vista with oodles of RAM which Toms has previously covered and given credence too: You get a MASSIVE SuperFetch (HD cache). Load times of games and loading of level/areas etc. can be much faster.[/citation]

Astro,
Thanks for the note. As we progress with the 64-bit app piece, we'll make sure that this is something we explore.
Best,
Chris
 
[citation][nom]cangelini[/nom]😵 I'm not sure *anyone* has their Core i7 platform configured with 2GB.[/citation]
Nor is it really possible withotu going out of your way to find a dual channel 2x1gb kit under 1.65v.
 
[citation][nom]computer_chief[/nom]Obviously, with testing framerates, that's mostly controlled via the GPU which is consistent between the systems. Not to mention the Graphics cards have their own memory to use.How about we test the difference when running a game server? Or the difference seen when hosting a game server and running a client both on the same machine? I bet you'd see differences there![/citation]

Comp,
What you're describing is a different usage model that what I was looking to explore in this piece, but you bring up a good point. Game servers very likely will favor a 64-bit operating environment. That's one of the big wins mentioned in the piece.
Thanks!
 
When I read that the reason for moving to 64bit computing is not about speed I want to pull the rest of my hair out and there isn’t much left after 37 years in this business. Simply stated if an “application” does not benefit from moving twice as much data at the same clock rate, all else equal than it is either I-O bound or the “app” isn’t actually running native 64 bit code. Tom’s produced a comparison a couple years back showing the difference between the same Windows Passmark benchmarks running in Native 64 bit Windows, 32 Bit Windows and 32 bit running under the 64 bit Windows on a laptop and the 64 bit version ran pretty much across the board 10% faster and even the 32 bit test running under the 64 bit OS (WOW) ran faster. That’s on a laptop that couldn’t hold a candle to what you can buy today. The chief problem with 64 bit “apps” today it that they are written in machine independent virtual development languages and even when converted to “64 bit” code they really aren’t running in complied Native 64 bit code. There are numerous layers that stand in the way of getting the true benefit of 64 bit code at this point. I have to deal with this all the time in Server Land and with apps like SAP where it is mounted in a a 64 bit machine, OS but the 64 bit SAP version is limited to 32 bit addressing (formerly 31 bit addressing like Windows 32) and runs a virtual machine interpreter that makes the underlying native word size and benefits moot for the most part. True 64 bit code will provide a 20-40 percent boost in “speed” if it is true native compiled code for most apps. There in lies the problem. Most apps are developed on virtual machine interfaces that emulate a standard of machine that puts numerous layers between the actual machine specific binary code and the interpreter that runs the app. If it does not speed up under 64 bit hardware, OS then one or more things are poorly written or simply not true 64 bit native code execution. This certainly applies to Games where the vendor wants to port the games to as many different platforms as possible. Native code will provide significant speed increases when the App Vendors actually start delivering it.
 
[citation][nom]nater[/nom]This is wrong:"Once you factor in device addressing, the magic number actually drops below 4 GB. That’s why it’s common for 32-bit systems with 4 GB to report 3 GB plus change in the Windows Device Manager. It’s not a Windows problem, though. Rather, that’s just how x86 architecture works."It is a Windows "problem" when you are running Windows on a motherboard with a chipset that doesn't support mapping I/O high. I wouldn't call it a "problem" though, it's a decision Microsoft made with their non-"Server" Windows versions to be compatible with poorly written drivers. Correctly written 32-bit drivers would handle being located above the 4GB physical memory boundary by using bounce buffers and adhering to the guidelines that Microsoft developed and published years ago. Most consumer-grade drivers however were written poorly, and when they were mapped above the 4GB boundary, they tried to access their own memory locations directly and failed. So Microsoft instead maps the driver I/O space over the top of physical memory in 32-bit non-"Server" Windows (i.e. if you run the 32-bit Windows Server 2003 on a computer with 4GB of RAM you will get to use all 4GB of RAM). Linux and Mac OS X do not map driver I/O space over the top of physical RAM in 32-bit and you can use all 4GB in those systems, *unless* the chipset was designed badly.The best example of such a badly-designed chipset was by Intel in 2005 and 2006, with their Sonoma (915) and Napa (945) chipsets, which stupidly couldn't map I/O high and capped those systems at 3GB *even if* the OS could have used all 4GB in 32-bit mode.There are also a lot of subtleties involving historical performance choices regarding the TLB, PAE (which has been around since the Pentium Pro and it's 36-bit memory addressing), and the relationship between virtual and physical address space and mapping which websites covering these topics just fail to explain, or when they do, to get right.This has all caused no end of confusion in any article I've read on this topic, and I'm now giving up on writing to the authors and editors at places like tomshardware, anandtech, etc. since they don't ever respond or correct their articles when I email them, and I guess I'll just have to post comments.[/citation]

Thanks for the note nater. I've updated the story to clarify. FWIW, I make a best effort to respond to as much feedback as possible, so never hesitate to contact me.
 
[citation][nom]badaxe2[/nom]In a repeat of what we saw in Grand Theft Auto, shifting to a 64-bit platform results in lost performance in Left 4 Dead at both 1680x1050 and 1920x1200. It’s only when you step up to 64-bit that the speed is recovered—though the 6 GB platform is not any faster than the 3 GB, 32-bit configuration.Don't you mean "6 GB"?[/citation]

Yup, fixed.
 
[citation][nom]nray[/nom]Regarding this:"In preparing for this piece, we searched high and low, asking around to hardware and software vendors alike, for evidence of games written to run in a native 64-bit environment. Only two surfaced: Crysis and Hellgate: London (Far Cry was patched to run 64-bit natively too, once upon a time, as was Half-Life 2)."That's missing the Chronicles of Riddick and Unreal Tournament 2004, the latter of which was a very high profile 64-bit title and shipped 64-bit alongside 32-bit at the time of release.And I'm confused by the "once upon a time" comment regarding the Half-Life 2 series, because anyone who has Half-Life 2 or Half-Life 2: Lost Coast installed in Steam on a 64-bit system will be running the 64-bit version of the game (though Episode One and Episode Two are not 64-bit, oddly enough, which I've never understood).[/citation]

Good point--UT2004 was also patched for x64. I never did play Chronicles, though it was reported that the 64-bit version didn't have any sort of copy protection. Perhaps Starbreeze ran into similar problems with 64-bit middleware as Crytek?
 
Windows 7 should be 64 bit only. No computer will be sold with less than 4 Gb of RAM in the near future.

Now, I are a lot more interested in minimum framerates benchmarks, because they are the real show stopper when playing games.
 
[citation][nom]cangelini[/nom]Good point--UT2004 was also patched for x64. I never did play Chronicles, though it was reported that the 64-bit version didn't have any sort of copy protection. Perhaps Starbreeze ran into similar problems with 64-bit middleware as Crytek?[/citation]

That is correct that Riddick in 64-bit did not have any copy protection, very similar to Crytek's Far Cry in 64-bit having no copy protection. Riddick in 32-bit used SecuROM 5.03 and shipped with three different 32-bit executables (Win32_x86, Win32_x86_SSE, and Win32_x86_SSE2).

Commercial copy protection solutions like StarForce and SecuROM were extremely slow about supporting 64-bit, and I would argue that the single biggest thing that kept 64-bit XP from being more popular with gamers were all the issues caused by 32-bit copy protection - the copy protection compatibility problems combined with the hesitation I'm sure a lot of publishers had to release a 64-bit version of their game without copy protection (because there were no 64-bit copy protection solutions at first!) As a result, I think gamers blamed XP 64-bit for what was primarily a copy protection/software publisher issue.
 
[citation][nom]williehams[/nom]If simply for the allowance of more ram it makes sense, however Vista64 has even more hardware compatibility issues than Vista32. Trying to install a linksys wireless card was a no go, even with guides and bodged drivers the result was poor, I resorted to an USB wireless adapter instead which is pretty lame.[/citation]

That's not the OS's fault. That's linksys' fault.
 
Chris,

I just wanted to say I enjoyed this article. It's interesting to see the FPS results for the titles you listed. Though I agree, GTA IV is not the best of benchmarks by any means.

We need software/game developers to stop making cross titles. That or develop them for PC, and port them to XBOX, rather than the other way around. 8^)
 
[citation][nom]jerreece[/nom]Chris,I just wanted to say I enjoyed this article. It's interesting to see the FPS results for the titles you listed. Though I agree, GTA IV is not the best of benchmarks by any means.We need software/game developers to stop making cross titles. That or develop them for PC, and port them to XBOX, rather than the other way around. 8^)[/citation]

Here, here! Totally agree =)
 
once upon a time, we played 16-bit, and moved to 32-bit.
and somedays we'll say "Once upon a time, we played 32-bit, and moved to 64-bit"

I think the need of more than 3GB accessable memory is a must, not now, but in sometime soon!
 
it does not look like 64 bit improves performance that much if at all but are there other advantages? like load time when using ramdisc software to mount the game in the abundance of ram? i would like to see how well a game runs if it is mounted in the ram. even if all you have is 8gb of ram that should be enough to mount most games and still have plenty left to play the game.

just curious.
 
Status
Not open for further replies.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom