PDA

View Full Version : CPU disagreement



JJJJJ
06-09-2006, 06:28 AM
Why, whenever someone asks for advice on buying a CPU, everyone rushes in and says get a double core?

Double core is useless unless you have the software that can use it.

I have an Athlon 64 x 2 4200+. It is useless for my game playing. Slower than previous 3200+.
I am about to replace it with something that does not have a " x 2 " in it's name.

Would some of the people who reccomend the X 2 like to tell me what software will perform better with the x 2? And I mean available now. Not something that may be written in the future.

pctek
06-09-2006, 09:36 AM
I have an Athlon 64 x 2 4200+. It is useless for my game playing. Slower than previous 3200+.
I am about to replace it with something that does not have a " x 2 " in it's name.

What games are you playing that causes slowness? Because they are a number of patches around for this problem.
AMDs optimizer - one off MS website etc....

It shouldn't be a problem with the newer games, I tried mine and theres no difference except with Warcraft II - slow....but I expected that.

The_End_Of_Reality
06-09-2006, 09:47 AM
As pctek said, there are dual core patches.

I have notice a performance increase on all my games when setting it to use only one core or two, the two cores are faster, not by much though

I do a lot of video encoding and editing and most of the programs that I have are good for dual core and run the CPU at ~90-100% eg: DivX, Fairuse Wizard... these are out not and have been for some time

FoxyMX
06-09-2006, 10:09 AM
What games are you playing that causes slowness?

I would have thought that everyone knew Jack plays flight sims by now. :p

JJJJJ
06-09-2006, 10:34 AM
What games are you playing that causes slowness? Because they are a number of patches around for this problem.
AMDs optimizer - one off MS website etc....

It shouldn't be a problem with the newer games, I tried mine and theres no difference except with Warcraft II - slow....but I expected that.


MS Flight Simulator.

TGoddard
06-09-2006, 11:11 AM
When you have a dual core processor you have to be aware that you will only get both cores working if you have software that supports it and an operating system with multi-processor support. This means that you can only use a single core with Windows XP Home and only threaded processes can use both cores at once.

Many older and current games use only a single-threaded design, meaning that a dual core processor will be no faster on one of these than on a single core one. Many game programmers, however, are beginning to run intensive operations such as AI in separate threads. It has traditionally been avoided due to poor general understanding of thread safety, but is now becoming more common.

If you want to be able to get the most of next year's games and are buying a new computer, dual core is definitely the way to go. The current Intel dual core processors are pretty impressive with only one core anyway :)

Trev
06-09-2006, 11:31 AM
MS Flight Simulator.

Jack FS9 dosen't support dual core but, FSX well, so I would hold fire until FSX comes out before you do anything stupid.

Trevor :)

PaulD
06-09-2006, 11:47 AM
This means that you can only use a single core with Windows XP Home and only threaded processes can use both cores at once.

You can use dual core processors with XP Home but only 1 physical CPU/socket.
http://www.holwegner.com/article/419/yes-xp-home-supports-dual-core

KiwiTT_NZ
06-09-2006, 12:37 PM
I suppose dual core should be compared to a turbo'd engine (high speed processor) or a larger engine (more processors). It just depends what you actually do.

Just remember, in the equations of performance and faster graphics card as usually better then a faster CPU.

FoxyMX
06-09-2006, 01:03 PM
No one has actually answered Jack's question yet, although Trev's advice seems pretty sound to me.

bizzack
06-09-2006, 03:23 PM
Hey JJJJJ pm me if you wanna give a poor starving student your dual core cpu, it would be a great help for my graphics programs! :p I'll give you my AMD 2600 + in return :rolleyes:

Trev
06-09-2006, 05:16 PM
The Last Word on Dual Core
Well, my last word, anyway. It seems there's quite a bit of anxiety on the FS boards about whether or not FSX will "take advantage of" multi-core CPUs. I've tried to provide some explanation but it's quickly drowned out by the waves of claims, opinions and speculation. So I thought I'd try one last time to explain the real deal. After this, I'm done.

First off, let's just all own up to the fact that multi-core CPUs technology is no silver-bullet magic voodoo that automatically gives you twice (or four times) the performance of a single-core CPU on all applications. Despite the hopes on many 20th century authors and futurists we do not yet have "thinking" computers that can look at an application, figure out what the programmer meant for it to do, and automatically optimize it to make it work faster. The programmers gotta do the work. And that work ain't easy for a game where you need to spit convincing images to the screen dozens of times each second.

So what, really, needs to be done? Simply put the programmer needs to divide up computational tasks in such a way that the operating system can "farm out" the work to multiple CPUs. In computer parlance these are known as "threads". The notion of so-called "multithreaded" applications is nothing new since multiple CPU PCs have been around for quite some time. It's only recently, with the advent of multi-core CPUs bringing multi-CPU computing to the masses, that the topic has garnered much interest from gamers.

What makes programming a multithreaded application, especially a game, difficult is the interdependecies between tasks. For example, take AI aircraft in FS. I can't count the number of times I've read "why can't FS just use the second CPU for AI traffic?" Well, what's involved in rendering AI? For one thing the AI occasionally need to know "am I on the ground?" For that, some process has to be able to figure out where the ground is--i.e., the terrain system. There's one interdependency right there. Another interdependcy is the AI's use of ATC. ATC needs to track the AI planes as well as the user's aircraft. And the list goes on and on.

