Jump to content

Is 2.5 now CPU multi-core?


Mr_sukebe

Recommended Posts

You are talking complete and utter bullshit, please stop trying to repeat the half remembered ramblings of excuses from Bohemia Interactive.

 

Physics is NOT a good example for potential multi-threading speed ups, its THE example potential for multi-threading speedups. The same reasons we compute polygon transforms for rendering your games on the GPU (For sake of this point, you can consider them a multi-thousand core processor) is the same reason hardcore physics calculations, like used in movies, science applications etc are all done on the GPU, or more to the point multiple GPUs, which are basically what supercomputers are primarily made of these days.

 

Physics calculations are multiple, straightforward non-branching logic math solutions which have little to no potential to encounter the race conditions and data locking problems (that is the justification for why games cannot be multi-threaded) because they are just expressions of Force = A * B^C - D, as long as don't depending on trying to update that outcome for use in *THIS* frame, and only use the updated value *next* frame.

 

Considering games generally process the world in frames, usually only using the previous frames data for calculations, the data is static, you don't consider anything that happened during the execution of the current frame because than you'd need to worry about order of execution, just like in multi-core execution even if your only using 1, it'd massive headache. So you take the physics force being calculated like speed and you apply your forces like drag, acceleration, you move on, and you do this a couple thousand? Hundred thousand? Million times? You do this in parallel. You can do this in parallel a couple thousand times over on a modern GPU if you want to, because it you don't need the "if this then do that" logic that the CPU can provide, you just doing A * B^C - D and writing the outcome to a new location.

 

But if you do need to do this on a CPU, and even in a existing older designed application like DCS (Don't get me wrong, rewriting a old code base to FULLY integrate threading isn't something to be taken lightly...) you can be single threaded all you want, hit your physics part, and then go "I have 100,000 physics calculations to do, and 4 threads to do them on" 100,000 divide by 4, core 0 does 1-249,999 core 2 does 250,000 to 499,999 etc... Everyone report back when you've done your share and we'll continue in the main thread after wards.

 

And to be honest I'd be VERY surprised if this isnt already done this way in DCS already because I don't think you understand the scale and absurdity of what you're suggesting how things operate... AI is another example of a workload that can be divided, assigned, processed, and then collected back into a single thread.

 

This kind of wide, narrow, wide, narrow, design isn't really desirable because its bottle necking, and a single core has to prepare the work and handle the completion of many, and its very possible DCS is hitting these kinds of bottlenecks. But for a existing application where the complete rewrite necessary for a 'down to the inner core' threading support, it offers perhaps the only way of achieving any kind of comparison in terms of performance.

 

PS. To the guy above me praising Process Lasso, fun fact as of the last time I was naive enough to be using on my old dual core Althon64 a decade ago. All project lasso does is set CPU affinity and process priority, and close applications/services for you... Hate to break it to you but applications really don't and shouldn't have level of authority over other applications, its handled at the OS level ... So they don't...

 

Sorry to interrupt your epilogue of information but when using Project Lasso on my setup the performance is much smoother then without, especially when it comes to hitching, on a ten your old dump rig like yours I am not surprised it did nothing.

4.8 I7, 1080, TMW&T, SSD, VKB MK.IV.

Link to comment
Share on other sites

  • Replies 116
  • Created
  • Last Reply

Top Posters In This Topic

Let’s be nice chaps. After all, DCS offers the opportunity of duelling, without having to resort to behaviour un-befitting an officer

System: 9700, 64GB DDR4, 2070S, NVME2, Rift S, Jetseat, Thrustmaster F18 grip, VPC T50 stick base and throttle, CH Throttle, MFG crosswinds, custom button box, Logitech G502 and Marble mouse.

Server: i5 2500@3.9Ghz, 1080, 24GB DDR3, SSD.

Link to comment
Share on other sites

Read carefully, and you might notice I said, last time, a decade ago.

 

But unless Lasso has managed to find away to literally rewrite and force its own thread interruption logic into windows but...

 

https://bitsum.com/automation/

Process Lasso’s Automation and Control

Automation

Imagine a world where you can set process priorities, process CPU affinities, and more, and have those settings persist for as preferred! This is one of the promises of Process Lasso’s unique automation capabilities. Take control of your PC through your own manual rules, or let Process Lasso’s automated algorithms do it for you.

 

