Far Cry AMD64 Edition - A First Look at 64-bit Gaming
by Anand Lal Shimpi on May 10, 2005 4:51 AM EST- Posted in
- CPUs
64-bit Far Cry Performance
For the most part, 32-bit games run at the same speed or slightly slower under x64 Edition compared to 32-bit Windows XP Professional. And from what we've seen with titles that have native 64-bit binaries (e.g. Chronicles of Riddick), there aren't any real performance gains to be had there either. In order to find out if Far Cry was any different, we looked at two separate platforms: an AMD Athlon 64 X2 4200+ and an Intel Pentium D 3.2GHz. All benchmarks were conducted with an ATI Radeon X850 XT and at 1024x768 with Very High quality settings enabled.We compared performance under 32-bit Windows XP, as well as x64 Edition, while running both 32-bit and 64-bit versions of Far Cry under the latter. We used our standard Far Cry demo that we've used in all other reviews, and in order to isolate the performance differences from the extra content, we only looked at performance changes with the first 64-bit patch installed - not the Exclusive Content Update.
Interestingly enough, Intel actually does a little better - showing a 6.5% increase in performance. It's tough to say exactly why Intel gets more of a performance boost here, other than assuming that for whatever reason, Intel is facing more register pressure in our particular benchmark.
We're just happy that there is any sort of performance improvement at all - but to those looking for major increases in performance by moving to 64-bits, it's less and less likely to happen.
Facebook
Twitter
RSS
59 Comments
View All Comments
Jynx980 - Thursday, May 12, 2005 - link
More insects and birds? I better hop on the 64 bit wagon!Im surprised to see so many uneeded processes running. qttask, ati2evxx, ipodservice, ituneshelper; these things eat up the ram little by little.
KF - Wednesday, May 11, 2005 - link
There is no way to say for sure that the basic design of Far Cry is sufficiently ambitious to show off AMD64 well, because designers need to design to what is available in mass if they plan to sell games in large quantity. Intel only recently capitulated to doing EMT64, so designers could not design with 64 bit in mind.
It may be that AMD's intent was to show that more abitious game designs are more practical for a 64 bit machine. If AMD wants to demo advantages of AMD64, there needs to be a 32 bit version of the game with the extra content to compare, or else they need to show why the added content is not possible with 32 bits.
Why do more registers speed things up? Keeping things in registers is the fastest way to do things. x86 has 8 general purpose registers, 6 of which are ordinarily available. To do a very simple loop, you are liable to need 2 or 3 registers to hold adresses and at least 2 to hold operands. Since you need to hold onto intermediate results in the process, you are already nearly maxed out. That was fine in the original 386 days. But current CPUs can readily execute 3 ops simulanaeously, so if you attempt to use the CPU to maximum capablity, and do multiple things concurrently, you run out of registers. Therefore the capabilities of present CPUs are vastly underutilized. Adding 8 more general registers, like AMD64 does, helps a lot. Intel says that by actual measuremnent in real programs, currrent CPUs average 1 op per cycle, when they can do a possible 3. Not impressive. I hope that explains the potential of more registers.
OTOH, programs like games obviously use massive amounts of data which is only briefly in registers, so slinging that in and out of memory is going to take up a lot of time. That will limit the average ops per cycle considerably. It is only while you are processing a given chunk of data that you could get the number of ops per cycle up. The more you process a given chunk of data, the more potential speed up possible. If the design was not ambitious enough, there is not going to be much speed up. Older CPUs would be good enough.
thelanx - Wednesday, May 11, 2005 - link
Has anyone compared the enhanced visual quality screenshots with hdr screenshots? I know that enabling hdr makes the colors of the land and the water more vibrant, which seems to occur in the enhanced version as well, most noticably the better water and more vibrant trees. Perhaps crytek used what they learned doing the hdr and implemented similar effects without using hdr?Sheeno - Wednesday, May 11, 2005 - link
I don't get the problem, Anand showed that the difference between the 64bit patch and a normal 32bit farcry was negligible. In fact, the only difference is the graphical enhancements you get from adding the second 'graphics' patch. We can all assume that the quality of your graphics card will run the latter, so why the 64bit? It seems this was nothing more then a marketing stunt, and those of us with 32bit processors, AMD or not, are left without a neat update. Thanks AMD, I'm glad you decided to forsake your 32bit processors.ir0nw0lf - Tuesday, May 10, 2005 - link
As much as I love AT, I feel that the [H]ard|OCP article was much more informative and "meaty." Their article didn't seem to have a rushed feel to it vs. the AT article, which as mentioned above feels a bit rushed and possible incomplete.msva124 - Tuesday, May 10, 2005 - link
Thank you, that makes sense.stephenbrooks - Tuesday, May 10, 2005 - link
^ Compiler doesn't get in knots swapping stuff in and out of main RAM or cache so often. Registers have a 0 cycle access delay :pmsva124 - Tuesday, May 10, 2005 - link
>That's like asking why would more cache, or more RAM increase performance..Then it should be very easy for you to explain why more registers will increase performance.
Concillian - Tuesday, May 10, 2005 - link
I will go along with many of the opinions I'm seeing here and say that I think there is a lot of assumption in the article, and not enough proof.- The reader is assumed to know that 1024x768 high quality is CPU bound
- The article assumed that the performance of 64 bit patch + additional content would show worse performance, but has no demonstration of that in either a CPU bound or GPU bound scenario. (speaking of the comments: "In fact, a fast GPU is all you really need to take advantage of most of these features - not a 64-bit CPU" and "but the fact of the matter is that none of the visual improvements enabled by the Far Cry patches had anything to do with AMD64 or EM64T"
Perhaps those comments assume more knowledge of how all this stuff works than the average reader has, and it's more obvious to someone like Anand with a more extensive knowledge of CPU architecture and how software interacts with specific registers, etc... Maybe the conclusion is more obvious to someone with that kind of knowledge, but I just see conclusions being drawn about one thing (64 bit patch + ehanced content) from a test of a completely different thing (64 bit patch only)
Anand, you talk about apples to apples comparison. To take that analogy and run with it... Why do you do an apples to apples comparison and then make a conclusion about potatoes?
I think it would have been a reasonable comparison to see the performance with and without the additional content to demonstrate which hardware was actually being taxed (video or CPU). Especially with the strong opinion expressed in the article about what hardware the etra content taxes. I don't question the conclusion necessarily, I just think that if you maake such a strong statement you should have real data to back it up.
I only criticize because we have high expectations of AT articles. I hope these comments are seen as constructive, because that's the intent.
xtknight - Tuesday, May 10, 2005 - link
I agree that some additional benchmarks with the 64-bit content pack would have been a good idea, even if it's not apples to apples. I'm not downloading this patch for the 5 FPS increase, I want the extra eye candy. Is the content pack supposed to include only stuff a 64-bit CPU could do efficiently? Then it would be nice to compare it to a 32-bit CPU. Otherwise, I understand your reasoning that this pack really has nothing to do with 64-bit in the first place.