multiprocessor and dedicated server

[Skal]

hi people hi,

I'm running 2 dedicated servers, and was planning to buy a third, eventually bi-Athlon XP-MP, but I've just tried on a "little" bi-PIII and it seems the second processor is not used ... quite weird, as OFP seems to be full multi-thread, I was thinking it could take advantage of a second CPU .... anybody have informations about that

C U :cool:

[Suma]

OFP is not optimized to be able to use dual CPU systems. I am not sure what is your sentence "as OFP seems to be full multi-thread" based upon.

[Mister Frag]

I have a multi-processor system myself, and the threads are distributed across all processors. That is in fact the default behavior for any process under Windows 2000 / XP Professional -- unless you fiddle with the Processor Affinity Masks, the scheduler is free to assign the threads to any processor that it wants, and even re-assign them as needed.

The programmer can set the PAM himself/herself, or you can take matters into your own hand (but not really fine-tune things) by running the IMAGECFG utility that comes with the DDK and the NT 4.0 Option Pack -- it lets you alter the image that is read by the loader so that you can restrict the process to specific processors, or any one single processor.

[Ender]

Suma:

I think he maybe used TaskInfo or a similar program and saw all the threads the game is utilizing.

Mr. Frag:

Just because it's multi-threaded doesn't mean it will increase performance. I've done a lot of multi-threaded programming, and I own a dual system so I know what I'm doing (mostly and if something is not optimized for a multi-processor system, it generally doesn't do much for you.

However, look at it this way: If you have two processors and run a game, the game will (hopefully) run on the processor with the most resources available, leaving things like drivers and other system level resources to be run by the other CPU. This of course will give you a performance increase.

However, like I said, multiple threads don't always mean a faster application. You can get into situations where one thread is waiting for another to complete before it continues execution. This causes one thread to hang for a bit, essentially reducing your application to a single-threaded app. A lot of other problems occur, like contentions when two threads are accessing the same RAM locations for extended periods and not letting other threads access it.

Most likely, the threads in OFP are light weight and probably something to do with UI, maybe network code and a few other things, nothing that will give you a huge boost on a multi-processor system.

[WisdoM]

OFP doesn't utilize the two processors theres a program at www.techtv.com that you can run in the background and it will tell you wether or not both processors are being used. And if you run it while playing OFP you will see it does not

[ScreamingWithNoSound]

Wisdom you are obviously not familiar with Win2K. W2K's task monitor can show usage for each CPU independently.

I'm in a ranty mood, so I'm gonna dumb down what Ender said (cause I like to see my own typing, K?)

Modern games programming for Windows, is, by it's very nature, multi-threaded. As most PCs that play games are going to have 1 CPU, then those threads need to be arranged and optimised for 1 CPU, this, sometimes, can cause problems when you try to run on 2... is it Q3, or UT that runs like a dog on 2 CPU, unless activate the 2 CPU architecture/change the *.exe?

[ScreamingWithNoSound]

I'm a wannabe, can I have a job? LOL

[ScreamingWithNoSound]

I'm stupid, Wisdom, I appologise.

[Mister Frag]

Ender, I write multi-threaded network code for a living, so I'm not exactly ignorant of the issues. I currently write code to handle credit card and electronic check transactions on SMP systems. Prior to this, I spent the better part of the last decade as a Principal Software Engineer in Symantec's Peter Norton Group and in Hewlett-Packard's OpenView division. In fact, I can't remember the last time I wrote a single-threaded application.

The point is that a multi-threaded application will always run faster on an SMP system, provided there are no thread synchronization issues where one blocks the other through a critical section, mutex, or another type of synchronization object.

If you have two threads and a single processor, they are scheduled according to the process' base priority class and the invididual threads priority. If both have the same priority, they are allocated the same CPU quanta, and scheduled to execute alternatingly. Even though there are multiple threads on one CPU, the CPU can't really execute multiple threads at the same time.

If you have more than one CPU however, each thread can execute independently on a separate CPU, and the only time there will be any waiting is when shared resources need to be accessed.

So yes, even if a multi-threaded program hasn't been specifically designed to run on a system with multiple processors, it will execute in less time on such a system.

[Mister Frag]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">Quote: from ScreamingWithNoSound on 5:46 am on Dec. 5, 2001
<Snip>
Modern games programming for Windows, is, by it's very nature, multi-threaded. As most PCs that play games are going to have 1 CPU, then those threads need to be arranged and optimised for 1 CPU, this, sometimes, can cause problems when you try to run on 2... is it Q3, or UT that runs like a dog on 2 CPU, unless activate the 2 CPU architecture/change the *.exe?
[/QUOTE]<span id='postcolor'>

One has to try very hard to get the poor results that Quake shows on SMP systems. The problem isn't with multi-threaded programming in general, but extremely poor software design and faulty thread synchronization on the part of the Quake developers -- Quake has "my first multi-threaded application" written all over it.

I can't count the number of times I've seen examples of this, such as using global variables instead of events to synchronize threads...