Its doing the same thing it was doing a decade ago. They can dress it up however they want as somehow better, but all they are doing is flicking some switches for you automatically.

 

And for the record, you don't actually need project lasso because the DCS hitches and stutters are actually largely being caused by disk operations suspending the simulation as it tries to load a new model into memory whenever players occupy new aircraft, or whatever else new is being spawned. And when that does happen, they're alot shorter if your using an nvme ssd that has a lot faster response time over even sata SSDs, I had people telling me they were freezing for over a second, meanwhile my freeze was only quarter of a second. These problems are 10x worse if your on spinning disks, and worse if your running the game on the same disk your OS is running on. Storage is a larger bottleneck than you'd think when it comes to have smooth experience in any application.

 

And, it helps if your not relying on swap/pagefile which apparently means having 32gb of ram, because DCS seemed to love memory leaking its way out to 18+gb of RAM usage especially before the patches, so when DCS goes on a memory leak binge it doesn't have to smash your swapfile, which is stupidly slow compared to ram in the first place, and only makes the other disk related problems worse...

 

And considering I'm writing this from the past on my very old Athlon64 and instead my 8700k, 32gb of ram and separate nvme SSDs that I intend on buying in 10 years. I don't need to drink Project Lassos' snakeoil and give them money for something achieved via right clicking in task manager...

 

And that's what it is... snake oil. Applications don't have authority/access to dictate the execution order of other processes, they don't even have that authority over their own, that's part of why race conditions are a thing in multithreading, the OS can, and does, suspend your thread whenever it feels like it, and there isn't anything you can do about it because its the operating system and its got 2000 other threads from all its services making your computer run, and all your programs like teamspeak that its gotta keep give some processor time to as well. And all this means when thread A and B doing exact same thing complete, one may finish much faster than the other, just because the OS decided let one work more often than the other because its giving other processes some CPU time and that can sometime seem random...

 

All your doing is when you set priority is saying "please give this application more time on the CPU" and at the higher settings available, that can be the expense of other applications freezing. Which is other side of project lasso, is that closes background applications and suspends non-critical windows services meaning there's less thread switching to be done. This is less helpful to say someone like me with 6 cores/12 threads, as DCS is largely singlethreaded, there's 11 other threads to handle the background shit than someone who is running a 4 core/4 thread i5.


Edited by GhostB
Link to comment
Share on other sites

stuff

 

Ok, how about when Eagle Dynamics said the same basic thing a while back, too. That's also half-remembered and I can't find it, is it also bullshit? Sorry, I have no reason to give a rat's ass what you think about any of this stuff, and am far more inclined to weight my opinion toward the professionals.

 

I see a lot of people going "WAAAA fix your game!"

I see devs offering a fairly reasonable explanation.

I see a lot of forum warriors crying foul.

 

 

 

Who do you really think I'm going to listen to?

 

-edit

I CAN find similar commentary offered on tech sites by other professionals, though, with a simple Google search.

I won't bother posting the links, since simply googling "Is more cores necessarily better" will take you to many of the same articles.


Edited by zhukov032186

Де вороги, знайдуться козаки їх перемогти.

5800x3d * 3090 * 64gb * Reverb G2

Link to comment
Share on other sites

It's strange, that nobody use Process Explorer or another app to know how it actually works. Task manager or MSI Afterburner is not good enough for these purposes.

This is DCS 2.1.1, but same situation in 2.5. I can upload more if you need.

 

75eac38136beaa9119e3557688752663.png


Edited by TaHkNcT

ASRock X670E Steel Legend / AMD Ryzen 7 7800X3D / 64 Gb DDR5@6000 MHz / Gainward Phantom RTX 4090 / SSD: XPG GAMMIX S11 480 GB (OS),  XPG GAMMIX S11 Pro 2TB, Viper VP4100 2TB, Samsung 990 Pro 2TB (DCS) / PSU: DeepCool PQ1000M / UPS:  CyberPower CP1500EPFCLCD / Win11x64 / Samsung Odyssey G7 32" / Pimax 8KX and Quest 3

