It's not about "changing things" we are talking about an issue running synthetic stress tests with adaptive voltage. But of course, insane or not, a multitude do dive in and change things! And of course a multitude of those with only a modicum of experience do indeed run Prime95. I recall I did while being way less experienced than I am now.

 

There's really nothing wrong with prime95 even on Haswell and above. The generally accepted solution for people truly worried about auto-voltage is to use older versions of prime95 (27.9 or lower) because the lower versions have little to no AVX support but are still valuable for testing system stability under high stress loads.

 

As for inexperienced people overclocking, I would think that if they're so inexperienced that they don't know to look before they leap, then they aren't likely to be looking on the Asus forums either, and are pretty much doing the equivalent of testing an electrical socket with a fork. Some things certain people have to learn the hard way. 

 

Not wanting a fried system, I did do my research, and probably one of the first things I saw mentioned repeatedly was to be wary of auto voltages when overclocking. In fact right now, the vast majority of my voltages are manual to avoid just those types of issues (and I wouldn't say I was any sort of master overclocker) I don't have a problem with Asus issuing a recommendation, but I do take it with a big grain of salt being directed to a paid product over a free one that's been working fine for years.

 

Many do still use Prime95 yes, but many experienced overclockers have stopped using it. Personally I don't. I find it more efficient to use stress tests that are closer to the  software I run in everyday use. 

 

It's just a choice, really. Red or blue. Except blue is free......  :unsure:

 

And as you acknowledged, pointed up a real problem that the other one probably would not have.

To be fair to anyone overclocking their PC, nobody I've met in 30+ years knows exactly what all the BIOS/EFI settings do ... a team (not a single person) of Asus engineers can probably shed some light, but it would also require insight from Intel EE's and any other EE involved in memory, motherboard, chipset, cpu, etc.

 

Honestly, 97% of it is trial and error ... I've searched high and low for EE's willing to share information since I started doing this 30 years ago ... none have provided repeatable evidence of claims about certain settings and always comes back to "try and see" ... which is fine, but the implications are obvious.

 

Most of the YouTube "how to" and "guides online" cover at most 1/1000 th's of BIOS/EFI options ... what they don't know always falls into "leave it alone" or ignore it. Logic would dictate that if the settings are available in the BIOS/EFI then they have a purpose. Ask someone what is XYZ BIOS setting actually doing and the answer is almost always "try this value" ... no real definitive understanding provided of the option in question.

 

Ultimately I think the root of the matter is the desire to add more cores in less space using less power as fundamentally NOT good for desktop computing ... why not use more space, have fewer cores (less heat issues), operate the processor at higher frequencies and require more power ... that's what desktop consumers/computers are built for -- why isn't Intel doing that?

 

For any game ...threading has finite limits, more cores doesn't always help ... in order to render a frame in a 3D sequence that is "time" based and makes virtual sense, their MUST be a synchronization thread and that is one and only one core operating (usually the one core doing most of the work).

 

More cores are good for things like rendering/compressing video where there is NO time constraint, thread runs until its done and works on the next chunk, it doesn't have to finish in any order cause it's not "real time" ... key being "time". Or more cores work well when you have multiple applications open working from RAM (keep in mind I/O is serial - hence SATA) so requests are queued ... wait your turn not a free for all.

 

Intel is out for profit (fair enough), no secret, but they aren't delivering what desktop users want, they're delivery what makes the most money for Intel. Look at the rumored next Intel 10C/20T chip 6950X - how long is Intel just going to keep up the "dog and pony" show with more cores at lower and lower frequency? IMHO, this IS going to be a significant problem for desktop games/simmers ... I'd much rather see 4 core CPU at 6Ghz than a 10 core CPU at 3Ghz.

 

Cheers, Rob.

Ultimately I think the root of the matter is the desire to add more cores in less space using less power as fundamentally NOT good for desktop computing ... why not use more space, have fewer cores (less heat issues), operate the processor at higher frequencies and require more power ... that's what desktop consumers/computers are built for -- why isn't Intel doing that?

 

"Desktop computing" is increasingly Office and web browsers, and for most of those use cases processor speed has been "fast enough" since Core 2, a half decade ago. The biggest gains have been through faster I/O (SSDs) rather than faster CPU speeds. To be fair to Intel, a Haswell core (Skylake is faster) is around 50% faster at equivalent speed than Conroe and I've now got twice as many of them. It's also worth noting that a much larger percentage of people are using notebooks and other battery-operated computers. If something takes 10% longer they don't care. If they lose 30-90 minutes of battery, they will.

 

On the server side, more cores is almost always better. Web services and big data crunching has all moved towards the Google model of large numbers of less powerful commodity hardware. When we ran our own environment, we bought lots of high core count machines to run as VM hosts - we didn't need raw single-threaded speed, we needed great I/O capacity and concurrency.

 

Intel isn't stupid. They're not just maximizing their profits, they're listening to their high volume customers who are paying for decreased power consumption and higher core density. Those guys buy more CPUs in a day than we do in our lifetimes - and they don't care too much about raw Ghz or single-threaded performance. If you're buying 10,000 Xeons for a virtual machine farm, why would you? You'll take a $50,000 savings in power any day.

 

Much of the world has moved away from raw, single-threaded computing. It's harder, and more complicated - but it scales and takes advantage of what performance you are getting from the chips these days. We're getting to a point with process size and clock speed that there are certain basic laws of physics that we can't simply or easily overcome at present. Flight simulators seem to be an anomaly - most video games are designed for consoles that have a fraction of the video and CPU capacity of a reasonably modern desktop. If the consoles can do it, why not a PC?

 

Cheers!

 

Luke

Hey Luke,

 

Desktop/Server CPUs are only 43% of Intel volume sales numbers, however, that's almost 80% of Intel's revenue.  Basic office/web work is shifting over to mobile (laptops, tablets, etc.) but when I look around my office, we have about 6 laptops (only 2 Intel based), and 20 desktops (all Intel based), and 4 or 5 servers (all Intel based) ... and of course everyone has a smart phone (multiple in some cases).

 

There's more profit to be had per Desktop/Server CPU ... however, Intel's majority resources (based on release frequency/schedule) appear to be focused on mobile/laptop computing ... in other words neglect one market in order to get a foothold in another.  This seems to be a common flaw in the executive ranks, overreacting to shifts in demand rather than a more planned and careful approach ... believing if they don't get in "now" they'll never get it ... old school thought process.  In today's world, if you deliver they will change brands and buy ... the Global market has more diverse buying power today, than it did 10 years ago.

 

I'm not suggesting a segment be excluded, every market segment certainly has it's place. 

 

But the consoles can't do it ... have you tried consoles?  It's just another cost compromised product ... for some it's enough and fits the price point, but for other's it's not - not even close.  When I compare it to what my PC can do it's like I went back in time a decade or so, the last time I operated at 1080p was 2005 and with AA as bad as it is in a console game.  I'm not knocking consoles, they fit a particular market segment, but that's NOT the only market segment out there.

 

It's always a balance, never all or nothing -- what we have is executive panic (Microsoft is another good example of OS panic).

 

Maybe AMD can bring some "Zen" to wake up Intel desktop resources again ... a remote hope.

 

Cheers, Rob.

Basic office/web work is shifting over to mobile (laptops, tablets, etc.) but when I look around my office, we have about 6 laptops (only 2 Intel based), and 20 desktops (all Intel based), and 4 or 5 servers (all Intel based) ... and of course everyone has a smart phone (multiple in some cases).

Out of curiosity, what was driving those purchasing decisions, and how old are the machines?

 

I ask because at my last office job (a relatively well-known digital property), pretty much the entire digital engineering group and senior management had switched to Macbooks five years ago. Over that time, a "faster" computer CPU-wise was almost never in demand. Instead the Airs were coveted for their small size. On the engineering side SSDs and Retina displays were coveted when my annual equipment upgrade budget needed to be handed out. Going back to a regular Macbook with spinning rust felt awful. Losing 500Mhz of CPU speed? Meh.

 

I would expect that in a lot of non-technical places, cost drives a lot of the purchasing - as well as the upgrade cycle. It used to be that after 2 or 3 years upgrading to the new current standard would provide a very noticeable boost in performance. Nowadays, the upgrade cycle can stretch to 5 years and usually what kills those machines is a lack of vendor support rather than being too slow - or like in my group's case, features outside of the CPU.

 

I'm not sure what market you feel Intel is excluding. The general purpose home or business desktop generally has more than enough horsepower (an i5 is usually overkill, never mind an i7). Mobile focuses more on battery and form factor (think of the Macbook Air and how little CPU power it has) and server side is all about wider and efficient versus raw single-core throughput.

 

Needing massive single-threaded performance to me is a sign of poor coding. Amdahl's law would dictate that you won't get linear performance increases with core count, but it shouldn't be too difficult to keep 2-4 cores busy. You just can't get there with a simulation engine designed around a single core - you have to design that from the ground up.

 

That's what I think we need, more than 64-bit. We need a proper multi-core sim engine.

 

Cheers!

 

Luke

Various reason for our purchases ... our developers (of whom I loosely govern over) use a multitude of equipment from phones to tablets/ipads to laptops to desktops.  IT guys for servers, sales and CEO mix of desktop/laptop, support folks typically is desktop with one or two rotating 24/7 support on a laptop.

 

Best computing resource I've ever own has been my MacPro ... but sadly because of such slow and infrequent updates from Apple I shifted over to a home built PC running Windows and it runs circles around my old MacPro.

 

It really depends on what the company does ... a company that occupies the floor above us is all CAD and AD ... all desktop computers, all 2-3 large monitors.  When I worked for BofA in the real estate group most execs couldn't even figure out how to get eMail so their PC's were extremely under utilized (complete waste of money to be honest).

 

 

 

Needing massive single-threaded performance to me is a sign of poor coding.

 

Completey disagree with you on that ... we have a multi-core engine (you'll never see equal utilization across all threads):

 

 

Quote from this link: https://www.microsoft.com/Products/Games/FSInsider/developers/Pages/GlobalTerrain.aspx

 

 

Regarding Threads, Fibers, and Multi-core Architectures

Many of the tasks performed by the terrain engine, including the ones described in this paper, cannot be started and run to completion in the interval between consecutive rendered frames.

Some of them would take several seconds to run even if 100% of the processor time was devoted to them.  What's the best way to execute these tasks without negatively impacting the frame rate or its stability?

One possible solution is to run them on threads separate from the main render loop.  In practice, however, threads alone may not be the best solution.  The main reason is because the terrain engine's tasks are processor intensive and they can easily starve the game's main loop of processing time.  Worse yet, the terrain tasks come and go intermittently which would cause the frame rate to fluctuate.

In theory, lowering the priority of the terrain threads should prevent the main game thread from being starved.  However, the game thread is also pretty busy so that would increase the risk of starving the lower priority terrain threads.

A better solution, based on our experience, is to run most of the terrain engine tasks on Win32 fibers.  Fibers are similar to threads in that they each have their own context (i.e. register state and call stack).  However, the scheduling of fibers is entirely up to the application using them.

With fibers, Flight Simulator can schedule the terrain tasks to run in the interval between iterations of the main game loop and not during rendering or other time critical operations.

Fibers do have their down side, however.  Flight Simulator's fiber scheduler is cooperative, which means the fiber tasks must periodically call back into the scheduler to see if it's time to yield.

While this takes some getting used to when writing code, it does simplify the job of synchronizing data between fibers and the main game loop because all of the possible points of preemption are known.

Recognizing the increased availability of dual-core processors, we plan to execute some fibers in a single thread on the second core.  Fiber tasks that exchange data only with other fibers on the same core can still lightweight synchronization, but any data exchange with the main game loop or other fibers running on the primary core must be fully synchronized obviously.

 

I don't know of a way to get around the synchronization?  Sounds like you might have solutions/ideas?

 

Cheers, Rob.

For the time being the massive single-threaded performance is the way to go, simply because of the current technology in place hardware and software. But, I also agree with Luke, in that this should not be necessary in theory with many cores. In practice breaking up simulations into smaller pieces gets very complicated. However, algorithms are emerging to embrace that paradigm at a pace. I've been evolving an algebraic technique of my own that moves mathematical criteria out of a system to be calculated elsewhere in many parallel threads with minimum impact. It's not immediately obvious how to go about it, and certain techniques of the kind may require operational overhead that mean they won't work so well until we truly have many cores, hopefully in the near future.

There's really nothing wrong with prime95 even on Haswell and above.

 

 

 

To be clear, Asus aren't saying ban Prime 95, or use it at your peril, Prime95 is evil. They aren't even saying don't use it.They are merely stating that they as a company don't recommend it. They fully recognize that many overclocking enthusiasts still use it. In fact, in a recent video on their PC DIY web site they ran prime95 to demonstrate the stability of their 5 way optimization overclocking. It was explained in the video that they did this because they recognize many still use it.

 

 

 

As for inexperienced people overclocking, I would think that if they're so inexperienced that they don't know to look before they leap, then they aren't likely to be looking on the Asus forums either, and are pretty much doing the equivalent of testing an electrical socket with a fork. Some things certain people have to learn the hard way.

 

 

No that's not true. They are looking before they leap...on the Asus forums. I was perusing the ROG forum yesterday, there are a multitude of less experienced individuals there seeking knowledge. Thus it's valid that Asus should provide that information in their articles, videos and forum posts. Why you object to Asus providing information for beginners makes no sense.

 

 

Not wanting a fried system, I did do my research, and probably one of the first things I saw mentioned repeatedly was to be wary of auto voltages when overclocking.

 

 

And that's precisely what inexperienced users are doing on the Asus forums when they ask questions and read the articles there. They are doing research like you did. And so it's right that Asus provide that information.

 

 

I don't have a problem with Asus issuing a recommendation, but I do take it with a big grain of salt being directed to a paid product over a free one that's been working fine for years.

 

 

What paid product? ROG Real Bench is totally free. 

No that's not true. They are looking before they leap...on the Asus forums. I was perusing the ROG forum yesterday, there are a multitude of less experienced individuals there seeking knowledge. Thus it's valid that Asus should provide that information in their articles, videos and forum posts. Why you object to Asus providing information for beginners makes no sense.

 

I don't have a problem with Asus issuing a recommendation, but I do take it with a big grain of salt being directed to a paid product over a free one that's been working fine for years.

 

So that's not exactly what I'm saying. I do say that when you are explicitly speaking of damage to the cpu or motherboard, your recommendation  can't help but be taken as a deterrent to using the software being discussed. Asus can do what they want, but this information is ancient (at least back to the first implementation of AVX when ASUS reps began appearing in Newegg videos expressing their preference for programs other than Prime95, and recommending Aida64, which is indeed a paid program and where the issue first raised eyebrows and stuck with me.

 

www.youtube.com/watch?v=4mkGQhE1o2w&feature=g-all-u#t=3m56s

 

Or: http://www.hardocp.com/article/2013/06/01/intel_haswell_i74770k_ipc_overclocking_review/7#.VqOEbSorKUl

 

ASUS warned us against using synthetic stress tests like are shown above.

 

Unvalidated stress tests are not advised ( such as Prime 95 or LinX or OCCT, Intel Burn Test or other comparable applications ). For high grade CPU/IMC and System Bus testing Aida64 is recommended along with general applications usage like PC Mark 7. Aida has an advantage as it is stability test that has been designed for the Haswell architecture and tests specific functions like AES, AVX and other instruction sets that prime and like synthetics do not touch. As such not only does it load the CPU 100% but will also test other parts of CPU not used under applications like Prime95.

 

Other applications to consider are SiSoft 2013 or Passmark BurnIn. Additionally this generation has a more specialized point of consideration for synthetic stress tests. When using an adaptive vid voltage control will be automatically controlled by the iVR when a complex concurrent AVX load is initialized from Applications like Prime95 or Aida Or LinX more voltage will be supplied than has been defined/requested.

 

So we did in fact go back and test some with Aida64, which does have a 30 day trial version. (And also as ASUS told us above, we did see elevated vCore voltages as well using Prime95.) 

 

Using the Aida64 Stress Test at 5GHz we had good results. We are still seeing temperatures bump into the mid-90c range, but these are quick spikes and we only see a tiny bit of CPU clock throttling. As of writing this I am still running long term testing at 5GHz, and I have seen a bit more throttling as the system gets heat saturated, but honestly I do not truly find value in this Aida64 "stress test." The fact of the matter is that even though Aida64 shows my system to be "stable," this is not true. All you have to do is start Handbrake, and use it to encode a Bluray rip at 1080P and the system will hard-lock. Your mileage may vary, but I am going to stay old school in terms of how we decide if hardware is "stable."

 

Overclockers absorbed the information and as a general rule, moved on. It's not really fresh news. In that time the main places people looked for information were on known reliable sites with less vested interest in any particular outcome, like Tomshardware, HARDocp, Mad Onion (Now Futuremark) and many other places where the real cutting edge lived, with people using liquid nitrogen, Peltier coolers, computers in oil, and other wild, fun and interesting things.

 

That's my formative introduction to overclocking, and it didn't include manufacturer forums, because they were generally small, conservative and..... boring. You went to them maybe to find out for sure what the recommended stock voltages or temps were for this or that.... and moved on.

So that's not exactly what I'm saying. I do say that when you are explicitly speaking of damage to the cpu or motherboard, your recommendation  can't help but be taken as a deterrent to using the software being discussed.

 

 

Yes but it's still fact. And they have a duty to provide customers with the facts, on their forum, in their videos or wherever those with varying degrees of experience reside. What should Asus do, lie? Withhold important information despite knowing that inexperienced individuals will be viewing their boards? There are plenty of other sources out there that  also don't recommend using Prime 95 with adaptive voltage. If that deters people from using Prime 95 then so be it, but facts are facts, and they'd be a crap company if they withheld important information from their forum members and customers. In regard to the adaptive voltage issue with Prime 95, Asus  refer to this in their overclocking guides. So would you expect Asus not to bother, miss out important information? At other times it's referred to in their specific overclocking videos, or in answer to specific questions on their forum... should they withhold this information? Of course they shouldn't. It's not like they are going out of their way to advertise the adaptive voltage issue, or promote their profound distaste at the mere mention of Prime 95.

 

 

 

 

 

 

Asus can do what they want, but this information is ancient

 

 

 

How old it is is irrelevant, it's still valid information and valid information can and should be disseminated. Makes no sense to ban Asus from revealing information that you appear to be fine with other sources disseminating. Why the discrimination?

 

 

and recommending Aida64, which is indeed a paid program and where the issue first raised eyebrows and stuck with me.

 

 

 

Yes that's true, but I recall JJ from Asus making it clear that Aida 64 free trial version was all that was required. So no payment required.

 

 

That's my formative introduction to overclocking, and it didn't include manufacturer forums, because they were generally small, conservative and..... boring. You went to them maybe to find out for sure what the recommended stock voltages or temps were for this or that.... and moved on.

 

 

 

 

That's great for you. But as I said above, if you check out the Asus ROG forums you will see a multitude of individuals of all levels of experience, all sharing information. Therefore it's right that Asus make the facts known. And if those facts include warning of the risks of running Prime 95 small FFT's with adaptive voltage then so be it. Quite why you would deny Asus the ability to disseminate the same information as everyone else baffles me.

Completey disagree with you on that ... we have a multi-core engine (you'll never see equal utilization across all threads):

 

It's a bit of a stretch to describe that as a mature, multi-threaded engine. Keep in mind that FSX RTM was entirely single-threaded. You can't take a software architecture that was single-threaded for a decade and in the span of a service pack or two reallocate the work so that it's performed efficiently across multiple threads. I'm surprised Phil and the team were able to do as much as they did.

 

For what it's worth, there are few tasks where you get equal utilization across the threads (graphics and video processing spring to mind), nor is it typically the goal. You want to have meaningful utilization across multiple cores. If I've got four cores, one is pegged, two are at 50% and one is at 30%, I'm still doing a lot more work than I would have on a single core. Again, Amdahl's law says so unless you have a task that's completely in parallel.

 

The FSX engine made a lot of assumptions, mostly that it was on a ever-faster single-core. It reminds me of another piece of software, which is somewhat different - MySQL. There were a lot of assumptions and inefficiencies in that code base, because it assumed that it wouldn't matter since another thread was stuck waiting on slow disk I/O. Once SSDs came out and radically sped that up, code that used I/O bound became CPU/bound (or waiting on lock contention). It took them several years to finally get rid of most of it and speed it up significantly on multi-core machines with fast storage.

 

It's a little different analogy (since it was I/O bound rather than single-threaded) but it illustrates the point well - you can't radically scale code across multiple cores quickly with a legacy code base. It takes time to identify bottlenecks and split them out.

 

 

The post you quoted at the bottom is interesting. Note that it predates the initial release of FSX, so they were justifying their use of Fibers and self-scheduling the tasks. Given the processor architecture of the time, I'm not surprised that they were worried about thread scheduling - most of us were running on Pentium 4s or Athlon XPs that were single-threaded. At best we had an extra logical core on the hyper-threaded P4s.

 

That day is over. For debugging and statistical purposes, I collect data from my VA about hardware, operating system and .NET configuration. Nowadays, over 90% of my users have over 4 processors (logical and physical), and over 75% have 4 or more cores. There's a significant surplus of CPU capacity, so let the NT kernel schedule the threads and move on.

 

Regarding fibers, here's a good article, written just two years later: http://blogs.msdn.com/b/ericeil/archive/2008/05/18/when-does-it-make-sense-to-use-win32-fibers.aspx

 

Here's what I read: So in exchange for easy context-switching, you get increased memory usage, and you lose the ability to use virtually any basic software building block ever written.

 

For something like Microsoft SQL Server, which is one of the most highly-optimized apps on the planet, and which pretty much lives in its own world where memory is “cheap” and library code is suspect anyway, it probably made sense to go with fibers to help reduce context-switch overhead without having to completely re-write SQL Server.  For almost literally everyone else, it just doesn’t make sense.

 

Cheers!

 

Luke

Martin-w, you posted my reply:

 

Asus can do what they want.

 

Yet are still focusing on a point that I never made in the first place:

 

Yes but it's still fact. And they have a duty to provide customers with the facts, on their forum, in their videos or wherever those with varying degrees of experience reside. What should Asus do, lie? Withhold important information despite knowing that inexperienced individuals will be viewing their boards? There are plenty of other sources out there  that  also don't recommend using Prime 95 with adaptive voltage. If that deters people from using Prime 95 then so be it, but facts are facts, and they'd be a crap company if they withheld important information from their forum members and customers.

 

To clarify again, Asus can do what they want; but it's the users that decide if they accept that as the final and last word.... or take it with a grain of salt and move on. Recall that initially, the entire practice of overclocking wasnt recommended, and remained a nearly cult endevour until a minority of super-enthusiasts pushed the envelope outward until what was once frowned upon eventually became explicitly supported in most modern bios. 

 

At this point if you want a "safe" overclock, the bios practically does it for you. (Kind of takes the fun out of it)

 

As a practical matter, the vast majority of people seem not to bother doing even that much though, and settle instead for default and speedstep. My experience has been that those who want more however, kind of want it all, and almost by definition are going to be pushing at the edge, where rules become more amorphous and higher risk is expected.

 

If there's a real point to all of this from me, it's that as you said, people do use Prime95 and I believe with reason. Even after absorbing Asus's input people will continue to do so because it's useful, time-tested and trusted. In fact, some may trust it even more now, in that in this particular instance, it was the old reliable canary in the mine that pointed out a problem that might not have been found by a putatively safer program.

 

Yes that's true, but I recall JJ from Asus making it clear that Aida 64 free trial version was all that was required. So no payment required.

 

As in most of what I've said it's a personal choice, and mine is not to mess with programs that clock out on me after a certain period unless they provide something I can't get elsewhere, which in this instance is not the case.

It's a bit of a stretch to describe that as a mature, multi-threaded engine.

 

I don't think it is, threading has been around for decades before Ace's worked on FSX ... fundamentals of threading and the applicable paradigm hasn't changed.  You referenced two applications that are of completely different paradigm, SQL server and video processing ... neither on those require any synchronization.

 

LM have been able to successfully unload a lot of CPU processing onto the GPU (having started with P3D V2.0 at 22 fps, and now I'm at 52 fps in V3.1 - all things equal) ... this is why GPU choice for P3D is just as critical as CPU choice ... this is a good thing because CPUs have remained pretty stagnant or more accurately aren't being designed with gaming/simming as a focus.

 

The Skylake issue appears to be an Intel optimization (a rather primitive one) to make specific instructions operate faster ... and the optimization seems to be flawed.  If Intel continues to ignore the two very different application paradigms, then we'll continue to get processors focused on something gamers/simmers don't want/need.

 

Cheers, Rob.

ACID-compliant databases don't require synchronization? Wow.

 

Do you care to explain why Oracle's spent so much time splitting mutexes and properly threading their app? Do you also want to explain how you get Atomic, Consistent, Isolated and Durable in a multi-threaded environment without synchronization?

 

LM have been able to successfully unload a lot of CPU processing onto the GPU (having started with P3D V2.0 at 22 fps, and now I'm at 52 fps in V3.1 - all things equal) ... this is why GPU choice for P3D is just as critical as CPU choice ... this is a good thing because CPUs have remained pretty stagnant or more accurately aren't being designed with gaming/simming as a focus.

 

The Skylake issue appears to be an Intel optimization (a rather primitive one) to make specific instructions operate faster ... and the optimization seems to be flawed.  If Intel continues to ignore the two very different application paradigms, then we'll continue to get processors focused on something gamers/simmers don't want/need.

 

It's not a question of CPUs aren't being designed for "gaming" - it's that DirectX has reached a point where it's a good abstraction to a massively parallel computing engine (the GPU) and LM is taking advantage of it. If CPU speed was so important, why would LM be offloading tasks from a 4Ghz processor to a GPU that's barely one-quarter the clock speed? Because it's massively parallel.

 

You shouldn't lump gamers and simmers together. More and more games are being successfully and effectively multi-threaded, leveraging multiple cores.There's nothing inherent about a flight sim that would make it impossible to do, either.

 

Cheers!
 

Luke

You shouldn't lump gamers and simmers together. More and more games are being successfully and effectively multi-threaded, leveraging multiple cores.There's nothing inherent about a flight sim that would make it impossible to do, either.

 

They are the same, 3D graphics processing in a "timed" environment -- I guess we diverge ... games/sims require synchronization, SQL, Video processing does not.

 

I have yet to see a game provide multi-core utilization higher than 60% (which is about what we see in P3D) ... here is a video from the most recent DX12 game I know that claims "advanced thread utilization" - Ashes of the Singularity ... as you can see from the video, one core is higher than the rest and that's the synchronization core.  All games/sims that are "time" based will exhibit very similar core utilization ... there is no logical way around this (except perhaps quantum computing) ... if there is, you need to sell the "engine" code with demonstration code and decide what you want to do with all the money you'll get

 

 

The best we can hope to achieve in games/sim is to offload as much as possible from the CPU to the GPU.  In this sample I'm running 5 cores with HT off (I was doing some other testing).

 

Cheers, Rob.