Fixing core parking

[Loney 22]

Today I ran SC4 in windowed mode with Window 7's Resource Monitor open next to it and anti-virus off. After running the time simulator at full speed on a 4 million-pop city, I noticed that cores were rarely parked for more than five seconds.

Odd, SC4 uses only one core, and I set it to use one core so the OS doesn't bounce SC4's thread around on the cores. While one core was at 100%, all of the other cores had 0%-5% load. That prevented the core that SC4 was using from ever being turbo boosted past 1.73 GHz for more than a few seconds.

I was told that setting processor affinity for background tasks is an invitation for a crash, but is there a way to safely force all of the background tasks on one core? Or better yet, stop the OS from bouncing the threads around?

OS: Window 7 SP1 Home Premium 64-bit

CPU: i7 720qm (4 cores, 8 threads, 1.60 GHz)

RAM: 8 GB

GPU: Mobility Radeon 5730

[tungston 19]

I suggest you let the game run on all 8 threads, you will get better performance.

[z1 566]

I suggest you let the game run on all 8 threads, you will get better performance.

Why do you think so? It never uses more than a single thread at a time.

[A Nonny Moose 8,261]

I suggest you let the game run on all 8 threads, you will get better performance.

Why do you think so? It never uses more than a single thread at a time.

Worth a comparison test. Skewing an operating system's algorithms usually has a serious overhead cost. I have only a dual processor, but the game runs quite happily without messing up the dispatch queue with priorities.

And, hey Tungston, I thought the i7 was only a quad processor. Do they have dual pipelines?

  Edited November 14, 2011 by A Nonny Moose  

[Loney 22]

I suggest you let the game run on all 8 threads, you will get better performance.

Why do you think so? It never uses more than a single thread at a time.

Worth a comparison test. Skewing an operating system's algorithms usually has a serious overhead cost. I have only a dual processor, but the game runs quite happily without messing up the dispatch queue with priorities.

And, hey Tungston, I thought the i7 was only a quad processor. Do they have dual pipelines?

The i7 Nehalem, the type of microarchitecture that my processor has, ranges between 2 to 4 cores. The newer i7s, the Sandy Bridge, have between 4 to 6 cores.

The i7 I have is quad, but it also has hyper-threading. I see eight cores in the Resource Monitor, and four of them are almost always parked. I'm assuming those are the "pseudo" cores.

[A Nonny Moose 8,261]

I suggest you let the game run on all 8 threads, you will get better performance.

Why do you think so? It never uses more than a single thread at a time.

Worth a comparison test. Skewing an operating system's algorithms usually has a serious overhead cost. I have only a dual processor, but the game runs quite happily without messing up the dispatch queue with priorities.

And, hey Tungston, I thought the i7 was only a quad processor. Do they have dual pipelines?

The i7 Nehalem, the type of microarchitecture that my processor has, ranges between 2 to 4 cores. The newer i7s, the Sandy Bridge, have between 4 to 6 cores.

The i7 I have is quad, but it also has hyper-threading. I see eight cores in the Resource Monitor, and four of them are almost always parked. I'm assuming those are the "pseudo" cores.

That is what I have believed. The so-called hyper-threading is what we members of the old guard call dual-predictive pipelines. That is, if the program encounters a conditional branch order, it assumes that it will take it and starts fetching the alternate path in the other thread (pipeline, list of instructions to do next). If the branch occurs, the processor switches pipelines (instruction lists) om a few nanoseconds and the instructions at the branch have already been at least partially fetched, operands and all. The last mainframe I used (1990) had a nine-level predictive pipeline per processor with up to four asynchronously operated processors. A CPU could start fetching instructions and operands into cache from nine threads in a cascade where conditions were built like a switch in a C program (this is sometimes called a jump table).

Most of the benefit from this kind of processor trick lies with the operating system because coding for this has to be done at a very low level unless you have a very, very smart compiler. Because .NET and ECMA standard programs (mono on Linux) can use canned CLI on-the fly calls to libraries of precoded objects, this should improve as this programming technique begins to permeate development shops. The average program run by a home user probably won't see this unless you are running a new, fancy graphics package or other computer intensive program that can multi-process and is written for it. I don't think most gaming companies would take the trouble as it is expensive to do.