The net result is that, no matter how many threads a program creates in an attempt to "take advantage" of multiple CPUs, at some point the work on one thread is going to have to stop and wait for something else, likely on another thread, to happen. This is especially true for a game where the application needs to update the screen. Server-applications that can treat requests independently from one another are less affected. Suppose, for example, that AI rendering was delegated to a thread that was dependent on the terrain system on yet another thead to provide it with infomation. What happens when it comes time to render the AI's position? Do you wait indefintely for the terrain system? If you wait too long you'll see a stutter. Do you simply not render the AI but rendering everything else? Not unless you want the AI to appear and disappear and jump around the screen.

Hopefully you can see that a multithreaded game like FSX consists of a numerous start, wait, and complete sequences. The big problem here is that when you get too many of these then nothing gets done because everything is waiting on everything else. So where can you use multiple threads? You use it where the interdepencies are loose and indeterminate wait times aren't readily noticable. In FSX we use multiple thread for texture decompression and certain types of file I/O. Consider terrain textures that must be loaded and decompressed as you fly along. Normally new textures are needed for the area at the edge of the visual scene. Using low-resolution versions for the initial display and then loading higher resolutions in the background works because texture swapping in the distance is not very noticable. In other words, it doesn't a matter if a texture is available immediately or several frames after it's requested because you likely won't notice the delay.

The good news is that these threads can be "farmed out" by the OS scheduler to multiple CPUs or cores. The bad news is that requests are made with varying frequency so the overall CPU utilization will also vary. In other words, those of you running the FSX demo and looking for 100% utilization on all your cores can just stop--you're not going to see it. You'll see a lot of utilization when you first load a flight (and we force requests to complete) and less as you fly along. As we continue to evolve the code base we'll continue to look for areas where thread offloading makes sense but changes in the area can have unexpected results so it will take time to decide what works best. And, oh, when you find a game that does use all that horsepower all the time, please let me know.

This is from one of the MS guys who is working on FSX.

Trevor :)

Graham L
06-09-2006, 05:32 PM
Sooner or later some smart game developer is going to realise that they could make an enormous improvement to the performance of any computer when their game is running.

All that would be needed is a small stub to shut down the OS, then load and run the game programme.

As well as the problems of multithreading mentioned in that article quoted by Trev, the game developers have to cope with the fact that the OS is trying to do things too. So a game thread might be waiting for an OS thread to complete.

Games are realtime applications. Realtime stuff has always been best handled as the only programme running. That way, you can be sure that any timing or synchronisation problems are your own fault. :D

I doubt if my hypothetical game developer would work for Microsoft. (Or not for long after this realisation) ;)

TGoddard
06-09-2006, 06:45 PM
Sooner or later some smart game developer is going to realise that they could make an enormous improvement to the performance of any computer when their game is running.

All that would be needed is a small stub to shut down the OS, then load and run the game programme.

As well as the problems of multithreading mentioned in that article quoted by Trev, the game developers have to cope with the fact that the OS is trying to do things too. So a game thread might be waiting for an OS thread to complete.

Games are realtime applications. Realtime stuff has always been best handled as the only programme running. That way, you can be sure that any timing or synchronisation problems are your own fault. :D

I doubt if my hypothetical game developer would work for Microsoft. (Or not for long after this realisation) ;)

The operating system is necessary. From this comment you clearly have no idea exactly how much it is doing under the scenes and exactly how much of that is necessary to get that pretty image on your screen. The small overhead is well worth the price.

Games are not hard realtime applications. They must be able to produce frames at a frequency of about 30Hz to appear realistic. Games will suffer if the computer is under significant load, but will get 95%+ of the CPU power otherwise. An operating system with a decent scheduler will allow for programs that require high computational power and will ensure that they get it.

Getting back to the point, the game threads never have to synchronize with OS threads. This is simply because the threads don't communicate directly and can work separately without any issues.

The hassles come when threads need to access shared information. When two threads try to access a resource at once, the second has to wait until the first is finished. If a programmer allows two threads simultaneous access to a resource and one changes it problems can occur. Threads are often very difficult to debug.

Graham L
06-09-2006, 07:11 PM
No thread can run unless there's a CPU available to run it. The OS uses a CPU when it does something. An OS "with a decent scheduler... " will ensure that a task gets CPU time when it needs it. This is Windows. Windows will ensure that Windows gets CPU time when it wants it.

Yes, threads are always hard to debug. That's because they are realtime things, and it's usually impossible to ever exactly reproduce the conditions. That's why realtime applications run best on a "no-OS" or minimal OS machines. You have enough trouble with your own code, without the problems produced by the armies of MS coders.

What does the OS provide to a game? A file system. It's easy enough to handle files. The video display. It's not imposible to reproduce the calls to the video manufacturer's video driver. Access to a keyboard, or a mouse. Big deal.


What does the OS take? Memory. Lots and lots of memory. Lots of CPU time. On a range of machines from PCs to fairly large mainframes, maintaining the OS clock took about 2% of the CPU time. I've measured that. That's a very small part of the inessentials that an OS considers essential. I once wrote a programme to be run before starting a RT programme on a PDP-11.
Start: BIC #100, @#177560
END Start That turned off the clock interrupt of the OS. We needed that time.

The games might need to provide only 30 or so frames/sec. But it takes a hell of a lot of computation to do that. With 95% of the CPU, that's 95% of the time left after the monitoring and other "invisible" bits of the OS have taken what they need.

No modern OS is a "small overhead".

Look at the speed of the CPU on a dedicated games console, compared with the required speed of a PC CPU running the same game at the same "to the user" speed. There's the effect of OSs.