VPC: T-50CM3 + Constellation ALPHA Prime (200mm extension), Rotor Plus TCS Base + SharKa-50 / Apache-64 Collective, ACE-Torq Rudder Pedals; Thrustmaster Warthog Throttle; SimShaker Pad

Link to comment
Share on other sites

Nope, it's not multi-core.

2-4 max

i9 13900k 5.5Ghz; ASUS TUF RTX 3090 OC 24GB; 64GB ddr5 6400mhz cl30; 7 Tb SSD NVMe; 2Tb HDD; 20Tb NAS ZFS RAID1; LG 34GN850 3440x1440 160hz IPS; Hotas Warthog + VPC ACE Flight Rudder Pedals; TrackIR5; Quest3; DX3 Pro+ and HiFiMan Edition XS 

MacBook PRO 16' 2023 M3 Max (14cpu-30gpu), DDR5 36Gb, 1Tb + 2Tb 990PRO Ext


 

 


 
Link to comment
Share on other sites

After all that here's the simple summary.

 

Is it multi-core? Yes, it uses more than one.

Does more than 2 cores gives better loading performance? Yes

Does more than 2 cores give better framerates? No.

 

:thumbup:

Gigabyte Z390 Gaming X | i7 9700K@5.0GHz | Gainward Phantom GS RTX 3080 | 32GB DDR4@3200MHz | HP Reverb | TrackIR 5 | TM Warthog HOTAS | MFG Croswinds | DCS PD 1.0 / Steam VR SS 170%

Link to comment
Share on other sites

After all that here's the simple summary.

 

Is it multi-core? Yes, it uses more than one.

Does more than 2 cores gives better loading performance? Yes

Does more than 2 cores give better framerates? No.

 

i am willing to agree on that. i am confident however, that on older cpus with severly limited single thread performance, 4-8 cores will give better framerates, since it has been proven that dcs can distribute load to at least 8 cores (i assume, it will only bother with that, if the "main" cores could not keep up. also it might be limited to speedtree tech and therefore only effect the new caucasus. please note: there is no need to distribute load on all cores, if two cores can keep up with the task!)

 

this is not very interesting when considering buying a new cpu though, since on a modern mainstream cpu 2-4 cores seem to be sufficient...

Link to comment
Share on other sites

i am willing to agree on that. i am confident however, that on older cpus with severly limited single thread performance, 4-8 cores will give better framerates, since it has been proven that dcs can distribute load to at least 8 cores (i assume, it will only bother with that, if the "main" cores could not keep up. also it might be limited to speedtree tech and therefore only effect the new caucasus. please note: there is no need to distribute load on all cores, if two cores can keep up with the task!)

 

this is not very interesting when considering buying a new cpu though, since on a modern mainstream cpu 2-4 cores seem to be sufficient...

 

OK well if you feel confident about that I'll just leave it there. It makes little difference to my performance or anyone else's performance if you believe the loads will be distributed or not.

Link to comment
Share on other sites

BY THEIR NATURE, most of these calculations have to be performed on the same core, especially anything even remotely tied to physics. The flight model, the environement, ballistics, aircraft systems, etc, etc, ALL have to be on the same line together or it won't function. You'll get the physics equivalent of de-sync on your monitor causing screen tearing.

 

In DCS, there was the video recently of the tank zipping through the mountainside and rolling end over end after dropping 19,000ft, and Arma is absolutely famous(infamous?) for the sometimes bizarre behavior of vehicles. You know, they work just fine 99% of the time... but then there's that one moment where the physics engine just says "f this, I'm out". That is because the calculations get sideways with one another, for whatever reason, and it doesn't know what's happening anymore.

 

Keeping all those calculations on one core helps keep those occurrences down, in essence, and helps make the whole experience more fluid. You CAN split it up, but it's very difficult, especially in a dynamic environment, to do so properly and efficiently. And even if it DOES happen...

 

You are talking complete and utter bullshit, please stop trying to repeat the half remembered ramblings of excuses from Bohemia Interactive.

 

Physics is NOT a good example for potential multi-threading speed ups, its THE example potential for multi-threading speedups. The same reasons we compute polygon transforms for rendering your games on the GPU (For sake of this point, you can consider them a multi-thousand core processor) is the same reason hardcore physics calculations, like used in movies, science applications etc are all done on the GPU, or more to the point multiple GPUs, which are basically what supercomputers are primarily made of these days.

 

