Why Do Intel CPUs stink at games?

[Gizmo]

There is an interesting article over at ExtremeTech which asks the question, "Why do Intel CPUs stink at games?". We all know that in most benchmarks, AMD usually comes out on top in the gaming area. This is true even when AMD lags Intel in other benchmarks. So, one of the people at ExtemeTech decided to disect the executable for BF2, and found some interesting things.

What do you think? Do Intel CPUs REALLY stink at gaming? Is there a massive conspiracy among game writers to make AMD look better than Intel? Is it a case of game writers just not wanting to risk turning on all the compiler options?

[Staz]

OK, Why would a game manufacturer purposely hobble the performance on a game?

[Áedán]

It raises several questions. Firstly, how much performance is lost across the two classes of processors given that the code is optimised for a Pentium class processor (no optimisation flag present).

Now, MS's documentation appears to suggest that you can see a speed up of around 5-10% ( on the code. Assuming worst case that this optimisation resulted in no speedup on the AMD processors (which we know is untrue), then it would produce a speedup on the P4 processors of 10%.

Using the BF2 framerates present in the original article shows that there's more than a 10% difference between the two processors. Thus, we can see that even in the best light, those optimisations will not result in enough of a difference to stop AMD keeping the lead.

On the other hand, my experience with compiler optimisations is that they can, under certain circumstances, lead to some odd and very difficult to debug crashes. Developers have limited time. If they have to spend many hours trying to work out why good code is mangled by a compiler optimisation, then that's many hours they're not spending fixing the real bugs in the program. When you're under time pressure to get a product finished, then the compiler optimisations are going to be the first thing that goes out of the window! At least that way the developers are going to know that any bugs that are in the code are actually in their code, not the compilers code.

[Staz]

Originally Posted by Staz

Why would a game manufacturer purposely hobble the performance on a game?

Originally Posted by Áedán

Developers have limited time. If they have to spend many hours trying to work out why good code is mangled by a compiler optimisation, then that's many hours they're not spending fixing the real bugs in the program. When you're under time pressure to get a product finished, then the compiler optimisations are going to be the first thing that goes out of the window!

Thanks Áedán

[Gizmo]

I highly doubt there is any conspiracy; AMD doesn't have enough resources to make it worth the developer's while, for one thing (i.e. money), I don't think.

There is also the possibility that they are using an older compiler. For example, I have products I maintain that were originally compiled using Microsoft Visual C 2.0, and I still use the 2.0 compiler to build and maintain them. Why? Because there are a lot of things that have changed over the years, and I can't simply drop that code into the latest Visual Studio .NET 2005 and expect it to compile without having to change a fair amount of code (libraries have changed; some function calls no longer exist, others take different arguments than they used to, internal data formats are different, the list goes on and on). Oddly enough, the VC 2 compiler doesn't have any idea how to optimize for a P4.

That's one issue.

Another is that, as Áedán points out, compiler optimizations can cause some weird problems. While it might be desirable to optimize for the most common CPU in the target audience, the fact is that after you've spent days tracking down a compiler induced bug, you are going to be loathe to reactivate a setting that could potentially cause that bug to reappear.

The fact is that in many cases, optimizers are simply a substitute for lazy programmers. This is not necessarily a bad thing, mind you. As a programmer, I should be able to spend most of my time developing the algorithm, not worrying about how to make it more efficient. However, if I do need to make it efficient, there are a LOT of things I can do in the source code. I once took a speech recognition algorithm that required over a minute of real processing per second of voice, and rewrote the source code so that, using the same hardware and the same audio, it only took about 3/4 second for the same second of voice. That was right at 2 orders of magnitude performance improvement, and that improvement was achieved even after the original code was compiled with optimizations enabled! Now granted, the original algorithm was written to illustrate how to do speech recognition, not for efficiency, but I think it still illustrates my point.

If I've got a piece of code that is so performance sensitive that I need the additional benefits of optimized code (and I can't reap those benefits by carefully laying out my source code), then I am most likely going to drop straight to assembler and do it myself. In which case, I don't need the compiler mucking about and screwing around with my memory and register layout.

[alexkerhead]

Intels do not suck at games, just benchmarks favor amd a tad more.
Not a big deal, I wish amd people would quite making intel people think that intels are like 1/4 the gaming speed.
The truth is, you need a benchmark to tell the difference, real life, the diff in 55fps and 65fps is unoticable.

[Seperah]

Easy there cowboy. Yes the article says "stinks at games"
But the question is why a specific architecture be it AMD or Intel isnt exploited to its fullest potential... Not "AMD pwnz Intel"

I'm still thinking about this one though..

[hoinar]

Originally Posted by alexkerhead

Intels do not suck at games, just benchmarks favor amd a tad more.
Not a big deal, I wish amd people would quite making intel people think that intels are like 1/4 the gaming speed.
The truth is, you need a benchmark to tell the difference, real life, the diff in 55fps and 65fps is unoticable.

