Im not going to [censored] too much. I shouldnt get a cpu bottleneck with a 6 core cpu but i do. I also should be able to play this game on ultra with one 2010 gpu and i cant with 2.... enough said

I do multi-threaded programming, and I can tell you for a fact that it's damn hard to make an app use all CPU cores effectively. It requires the software to split up any work into a bunch of small tasks that can be run concurrently, and then the results have to be gathered and processes.

Sometimes it's impossible to break down the work into enough concurrent pieces, and you end up having to do a bunch of work back-to-back. This means you can't spread the load between the CPU cores. You also have to watch for all the gotchas that come with multi-threaded programming, such as race conditions, concurrent variable access, and cross-thread synchronisation.

I'm not apologising for Bethesda here. I'm simply stating why things are the way they are.

Yea, i want a patch for my dual Octocore's !

gamesas has far more important things to worry about patching than a "fix" for 6-core CPUs. The bottom line is that there is virtually no game in the market that can even make use of more than 4 cores, while 6 cores are reserved mainly for rendering and other things. Additionally, multi-core support isn't "broken" in this game; the bottom line is that it's just not included in the engine. The game barely makes use of more than 2 cores, let alone 4 or even 6, but that's because the engine doesn't support it; there's nothing that a patch could do to add a performance increase with more cores.

i can't see it being to difficult for it to offload the npc scripts to the other cores for example....

I've seen how multi core programming can be done.. it's just a matter of optimising everything in a way to make use of it... There are always "simple" solutions to what seems like a overly complex task...

http://en.wikipedia.org/wiki/Amdahl%27s_law

Games have a lot of sequential code in them that is very sensitive to timing errors so the speedup is actually very poor in some cases (Very dependent on the engine). In the worst case scenario you can actually write programs that run slower in parallel than in series operation due to the overhead you can introduce.

Am I right in saying that even if the engine did spread some tasks to other cores, one core still needs to control the game and would be limited by the clock speed as to how quickly it worked?

Skyrim uses more than 30 threads already.

The problem is that there is one thread which is very CPU intensive. Usually that one thread uses up the power of one core completely. All other threads are distributed over the other cores and cause no slowdown at all. But that one thread limits the overall performance.

As NZGeek already wrote, it's not that easy to split up that one thread. So please stop saying that the programmers are incompetent or lazy or whatever, they're certainly are trying hard to make the game run as good as possible. But you always have to make a tradeoff somewhere.

It's no coincidence that there are hardly any games with that kind of a huge, seamless world combined with that level of detail AND huge range of sight. It just causes a load of problems for the developer.

B1gBadDaddy got it right, by the way. Only the CPU clock helps with Skyrim, because it speeds up that primary thread.

I've done alot of multithreaded programming and I would say that's not entirely correct. Multiple cores could "control" the game however it would be fairly complicated and probably not worth it. The amount of over head required to make skyrim more multithreaded just wouldn't be worth it overall(both in terms of bethseda's time and in processor time).

The way I see it, having a 6 core machine allows you to multitask much more and much better, but if your not multitasking then theres not much of a difference between 4 core and a 6 core.

The big thread is probably the manager thread that keeps the world synchronized properly and the other ones are either worker threads or threads with specific functions like sound/video/IO/etc...

It normally is extremely hard to impossible to break up the dispatcher without relaxing the required sequential nature of the program so if you like your forward consistent timeflow it takes a lot of work to build good parallel code. Not to mention the various platforms probably complicate things already as you need to make sure it works on all of them or can scale properly.

Because the engine (from what I can tell) wasn't designed from the ground-up with heavy multi-core use in mind, it would take an enormous amount of refactor across the entire engine to make it a reality. That's never going to happen for the existing release. The best we can hope for is a few quality, thorough optimization passes isolating bottlenecks in the code and refining them as possible.

They certainly may also come across some work that can be offloaded in theory but as rightfully mentioned a number of times in the previous posts, something you "think" should be a simple thing to do more times than not will bite you in the ass so many times it's not funny. That's why it needs to be accounted and designed for at conception. Trying to reto-fit heavily asynchronous code into a massive code-base that wasn't designed with that in mind is hard as hell and prone to a huge amount of bugs every step of the way.

i honestly think that the game could make better use of the multiple cores but it was designed with capability in mind.. (don't laugh at that.. we all know about CTDs in one way or another)..

I'd be quite happy to know how it's vanilla setup actually works.... what is being done by what core. How the threads are spit up, We already know the havoc/physics system has it's own.... graphics.... scripts... AI..... etc and so forth.

First need to know how these are being handled, and perhaps if there are known and guaranteed working INI options that could potentially change the above.

I'm not one to dwell on placebo effects... i want some raw data showing that any of the current "multi threading" suggestions out there actually have an impact and how.

I was looking through some havoc info and noticed a few cases where physics precision can be increased significantly provded the cpu can handle it.... able to offload sets or invidual physics calculation per core/HT core which obviously the more your ramp up, the more load across the board.

We just have to understand how skyrim works first before really debating anything else.

It's just unfortunate that a developer that may know likely isn't going to ever respond to these questions....

Indeed sir and what u say is quite brilliant. By offloading some simple tasks u can even make more efficient use of multi threading without it being to complicated as well, but hey consoles first PC second

Right. Maybe once they get all the glitches and issues hammered out they'll start showing up but we won't be holding our breath for it.

For clarity since I see some process thread counts being mentioned, just because something is on its own thread / fiber doesn't mean it's automatically intended to run fully asynchronous without having to ever wait or sync to other code. There are very likely any number of joins / waits / mutex / locks against resources and for proper sequencing. I'm not a DX or game code expert at all but there are some hovering around the boards and from what I've seen mentioned by a couple, one of the massive underlying issues revolves around the ability of the pipeline in relation to DX9 to be able to do good (or any) threaded execution, so even if the engine were absolutely stellar in design for threaded execution the DX9 issue would still remain.

Considering that the engine was intended to be the 'next' engine it should have been quad core/thread optimized.
Cryteck Cryengine 3 is optimized to work with up to 8 threads and on my quad core I notice that all cores are pushing +90% when the game is active. It can be done the catch is that optimizing for multi-thread in games is not as common as it should be.

It's not a brand new engine, it's that good old Gamebryo from Oblivion. As it's already been stated, it's hard to "parallelize" a program that wasn't built with this idea in mind.

Basically Gamebryo is in receivership (Went under sortof) and Bethseda has a source code license to modify the engine freely. So they probably just took engine development in house and took all the baggage it had in previous games as well.

Gamebryo was designed before multi-core processing became commonplace only now is it widespread to have dual/quad core computers. Also doesn't the engine is not very good at a GPU/CPU balance for calculation load as the game is highly CPU bound.

Plus Crytech are probably a lot more specialized in making game engines than Bethseda as they intend to sell licenses for the engine.