This topic has been locked
LastDefender Sep 29, 2019 @ 5:34pm
Core affinity for older games
Hi guys, I've recently bought a new laptop (a quad-core).
I use to play mostly old games (games released in early 2000) and they all worked pretty well on my old dual-core. I'm wondering if I should set affinity core for these games now in order to run them properly (cause they need only one core or maybe two in some cases, I'm not sure). Any tips about this?
Last edited by LastDefender; Sep 29, 2019 @ 5:34pm

Something went wrong while displaying this content. Refresh

Error Reference: Community_9708323_
Loading CSS chunk 7561 failed.
(error: https://community.fastly.steamstatic.com/public/css/applications/community/communityawardsapp.css?contenthash=789dd1fbdb6c6b5c773d)
Originally posted by nullable:
Originally posted by LastDefender:
Originally posted by Brockenstein:
In this case I think you're safe to try first and solve any problems that crop up second.

I'm just trying to prevent possible issues.
One question though: in what kind of scenario a user would change cores affinity?

I couldn't tell you because in over thirteen years of multi-core computing (using and developing software) I can't think of a single instance where my problem was solved by fiddling with core affinity. Sometimes people recommend it in a throw spaghetti at a wall/couldn't hurt type scenario and in those cases I've never found the results to be very significant.

I really wouldn't worry about it until you have an issue where multiple sources agree fiddling with core affinity is the best solution. And for most software and games, that's going to be extremely rare. Not saying never ever, just saying rarely.
Showing 1-10 of 10 comments
nullable Sep 29, 2019 @ 5:38pm 
You don't need to worry about it. Single threaded applications (like old games) will only utilize one core anyway. You generally don't need to micromanage this in any case. My advice is don't try to create solutions to problems that don't exist.

Fallout 3 was the only game I had to fuss over cores usage, and that was handled in the game's config anyway. Yes, I'm sure there's other examples, but it's not like there's something you need to do with most old games or anything.
Last edited by nullable; Sep 29, 2019 @ 5:40pm
Cathulhu Sep 29, 2019 @ 5:38pm 
Generally not necessary. If they already run fine, there is nothing you must do.
LastDefender Sep 29, 2019 @ 5:41pm 
Originally posted by Brockenstein:
You don't need to worry about it. Single threaded applications (like old games) will only utilize one core anyway. You generally don't need to micromanage this in any case. My advice is don't try to create solutions to problems that don't exist.

Well...it makes sense.
LastDefender Sep 29, 2019 @ 5:42pm 
Originally posted by Cathulhu:
Generally not necessary. If they already run fine, there is nothing you must do.

I have not tried them on my new laptop yet. That's why I was asking.
nullable Sep 29, 2019 @ 8:49pm 
In this case I think you're safe to try first and solve any problems that crop up second.
LastDefender Sep 29, 2019 @ 9:02pm 
Originally posted by Brockenstein:
In this case I think you're safe to try first and solve any problems that crop up second.

I'm just trying to prevent possible issues.
One question though: in what kind of scenario a user would change cores affinity?
Kargor Sep 29, 2019 @ 9:18pm 
Originally posted by LastDefender:
One question though: in what kind of scenario a user would change cores affinity?

From a technical perspective, depending on the hardware and how the scheduling is actually done, forcing a process to run on a specific set of CPUs can improve cache performance. Consider two independent CPUs -- the data for your program is in cache #1, but then your program gets assigned to CPU #2, which means it has to reload all the data again.

This doesn't apply to most PCs, though, as we tend to have a single CPU with multiple "cores" that share the cache anyway.

And then there's the aspect of trying to avoid bugs. If you're writing a multithreaded program, you have to be careful so threads don't access data that's currently being changed by another thread. Bugs like this -- commonly referred to as "race conditions" -- can go unnoticed for a long time on single-threaded systems as threads are never executed at the same time: if you're looking at the data, no other thread can possibly change it because there's only hardware for one thread, and you're that one thread.

If you add multiple cores and CPUs to the system, so threads will get actually execute concurrently, the chance that a bug like this actually shows will increase quite a bit. Or, in the opposite way: if software has this kind of bug, locking it to just one CPU can help hide it.
The author of this thread has indicated that this post answers the original topic.
nullable Sep 30, 2019 @ 10:46pm 
Originally posted by LastDefender:
Originally posted by Brockenstein:
In this case I think you're safe to try first and solve any problems that crop up second.

I'm just trying to prevent possible issues.
One question though: in what kind of scenario a user would change cores affinity?

I couldn't tell you because in over thirteen years of multi-core computing (using and developing software) I can't think of a single instance where my problem was solved by fiddling with core affinity. Sometimes people recommend it in a throw spaghetti at a wall/couldn't hurt type scenario and in those cases I've never found the results to be very significant.

I really wouldn't worry about it until you have an issue where multiple sources agree fiddling with core affinity is the best solution. And for most software and games, that's going to be extremely rare. Not saying never ever, just saying rarely.
The best solution for core affinity is ImageCFG: https://robpol86.com/imagecfg.html.

Download it, extract it in the System32 folder, run the command (according to the instructions on the site) to assign which cpu cores should be used for each exe, and problem solved!
Last edited by Henrique Marrocos; Mar 1, 2024 @ 5:26am
This thread was quite old before the recent post, so we're locking it to prevent confusion.
Showing 1-10 of 10 comments
Per page: 1530 50

Date Posted: Sep 29, 2019 @ 5:34pm
Posts: 10