What does core usage have to do with 32/64 bit, Lavo? The bits effect how much memory can be addressed, it has nothing to with multithreading and core usage.

Pithlit, my understanding is that the game is mostly single-threaded. It uses one core for the bulk of the game and another for things like loading textures and the like. That recollection goes all the way back to vanilla release, though, so things may have changed.

Usually multithreading and 64 bit programs go together for games, as you need the extra CPU to handle all the memory you're using. But yes, technically they are different.

To the OP's question however, no there is nothing you can do to make the game use more of your cores. You can set the priority higher, set it so Sins is the only thing using those cores, and most importantly reduce CPU intensive settings. You're right that most graphics based settings are done by your graphics card so lowering them won't help much, but disabling things like trade ships icons and trimming your empire tree can help because it lowers the total number of elements the game is working with.

Stardock has been very clear that multithreading and 64 bit are not an option with Sins. They've been saying that since day one. There are two or three other threads on this that came up in the last 24 hours where they said it again. The engine updates were graphical updates and optimizaitons, not rebuilt from scratch which is what multithreading would require.

And yes, I can tell you a 10 player map will become unplayable. Humans can only do it because the team that is clearly losing usually quits before fleets max out. That said, for single players there will be a Rebellion optimization mod as there was for Entrenchment, so eventually you maybe able to do it with that. Hard to say at this point.

OP, if your graphics are set too high or if your graphics card(s) are dated, might be why.

They're two separate issues. 32-bit apps are fully capable of being multithreaded and using multiple cores. It's true that Sins will not be getting 64-bit or multithreading support, but again, they are two separate issues to tackle (neither of which is going to be done).

The server application I work on is a legacy 32-bit application (We're forced to stick to 32-bit due to some external dependencies we have) but it is fully multithreaded and is happy enough to peg every CPU on the system when under load (grumble grumble, optimization, grumble grumble).

I found that 64-bit comment weird too. I've written plenty of multhreaded 32-bit programs over the years. Unfortunately, a relatively small subset of programmers actually know how to do it properly without introducing race conditions or deadlock. OpenMP and Boost really don't care if you're 32 or 64 bit when it comes to threading.

As far as the game is concerned, it is most likely that the game is completely single-threaded. That second thread is more than likely DirectInput constantly checking for keyboard and mouse activity. You're not supposed to do that anymore, but back when the game initially came out that was considered normal. I'm not even sure it was deprecated back then. You're supposed to do these things through the message loop now, although DirectInput retains several great game controller features Microsoft doesn't provide in XInput -- not that it's relevant in an RTS game.

So I gather from this thread that 4 of my 6 cores and 14 of my 16GB RAM are doing nothing at all when playing Sins?

BTW Intel's new 3rd Gen chips can offload core work to other cores, don't have one yet but it will be interesting to see what this tech might do for older game engines.

64-bit did not become "mainstream" with vista. it became more readily available to consumers with vista. it wasnt until recently when vendors started shoving 6 and 8 gigs of ram into laptops left and right with win7 that it became mainstream. and i guarantee you that 99% of people still dont know or care to find out what it is. so it could be argued that 64-bit is STILL not mainstream. LogicSequence makes a good point that backs me up pretty well:

not sure on the exact technology but this page supposedly lists them all...

http://ark.intel.com/products/65523/Intel-Core-i7-3770K-Processor-(8M-Cache-up-to-3_90-GHz)

if you're fond of overclocking though, i would hold off on the ivy bridge

http://www.maximumpc.com/article/news/proof_%E2%80%93_switch_fluxless_solder_thermal_paste_cause_poor_ivy_bridge_overclocking_temperatures

The tech I was talking about is called Turbo Boost 2.0 and it comes in all flavors of the i7,i5, and i3 Ivy bridge chips and they have also upped the clock speed for multi-core procs which is very nice.

Newegg has a page on it if your shopping around.

http://promotions.newegg.com/intel/12-1596/index.html?nm_mc=EMC-IVYBRIDGE042912&cm_mmc=EMC-IVYBRIDGE042912-_-EMC-042912-Index-_-E0A-_-CPU

Thanks to the Vasari about the OC warning I am not into that myself other than built in smart OCing however for anyone who is take heed. As fast as technoligy moves I prefer to just to run at stock speeds and then upgrade to a faster chip down the line but thats just me.

I never have this problem, from the vanilla sins to diplomacy and rebellion, I am running a quad core i7 and no problem with multithread issues. My sins is pretty much spread out between the four cores with no problem. Although a good fix is to look at how much Affinity you are using when you are using the program. Make sure you are selecting <All Processors>

Siger, sins is always using 2gb max, so your 8gb of ram is pretty much useless. And since you have 16 hours of gameplay don't you think you should be receiving lag? I mean think about all of the debris. And remember these people aren't using engine like Unreal Engine 3 or CryEnigne (whichever is the most recent, 3 or 4 I don't remember it was March when it announced it). The devs wrote the entire engine by themselves so cut them so slack.

You play on a big enough map or have a game go on a long time, and it WILL CPU bottleneck. Running out of memory is actually less common unless you're using mods (which tend to increase memory use). Of course, the bottleneck isn't always fatal (if it only bottlenecks a bit its just annoying), whereas OOM always is.