The question that arises from the term multi-threading is why Microsoft invents new terminology all the time. It is probably just to hoax the yokels. It was bad enough when the International Brotherhood of Magicians invented the word byte when everyone else was using octet. If you've got a big chunk of the market and a large customer base, you can get away with this kind of thing.

[Loney 22]

Intel was the one to come up with the term, "Hyper-threading": http://en.wikipedia.org/wiki/Hyper-threading

For SC4's CPU priorities, I left that alone.

[tungston 19]

My latest machine has an Intel i7 K875 quad with hyperthreading. When I play my larger cities, 600K to 900K, then there can be activity on all 8 threads, with CPU usage from 140 to over 160 percent. That is the same type of results I have seen with my dual, and quad processors, except no hyperthreading.

Why do you think so? It never uses more than a single thread at a time.

I don't know why yours doesn't, but since my first dual processor, the game has always used all cores.

[z1 566]

Why do you think so? It never uses more than a single thread at a time.

I don't know why yours doesn't, but since my first dual processor, the game has always used all cores.

It will use as many cores as are available (or as you tell it to), but the game consists of a single thread, so the total usage on all cores can never be more than about 100% of one core. (It might be a tiny bit higher due to switching overhead.) As to the 140% to 160%, there must be other unrelated processes running; you can't get those numbers from a single thread.

[tungston 19]

Why do you think so? It never uses more than a single thread at a time.

I don't know why yours doesn't, but since my first dual processor, the game has always used all cores.

It will use as many cores as are available (or as you tell it to), but the game consists of a single thread, so the total usage on all cores can never be more than about 100% of one core. (It might be a tiny bit higher due to switching overhead.) As to the 140% to 160%, there must be other unrelated processes running; you can't get those numbers from a single thread.

That's kind of what I said, there are multible cores being used.

There is nothing using the processor to speak of, if I shut the game down the CPU usage goes down to almost zero. If you don't take my word for it, that's OK.

[tungston 19]

My understanding in a simplified, nontechnical way of how multi-core processors work, is that the application, the game in this instance, sends a request to process code to the OS, which then sends the request to the front side bus [chip set]. The front side bus then determines which core is not busy, and sends the request to that core. Once the code is processed it can then accept another request from the OS, which can then accept another request from the game. When you have more cores working, then the requset get processed that much faster.

If you limit the processor to one core, and it is running at 100%, then that core is creating much more heat than if the processing was spread out over more cores. Once the heat gets to a certain point the CPU will slow down to cool down.

[Gringamuyloca 47]

My understanding in a simplified, nontechnical way of how multi-core processors work, is that the application, the game in this instance, sends a request to process code to the OS, which then sends the request to the front side bus [chip set]. The front side bus then determines which core is not busy, and sends the request to that core. Once the code is processed it can then accept another request from the OS, which can then accept another request from the game. When you have more cores working, then the requset get processed that much faster.

If you limit the processor to one core, and it is running at 100%, then that core is creating much more heat than if the processing was spread out over more cores. Once the heat gets to a certain point the CPU will slow down to cool down.

... so why does switching to one core only have such a huge impact on reducing the number of crashes? (For me anyways... the only time my game crashes now if it is 'self-induced'.)

[A Nonny Moose 8,261]

My understanding in a simplified, nontechnical way of how multi-core processors work, is that the application, the game in this instance, sends a request to process code to the OS, which then sends the request to the front side bus [chip set]. The front side bus then determines which core is not busy, and sends the request to that core. Once the code is processed it can then accept another request from the OS, which can then accept another request from the game. When you have more cores working, then the requset get processed that much faster.

If you limit the processor to one core, and it is running at 100%, then that core is creating much more heat than if the processing was spread out over more cores. Once the heat gets to a certain point the CPU will slow down to cool down.

... so why does switching to one core only have such a huge impact on reducing the number of crashes? (For me anyways... the only time my game crashes now if it is 'self-induced'.)