Physics calculations are multiple, straightforward non-branching logic math solutions which have little to no potential to encounter the race conditions and data locking problems (that is the justification for why games cannot be multi-threaded) because they are just expressions of Force = A * B^C - D, as long as don't depending on trying to update that outcome for use in *THIS* frame, and only use the updated value *next* frame.

 

Considering games generally process the world in frames, usually only using the previous frames data for calculations, the data is static, you don't consider anything that happened during the execution of the current frame because than you'd need to worry about order of execution, just like in multi-core execution even if your only using 1, it'd massive headache. So you take the physics force being calculated like speed and you apply your forces like drag, acceleration, you move on, and you do this a couple thousand? Hundred thousand? Million times? You do this in parallel. You can do this in parallel a couple thousand times over on a modern GPU if you want to, because it you don't need the "if this then do that" logic that the CPU can provide, you just doing A * B^C - D and writing the outcome to a new location.

 

You two are both right and wrong... first, lets separate two things:

1) Multi-threading

2) Multi-core/Paralelization

 

Multi-threading exists from long before the democratisation of multi-core CPU. you can deduce that you can have a multi-threaded application which is not multi-core at all. As I explained in another place, threads are managed by the OS Kernel, you don't have choice to dedicate a thread to a particular CPU core. You only can define some priority, the kernel manage all that for you.

 

In this context, Multi-threading is hell to manage with real-time applications like DCS, where all must be synchronized, where all events must be handled the right time to create consistent interaction. Creating a sperated thread for "physic simulation" in paralelle of "scene object motion" is simply an heresy since both are directly linked.

 

However, it is possible now, to create a single-threaded application, which use some API that are exploiting GPU or multi-core CPU to perform parallelized computing, quicker than an usual loop within the main thread. However, this, is NOT "multi-threading"... this is "parallelization". This is already how that works with DirectX/OpenGL using GPU: The application have ONE thread, and when it is time to compute graphical things, the thread calls API functions (DirectX or OpenGL) which will computs things using GPU... However, this is not multi-thread at all: The thread is WAITING that DirectX/OpenGL functions returns (finished their job) to continue.

 

Using API like OpenCL, it is now possible to create a similar behavior to take advantage for multi-core CPU and GPU to computs some parts which can be paralelized, like, as you mention, a bunch of similar computing. However, this is not as simple as it appear to design a physics engine which can really take advantage of this...First, because using API like OpenCL is full new world to understand, and because the heavy and hard part is not the velocity from gravity vector computing (this is very cheap) but the collision détection, and here, parallelizing things is not as simple as a fixed function without branching, because you have a lot of branching and complex algorithms...


Edited by sedenion
  • Like 1
Link to comment
Share on other sites

Can you people simply tone down the panic, like you can't play without knowing this, let this go slow and steady and figure it out good.

The people who want to be given an answer on a silver plate need to tone down their unpatientness as it makes this whole thread less enjoyable and I wouldn't like to get back to locked one after doing my own look into it, ruining the adventure of disovering this in a relaxed and interesting way.

 

 

I liked to do some of my own testing too, so much that I couldn't resist the wait and decided to just put the free core 2.5 OB, without any of my controls or paid modules.

 

The whole multi-core thing is, that the game was multi-core already. For those that want that kind of an answer. It's so much more complicated and takes effort to actually put multiple-cores to good use.

