Is messing with core affinity a Good Idea™?

[TheBytemaster]

Hello, all,

I was trying to get every last drop of performance out of my, (physical and non-hyper-threaded), dual core system that I could while running a single-threaded process, (some with odd syncing issues and such when run in multi-threaded mode), and came up with an idea for a simple, (if somewhat spartan), optimization script.

It would set the affinity of my single-threaded CPU-eater to one core, and shunt every single one of the other process possible to the remaining core. Thus avoiding as many interrupts and similar phenomena as possible while guaranteeing maximum possible performance. (I realize that the boost probably wouldn't be stellar, but I feel like it's worth a shot, and I could use the coding practice anyways.)

In as broad terms as possible, if I only cared about the one-threaded process to the detriment of everything else, (and no, a nice light Linux distro isn't an option here, or I'd do that), would this be a Good Idea™?

Assuming that this is a Good Idea™ I'm guessing that some system-level processes might not appreciate having their affinity masks changed. If that is the case, I would assume that _WinAPI_SetProcessAffinityMask would simply error out without causing any trouble. Is this correct?

Are there any other hiccups or little snags that I should be aware of here?

[JLogan3o13]

If you are that concerned with performance, ditch the antiquated dual core and go with a processing powerhouse. You can now pick up 6 or 8 core procs relatively cheap.

[TheBytemaster]

If you are that concerned with performance, ditch the antiquated dual core and go with a processing powerhouse. You can now pick up 6 or 8 core procs relatively cheap.

Oh, I know that would be far more efficient, but I don't really have the money for any hardware upgrades right now. (Written from my 5 year old laptop with core2 processor.)

Regardless, most of the reason I'm even attempting this anyways is to practice coding and maybe even learn a little bit about windows. If I happen to get a useful tool out of it, all the better.

EDIT: Wait, it looks like SetProcessAffinityMask needs a process handle, not just a PID. Hrmm... I'm guessing that _WinAPI_OpenProcess is what I want here. I'll post the results later if all goes well.

Edited February 19, 2014 by TheBytemaster

[Richard Robertson]

You are running an AutoIt script and trying to get hardware level performance? Irony at its best.

[TheBytemaster]

You are running an AutoIt script and trying to get hardware level performance? Irony at its best.

That particular irony actually wasn't lost on me, but considering that the script will terminate itself after running anyways, I don't think that's too much of a problem.

[Richard Robertson]

That particular irony actually wasn't lost on me, but considering that the script will terminate itself after running anyways, I don't think that's too much of a problem.

It never could have been.

But for the record, just let Windows schedule your thread rather than trying to change it. Microsoft has been in the business for a long time and probably know what they are doing.

[TheBytemaster]

It never could have been.

But for the record, just let Windows schedule your thread rather than trying to change it. Microsoft has been in the business for a long time and probably know what they are doing.

And to that, I say, meyh. You're probably right, but as I mentioned earlier, I need the coding practice and I'm already most of the way done with it anyways. Can't hurt to take a shot.

[Iczer]

From my experience messing around with core affinity IS a Good Idea - by setting core affinity of some one threaded dotNET application, i get about 350% of performance out of nowhere. So you can experiment for yourself.

[Richard Robertson]

From my experience messing around with core affinity IS a Good Idea - by setting core affinity of some one threaded dotNET application, i get about 350% of performance out of nowhere. So you can experiment for yourself.

How in the world are you measuring that? .Net threads aren't even the same thing as native threads and may be executed on one or more different native threads within seconds.

[Iczer]

How in the world are you measuring that? .Net threads aren't even the same thing as native threads and may be executed on one or more different native threads within seconds.

By difference in execution time? Something wrong with it?

[shaqan]

Look for little program called Process Lasso. It does exactly what you want and better than AutoIt script could.

[TheBytemaster]

Look for little program called Process Lasso. It does exactly what you want and better than AutoIt script could.

I actually already have PL Pro installed on my main computer

And yes, I agree, it is ~amazing~, especially for older systems like mine. Crazy good stuff, I highly recommend it.

This is just an attempt to learn a bit, and maybe make something that's quick, cheap, dirty, and portable. Now if I actually get some time set aside to finish it...