This kind of thing is operating system dependent. If the switching algorithms get their wires crossed the default action is to scrub the offending process. This is in addition to the regular crashes. Also, the faster the processors the more frequent the chance of a crash. The game seems to be quite sensitive to being overloaded. I run only a dual processor, but I can run my system monitor and watch the game switch between processors as the dispatcher finds it in the queue and sends it to whichever processor is next. With four CPU's each with a dual pipeline, you could theoretically wind up in any of the pipelines. I expect, however, that unless you are running a lot of stuff at the same time, you won't see that.

Other than one-upmanship, I am at a loss to understand why a home system needs quad cores and dual pipelines. You would only need such a machine if you were, for example, an engineer working from home and running some of the big design packages.

  Edited November 15, 2011 by A Nonny Moose  

[tungston 19]

... so why does switching to one core only have such a huge impact on reducing the number of crashes? (For me anyways... the only time my game crashes now if it is 'self-induced'.)

Since I have moved on to Vista, and them Win7, I don't have game CTD. My only suggestion would be to carefully examine your plugins, and how many different creators of custom content you are using.

[tungston 19]

... so why does switching to one core only have such a huge impact on reducing the number of crashes? (For me anyways... the only time my game crashes now if it is 'self-induced'.)

Since I have moved on to Vista, and them Win7, I don't have game CTD. My only suggestion would be to carefully examine your plugins, and how many different creators of custom content you are using.

Edit: There are many possibilities, drivers that could need updating, besides sound cards, etc., motherboad, chipsets, maybe even the BIOS. When you dedicate to one core nothing can enterfer with the game. If you use all cores, then the background apps can, including the antivirus.

Overclocking is one major reason for crashes with the game.

[A Nonny Moose 8,261]

Coming back to the original topic. What is it you want to fix? The operating system will optimize the use of your processors depending on queued demand if you don't interfere with it. If some threads are idle, it is because there is nothing for them to do. With an i7 system, you would have to be running at least six heavy processor use applications (leaving two threads for the system) to get all 8 threads operating. Most applications spend their time in the wait queue holding for i/o completions. The technology and algorithms for dispatching jobs to processors has been beaten to death and is well known since the Atlas 8. That processor ceased production sometime in the 1950s, and there is nothing new under the sun. Just fancier, cheaper hardware.

I think I said earlier that there are only specific conditions in which a high throughput chip was justified for a home user.

[bluemoose 223]

My game gets really crash-y if it uses more than one core. I always set my affinity to the third core only, and it does wonders for stability, but does lower the speed. If I don't do this, My game will most certainly crash after a quick zoom, or large construction.

  Edited November 16, 2011 by bluemoose  

[tungston 19]

The bigest benifit of the later model i7's is the memory handler is on the processor, and doesn't have to go through the front side bus.

[Loney 22]

If you limit the processor to one core, and it is running at 100%, then that core is creating much more heat than if the processing was spread out over more cores. Once the heat gets to a certain point the CPU will slow down to cool down.

There's one problem, when I'm running SC4 without forcing it to one core, all of the cores report 25% load while SC4 is running like molasses. I see as not thread spreading, but thread bouncing. I'm fairly sure a processor with two loaded cores and the other two cores parked would produce less heat than a processor with all cores loaded.

Other than one-upmanship, I am at a loss to understand why a home system needs quad cores and dual pipelines. You would only need such a machine if you were, for example, an engineer working from home and running some of the big design packages.

If you're only web browsing and typing, a quad core would be an overkill as a dual core would be sufficient.

However, for gaming, quad cores are recommended since more and more newer games support more than two cores. Hexa-core is often considered an overkill for gaming.

On my old laptop, even though the dual-core T7200 (2.0 GHz, Core Duo 2) processor has similar performance for single-threaded benchmarks/programs, one of the games that I frequently play uses more than two cores and there's a noticeable lower performance. Even with graphics set to absolute minimum, the quad core outdid the dual core in frame rates per second.

Coming back to the original topic. What is it you want to fix?

How do I get Window 7 to recognize that I don't need all four cores active for a large single thread and some background tasks? And if there's no solution to that, how do I turn off two of the cores to force Turbo Boost to kick in?

  Edited November 17, 2011 by Loney