Because this is not answerable in one statement, it's not practical, because technically it's been multi-threaded and aware of multi-core CPUs (if that's a thing) for a long time.

 

The whole multi-threading without multi-core is actually in a lot of cases not a thing to get more performance, but to run multiple jobs and processes, so your video can play while you're chatting or something.

 

It's very annoying that the same "multi-threading" term used for what are virtual threads in a programming language long before multi-core PCs were a normal thing, don't mix those with the CPU physical cores/threads. Industry is annoying sometimes because each field just picks terms like candy without looking at the larger implications and confusion, terminology is a big thing I'm constantly having problems with around tech sectors, so lazy when they pick terms and names for things, context get's lost on the way from the core engineers to the print that's put into practical use.

 

It's been said for ages around here, as I'm a bit late to find that out, Audio is on a different core (physical thread), that's all it is, everything else except audio is still on one core. But ofcourse we're not sure for latest 2.5

 

Also it's really important not to mix threading in general, OS, kernel, it has threading thing to run multiple things on one computer, even if it's a single-core processor, so there's multiple layers of things, it gets very complicated with different kernels, different programming languages, different processors, and different implementations of hardware hyperthreading (splitting a physical core to multiple virtual hardware threads) ..


Edited by Worrazen

Modules: A-10C I/II, F/A-18C, Mig-21Bis, M-2000C, AJS-37, Spitfire LF Mk. IX, P-47, FC3, SC, CA, WW2AP, CE2. Terrains: NTTR, Normandy, Persian Gulf, Syria

 

Link to comment
Share on other sites

The whole multi-threading without multi-core is actually in a lot of cases not a thing to get more performance, but to run multiple jobs and processes, so your video can play while you're chatting or something.

 

This is the right way to understand multithreading. However, using separate thread(s) for some task can help improve overall performances. For example, runing sound process within a dedicated thread can help, because sound is matter of streaming buffers highly related to time, and it's better to let this working its own way separated from the main application loop...

 

It's been said for ages around here, as I'm a bit late to find that out, Audio is on a different core (physical thread), that's all it is, everything else except audio is still on one core. But ofcourse we're not sure for latest 2.5

 

I doubt the Audio is on a "different core". It is highly probable that audio process is in a separated thread, but not a separated core. The simple reason is that: I don't know any way to dedicate a particular process/task to a particular core... nothing in Windows API allow that... If this is possible, i'll be curious to know how this is done.

Link to comment
Share on other sites

The simple reason is that: I don't know any way to dedicate a particular process/task to a particular core... nothing in Windows API allow that... If this is possible, i'll be curious to know how this is done.

 

well, at least i know of at least one application, that won't utilzie virtual cores (HT), unless specifically told to do so. so there must be at least some control on application level...

 

i also remember when HT multi-core cpus became a thing in mainstream gaming, some games would struggle, because they would f.e. use one physical core and it's virtual twin for parallelization (hope that's the correct term), instead of using two "full" cores.

this problem got solved at some point, but i am not sure, if this was solved through OS or per application.

(you sometimes still have people advising for deactivating HT for gaming. i think this still dates back to the original struggle. on modern games, i never observed any benefit from deactivating HT...)

Link to comment
Share on other sites

I doubt the Audio is on a "different core". It is highly probable that audio process is in a separated thread, but not a separated core. The simple reason is that: I don't know any way to dedicate a particular process/task to a particular core... nothing in Windows API allow that... If this is possible, i'll be curious to know how this is done.

 

The OS handles this. The programmer decides how many threads to spawn and what to do in them, the OS determines where to run them, whether on separate cores or not AND which cores at any given time. There's a scheduler in the OS that allows threads to run and it can interrupt them when it needs those cores to do other things (update the clock, redraw the screen, play an email alert etc). You can set an app's priority (task manager, process lasso etc), i.e. higher priority -> interrupt other stuff before this one or CPU affinity -> try your best to only use THESE CPUs (cores in our case but the OS see them as CPUs nonetheless)

Link to comment
Share on other sites

The simple reason is that: I don't know any way to dedicate a particular process/task to a particular core... nothing in Windows API allow that...

 

I don't think this is what's going on in DCS by default but the app can use SetThreadAffinityMask API to specify which cores a given thread is allowed to run on:

 

https://msdn.microsoft.com/en-us/library/windows/desktop/ms686247(v=vs.85).aspx

 

I believe that's what DCS uses if you use the affinity_mask setting in autoexec.cfg.


Edited by bolek
Link to comment
Share on other sites

DCS runs on 2 threads, Multithreaded optimizations have not been implmented from what I can tell. Windows will try optimize any application running on a single thread across multiple cores, it will attempt to "distribute the load" as it sees fit. This is whats happening here.

 

My understanding of DCS is that it runs everything on 1 thread, and sound on another thread.

 

As an example I wrote a simple app that creates a thread and quite literally infinite loops to saturate the processor, this single thread can be seen running on all of the cores on my machine.

 