In a benchmark I see odd figures mate, but in a 45 to 35 fps change I see a broken keyboard that's what I think matters more.

[skool h8r]

Originally Posted by Seperah

But the question is why a specific architecture be it AMD or Intel isnt exploited to its fullest potential... Not "AMD pwnz Intel"

Perhaps there is something going on with compilers and developers and AMD. If you notice, on many of the newer games, it does say something like 'works great on AMD64'. And yes, looking for a reason why optimistaions are done in a particular way would be very time consuming, it's all been worked out as 'what is the best/quickest way a CPU can process binary without errors?'. If you could actually look at the binary of an exe that is optimised and one that isn't optimised, you would see that the optimised one is less organised for viewing by a human but runs better when it is read by a CPU. Still, i do think that many game developers are leaning towards AMD now, mainly because of how quickly they are progressing as opposed to intel progressing. In the past few years, AMD have made many technological advances such as 64-bit CPU's, dual cores amongst other things. It seems that intel are starting to try and follow what technologies AMD are 'creating' as it were, and then creating what they think is better. The arguement continues.

[aghastpumpkin]

CPC Benchmarks.

Very interesting.

FPS Results at 1600x1200 4xAA 8xAF with an Athlon 3000 and an Athlon FX-57 hooked up to Twin 7800GTXs
64 3000
BF2 65FPS
Doom 3 85FPS
FEAR 41FPS
Far Cry 60FPS
Quake 4 54FPS

FX-57
BF2 65FPS
Doom 3 97FPS
FEAR 41FPS
Far Cry 80FPS
Quake 4 549PS

It clearly shows that the extra £500 you spent on that FX57 gave you no increase in gaming performance.
Which in turns means, spend less on CPU, more on GFX.

Intel Vs AMd Benchmarks
Rome Total War GeForce 6800GT 1280x1024 2XAA 2xAF

FX57 19
64 4000 18
X2 4800 17
Intel P4 670 3.8GhZ 15
Intel P4 3.7GhZ Extreme Editon 15
Intel 2.26GhZ Pentium M 15
Athlon 64 3000 14
Athlon 64 X2 3800 14
Sempron 3400 13
Intel Pentium D 840 12
Intel Extreme Edition 840 12
Intel 630 3GhZ 11
Intel 1.7GhZ Pentium M 11
Sempron 2600 10
Intel 2.8GhZ D820 10
Intel 2.6GhZ Celeron 331 7

All scores in FPS using FRAPS.
We can conclude that bringing into account cost, AMDs CPUs outperform Intels for gaming.
We can also conclude that X2 Athlons are slower than single core Athlons in gaming.

[aghastpumpkin]

Sorry to double post.
But I'd like to put this bit in.
From wha those results tell me, I think I can build up a PC for £1000 that is a true gaming monster.

Abit AN8 Sli £120
1024MB Corsair Ram £130
2x7800GTs £450
AMD Athlon 3500 Venice £130
Seasonic 600W PSU £85
Add on your extras like drives and you get to about £1K.

Previously, I'd have thouht this was better.
Abit AN8 SLI
1024MB Corsair Ram
Sapphire Radeon X800GTO2/Connect 3D Radeon GTO
AMD Athlon X2 4800

[Áedán]

Originally Posted by skool h8r

Perhaps there is something going on with compilers and developers and AMD. If you notice, on many of the newer games, it does say something like 'works great on AMD64'. <snip> If you could actually look at the binary of an exe that is optimised and one that isn't optimised, you would see that the optimised one is less organised for viewing by a human but runs better when it is read by a CPU.

Having done some reverse engineering, I can tell you that binaries are not optimised for viewing by humans at all. It takes a huge amount of effort to turn binary code into something understandable by humans even without any optimisations.

From what I've seen (which isn't really that much), most games are optimised for 386/486 processors. This means that subsequent processors won't be able to get the most performance out of the code, but at least it'll run across all modern processors. If you compile code specifically for one processor (both at the CPU and architecture level), then the chances are very good that the code will not run correctly on a different processor.

Again, from a developer point of view, this is a huge headache. It means maintaining several seperate versions of code, for each of the target architectures. That multiplies the amount of work necessary to debug the code, as seperate versions of the code may well have specific bugs due to interactions between compiler flags and processors.

The net result is that the "runs best on" or "works great on" is nothing more than marketing. The likelihood is that the code was never optimised for one specific manufacturer at all.

Interestingly enough, Intel's compiler does a very good job optimising code. However, running that code on an AMD processor also results in a performance boost...

(As far as I'm aware, AMD doesn't have their own compiler?)

[keithwalton]

intel have not allways sucked at games, if you look back to the quake 3 engine based games (most notably quake 3 arena itself) intel had a decisive upper hand with the P3. At the time it would take an amd athlon chip running a good 100-150mhz faster than an intel chip just to bench the same.
A friend of mine had a P3-666 (440bx) and at max settings at the time it took an athlon 800 to narrowly beat it.
Alas times have indeed changed