Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
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.
Well...it makes sense.
I have not tried them on my new laptop yet. That's why I was asking.
I'm just trying to prevent possible issues.
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.
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.
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!