cpu_example.gif

 

As you can see from the image, all 4 cores are working, but not to their full extent, this is typiical. It basically tops out at around 25%, and 4 cores... so quick math 1 / 4 = 0.25, yup, they are distributing the load. Now assuming I added a 2nd thread, we would probably see 50% utilization. Hope this helps.

 

Code for reference (if you are into that kind of thing)

class Program
   {
       
       static void Main(string[] args)
       {
           Thread t = new Thread(DoWork);
           t.Start();
           Console.Read();
       }

       private static void DoWork()
       {
           while (true)
           {
               // Just work hard.
           }
       }
   }

Twitch2DCS - Bring twitch chat into DCS.

SplashOneGaming.com - Splash One is a community built on combat flight simulation. S1G Discord

 

twitch / youtube / facebook / twitter / discord

Link to comment
Share on other sites

The OS handles this.

 

That's what I said... However, bolek pointed something I did'nt known;

 

I don't think this is what's going on in DCS by default but the app can use SetThreadAffinityMask API to specify which cores a given thread is allowed to run on:

 

https://msdn.microsoft.com/en-us/library/windows/desktop/ms686247(v=vs.85).aspx

 

However, as programmer, I wonder if such thing would really increase performances much more than letting OS and firmware optimizing it theirself...

Link to comment
Share on other sites

You can start telling the software to run on a specific core but then you interfere with the OS scheduler and it will quickly become a whack-a-mole situation.

 

If your application only has 1 thread, the OS can't make it run any faster on multiple cores than it would have run on a single core. The thread will be interrupted and resumed as the OS sees fit and it may end up on a different core when it resumes. This is normal. In general, interfering with this makes the system as a whole perform worse but it may or may not have a positive effect on DCS under specific circumstances. I think core 0 is used for Windows kernel stuff so letting the OS move DCS away from that one when it needs to probably results in better performance. You can test this by forcing DCS onto a single core with the affinity trick. You'll see it runs like absolute garbage because the audio thread interrupts the main thread a lot.

Link to comment
Share on other sites

You can start telling the software to run on a specific core but then you interfere with the OS scheduler and it will quickly become a whack-a-mole situation.

 

If your application only has 1 thread, the OS can't make it run any faster on multiple cores than it would have run on a single core. The thread will be interrupted and resumed as the OS sees fit and it may end up on a different core when it resumes. This is normal. In general, interfering with this makes the system as a whole perform worse but it may or may not have a positive effect on DCS under specific circumstances. I think core 0 is used for Windows kernel stuff so letting the OS move DCS away from that one when it needs to probably results in better performance. You can test this by forcing DCS onto a single core with the affinity trick. You'll see it runs like absolute garbage because the audio thread interrupts the main thread a lot.

 

That's was my intuition...

Link to comment
Share on other sites

what is being refactored/rewritten does use multi-threading where possible.

 

atm the major parts which do it are:

resource loading and other I/O (logging, input, ffb ...), integrity checking, sound

 

w/o rewriting the engine, splitting simulation into a separate thread from the graphics will benefit it most - which will be, in fact, the mentioned client-server approach, just inside the app.

It's been a while since one of the developers made this statement. So there should be even more progress meanwhile.

 

So the old "lore" that DCS uses only two threads does not strictly hold true any more.

A warrior's mission is to foster the success of others.

i9-12900K | MSI RTX 3080Ti Suprim X | 128 GB Ram 3200 MHz DDR-4 | MSI MPG Edge Z690 | Samung EVO 980 Pro SSD | Virpil Stick, Throttle and Collective | MFG Crosswind | HP Reverb G2

RAT - On the Range - Rescue Helo - Recovery Tanker - Warehouse - Airboss

Link to comment
Share on other sites

It's been a while since one of the developers made this statement. So there should be even more progress meanwhile.

 

So the old "lore" that DCS uses only two threads does not strictly hold true any more.

 

Good find. good to know more specifics, thanks.

Twitch2DCS - Bring twitch chat into DCS.

SplashOneGaming.com - Splash One is a community built on combat flight simulation. S1G Discord

 

twitch / youtube / facebook / twitter / discord

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...