As the post says, I really want to see better and more usage of my 12 CPU threads. I'm not sure if they're gonna do a whole engine rewrite or not, but having their games limited by not having the processing power to add certain features is a bummer.
-
We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
This is an important issue. I am tired of seeing my cpu running hot because only 1 of 12 cores are being used. I am tired of seeing slowed down games because of the same reason..
Sengoku had some multithreading. HOI3 beginning from FTM and V2 from AHD.
I think this really should be left for the developers themselves. They know if they want and where to apply multithreading. It's not a magical performance boost switch after all.
We should concentrate on complaining about general performance whenever it's needed.
V2 vanilla was agonizingly slow later on (and when rearranging large stacks). AHD soothed that ache. Probably not only due to inclusion of multithreading.
Since MT has already been introduced into Clausewitz, it's quite safe to assume that further developed 2.5 (EU IV) will include as much or more of it.
I think this really should be left for the developers themselves. They know if they want and where to apply multithreading. It's not a magical performance boost switch after all.
We should concentrate on complaining about general performance whenever it's needed.
V2 vanilla was agonizingly slow later on (and when rearranging large stacks). AHD soothed that ache. Probably not only due to inclusion of multithreading.
Since MT has already been introduced into Clausewitz, it's quite safe to assume that further developed 2.5 (EU IV) will include as much or more of it.
Last edited:
CK2 has multicore as well, so I wouldn't worry about it EU4 will also have the same features given its built on an improved engine.
They also can't take it too far. After all, 12-thread computers aren't exactly universal yet.
I have been doing programming at uni and while we have done very little of it my understanding is this so people correct me if I am wrong but threads do not equal cores, a thread can only run on one core but a core can run many threads. Meaning once what is split into threads the actual amount you have is more or less irrelevant.
If I am remembering correctly I saw something for a game called Star Ruler, it was about why you couldn't automate ships between star systems, it was because each star system was its own thread that run everything that was in that star system at that current time. The problem they had was getting threads to talk to each other so while anything in a star system could get whatever info it needed for anything else in the star system it couldn't get any info for things in other star systems. And that I believe is the real problem with multi threading most paradox games.
Silly me, yeah I know the difference between the two. Need to proofread more often.
They should rewrite using .net 4.0's Threading library. It does the thread stealing and stuffs.
Some things need to happen in a certain order, but sometimes you hit a point in your programming where some things can be split up and run at the same time, so long as they both finish before you continue. Like the horrifically long loading times paradox games.
Now I don't know wtf it loads even though I've seen the loading screens for probably half the time I've been alive, but lets just say they are 12 things that happen in same thread that could be happening at the same time, and they average about 10 seconds each with the longest taking 15 seconds.
In .net 4.0 its really easy to multithread this.
Doing this used to be quite complex but as you can see its really quite simple now thanks to how to new clr handles these new Task objects. You can add them to a list (they start running and doing their thing as soon as you create them, the list just provides a handle to them) and then after you're done spawning the tasks you want to wait on, you simply use the WaitAll function in the function that needs to wait on them and it will sit there until the other things are done running and then continue.
For other examples where spawning a task that doesn't need to happen before anything else and nothing needs to wait on it to finish, you can simply omit the wait and .net clr handles the cleanup, the main thread can even finish before the spawned child thread finishes.
Though if you want to attach the thread to the parent (the process that creates it) you can pass in TaskCreationOptions.
Some things need to happen in a certain order, but sometimes you hit a point in your programming where some things can be split up and run at the same time, so long as they both finish before you continue. Like the horrifically long loading times paradox games.
Now I don't know wtf it loads even though I've seen the loading screens for probably half the time I've been alive, but lets just say they are 12 things that happen in same thread that could be happening at the same time, and they average about 10 seconds each with the longest taking 15 seconds.
In .net 4.0 its really easy to multithread this.
Code:
List<Task> tasks = new List<Task>();
tasks.Add(Task.Factory.StartNew(() => { /*Do some work here*/ string poop = "everybody does it"; }));
tasks.Add(Task.Factory.StartNew(() => { /*Do some work here*/ string steak = "its whats for dinner"; }));
tasks.Add(Task.Factory.StartNew(() => { /*Do some work here*/ string ck2 = "desires better alliance"; }));
tasks.Add(Task.Factory.StartNew(() => { /*Do some work here*/ string aliens = "i'm not saying its aliens"; }));
tasks.Add(Task.Factory.StartNew(() => { /*Do some work here*/ int boobies = 8008135; }));
Task.WaitAll(tasks.ToArray());Doing this used to be quite complex but as you can see its really quite simple now thanks to how to new clr handles these new Task objects. You can add them to a list (they start running and doing their thing as soon as you create them, the list just provides a handle to them) and then after you're done spawning the tasks you want to wait on, you simply use the WaitAll function in the function that needs to wait on them and it will sit there until the other things are done running and then continue.
For other examples where spawning a task that doesn't need to happen before anything else and nothing needs to wait on it to finish, you can simply omit the wait and .net clr handles the cleanup, the main thread can even finish before the spawned child thread finishes.
Though if you want to attach the thread to the parent (the process that creates it) you can pass in TaskCreationOptions.
Code:
Task.Factory.StartNew(() => { /*Do some work here*/ string bastardo = "Are you my dad?"; }, TaskCreationOptions.AttachedToParent);
In fact, they have to take it as far as they can, running well written parallel software that has the bulk of its processing divided among 12 similarly resource intensive threads means that a 12-core processor is going to run it great, but if your processor only has 6 cores, it can run that software just fine too, but at roughly half "speed". But if they decide to ditch 6 of those threads for the sake of "not going too far", then both the 12-core and the 6-core processors will run the game with similar performances, and more or less as poorly as the 6-core used to when the game supported 12 threads.
Well to properly multithread the programmer shouldn't even think about what hardware will be there. Your architecture shouldn't change if its 2 cores or 100 cores.
Two tasks any videogame must do by default are both wait for user input and process the game model at the same time, so you'll always have at the very least two tasks. And if the game connects to the internet thats a 3rd thread thats always running when online.
For paradox game models it doesn't make too much sense to have more than one main process happening when its a time based game, stuff needs to happen and it needs to happen within a time constraint. But what you could do is say, heres a new task I need to happen, and it needs to happen before the next in-game day, that might make sense to spawn a thread for and then wait for it later on when you need it, and it will probably already be done and the results ready to use.
Lets say one of the tasks is to have the AI make a decision based on conplex family histories, like lets pretend pdox made an AI look back at alliance history to decide whether or not it wants to ally with you. Have you been good to your allies? Well that might take a while to datamine, you wouldn't want your main thread waiting on that AI's decision. If it queries a database then thats even more IO latency you want to avoid making the player wait on. So you spawn that out to a new thread and say hey make your decision by the end of 5 days or the player will have to wait on you, silly AI! Odds are it will have made its decision already unless you have 400 years of alliance history and are running at maximum game speed.
Two tasks any videogame must do by default are both wait for user input and process the game model at the same time, so you'll always have at the very least two tasks. And if the game connects to the internet thats a 3rd thread thats always running when online.
For paradox game models it doesn't make too much sense to have more than one main process happening when its a time based game, stuff needs to happen and it needs to happen within a time constraint. But what you could do is say, heres a new task I need to happen, and it needs to happen before the next in-game day, that might make sense to spawn a thread for and then wait for it later on when you need it, and it will probably already be done and the results ready to use.
Lets say one of the tasks is to have the AI make a decision based on conplex family histories, like lets pretend pdox made an AI look back at alliance history to decide whether or not it wants to ally with you. Have you been good to your allies? Well that might take a while to datamine, you wouldn't want your main thread waiting on that AI's decision. If it queries a database then thats even more IO latency you want to avoid making the player wait on. So you spawn that out to a new thread and say hey make your decision by the end of 5 days or the player will have to wait on you, silly AI! Odds are it will have made its decision already unless you have 400 years of alliance history and are running at maximum game speed.
My understanding is - not sure about how CKII does it - only the AI and economy run on multithreading in HOI3 Simper Fi+ and Victoria 2 AHD
The only time I've seen CKII lag is when selecting a multitude of units or when looking at the family history window.
The only time I've seen CKII lag is when selecting a multitude of units or when looking at the family history window.
You're right though thread managing requires some processing power and (in case of P-x games) syncronization. So if we make every country AI a separate thread most of the time cores will switch between threads and think what to do next.
AFAIK DirectX gives you some multithreading anyway, sound processing and possibly other things work in separate thread. Though obviously it's a tiny fraction of modern games' processes. If EU can at least separate event system in other thread it would give a great boost. I think they already did it.
The load time of PI games is way more limited to hard drive acces speed, duue to thousands of small files, so unless you "multitread" the HDD accec, load time will stay same even on 100500 core computer.
Not magical, true. Otherwise nonsense. There are dimishing results increasing the number of threads but barring horrible implementation in software or hardware, 2 cores is always faster than 1 and 4 cores beats 2 cores handily.
There's another tradeoff wrt processing speed results vs development time but the real crunch comes from going from 1 thread to 2 or more. Devs may very well decide spending resources on improving parallerism is not worth it although from user point of view only using one quarter or less of available processing capacity seems daft.
This is only a tiny bit true. When I upgraded to Intel 520 series drives in Raid 0 it still takes a lot of time to load. Far longer than loading even the entire game folder into RAM alone would take. This is with 500MB/s+ random io reads and near 0 access tims.
To Kallocain, I didnt mean to make it a thread about how you guys should do MT. Just that it is an important aspect going forward. Im sure between Intel and MS making more tools available to devs to aid in threading it will get done.