53 replies to this topic

[mjr]

You mention that PinAffinity controls “the cores that everything else in the system is using” and “to confine all of the Windows background tasks to a group of cores”. Since there appears to be a lot of Windows background processes running, wouldn’t it be easier to just select the cores that VP & VPM should use? 

 

The snag in that theory is that Windows will then schedule background tasks on the same cores that you've assigned to VP & VPM, because you haven't told it *not to*.  The main thing that PinAffinity does, really, is not to tell VP/VPM where to run, but to tell everything else *not to run there*, so that VP/VPM get those cores to themselves.

 

Windows uses a sort of peanut butter algorithm by default, trying to spread the load evenly.  That's a good generic algorithm for a mix of random tasks, optimizing for overall throughput.  But optimizing for throughput comes at the expense of latency.  If you want to optimize for latency, you want a different scheduling algorithm:  you want those low-latency tasks to be at the front of the scheduling queue every time, and you want to minimize competition from other tasks for the CPU.

 

 

I have no idea how threads or cores are assigned, but that almost sounds like if fewer cores or threads are used there would be less scheduling latency & therefore less stutter. IOW assigning a single core to Visual Pinball would be ideal. Apparently that does not appear to be optimal.

 

I'm not sure where you're coming from on the idea that fewer is better when it comes to threads or cores.  If you could explain your reasoning there, I could maybe answer more specifically.  I think the intuition most people have is "more is better/faster" when it comes to threads and cores, so you're being a bit contrarian on this point.

 

 

But what is recommended if I upgrade to an Intel i5-8400 with 6 real cores? If one core is selected for all the Windows background tasks that leaves 5 cores for VP & VPM. Will that cause too much “thread scheduling latency” & therefore too much stutter? Am I better off using only 4 real cores?

 

You really have to be empirical on this stuff - try it both ways and see which is better for you.  These systems are so complex (in terms of both hardware and software) that it's hard to predict from first principles.  From what I've been able to analyze of VP's CPU usage, VP is happiest with at least three cores to itself.  Giving it more cores to itself won't be harmful to VP in any way - it really is the more the merrier as far as that goes.  But the trade-off is that any core you give exclusively to VP, you're taking away from everything else.  And there might be some background tasks where overly throttling them is harmful to VP's performance or responsiveness.  I think you get diminishing returns giving more than three or four cores to VP - not a negative impact, just diminishing returns - so if you have cores to burn beyond that, I'd be inclined to think it would be better to give them to the other tasks.  So on a 6-core system, I'd probably try a 3/3 and 4/2 partitioning (4/2 = 4 cores to VP, 2 to all else), play a while with each, and see if I could tell any difference.

Edited by mjr, 09 December 2018 - 08:29 PM.

[Brer Frog]

 

 

I have no idea how threads or cores are assigned, but that almost sounds like if fewer cores or threads are used there would be less scheduling latency & therefore less stutter. IOW assigning a single core to Visual Pinball would be ideal. Apparently that does not appear to be optimal.

 

I'm not sure where you're coming from on the idea that fewer is better when it comes to threads or cores.  If you could explain your reasoning there, I could maybe answer more specifically.  I think the intuition most people have is "more is better/faster" when it comes to threads and cores, so you're being a bit contrarian on this point.

 

 

The PinAffinity instructions mention “Affinity optimization can reduce stutter by reducing thread scheduling latency, allowing video game threads to respond more quickly when they have work ready to do.”

I have no idea how cores are assigned, but when I saw “thread scheduling latency” this made me think there might be delays depending on how threads or cores are scheduled or assigned. IOW if a process is assigned to multiple cores & had to jump between cores would that cause a delay & stutter. If everything (meaning the whole program) ran in one core it would not have to jump between cores.

Other than playing Visual Pinball, I am not a gamer. But magazines & articles typically say that most games do not use multiple cores, & that left with the impression if a game is designed for one core than that is all it will use. This made me wonder what does VP use or need. Obviously my understanding of how cores are used is very much lacking.
 

Edited by Brer Frog, 10 December 2018 - 01:32 AM.

[mjr]

IOW if a process is assigned to multiple cores & had to jump between cores would that cause a delay & stutter. If everything (meaning the whole program) ran in one core it would not have to jump between cores.

 

Ah, okay, I get it.  You're picturing a core as a sort of apartment that a program lives in for a while, and when it's time to move to a different core, it has to pack up its stuff into boxes, get a moving truck, ship all the boxes to the new core, unpack everything, and start over.  In other words, you're picturing there being some overhead - some lost time - when a program moves between cores.  So the implication would be that confining a process to a single core would avoid this overhead by preventing Windows from gratuitously evicting it from the core it's all nice and settled into and making it waste a bunch of time unpacking in a new core.

 

It's not really like that though.  A "core" is just a unit of execution.  It doesn't have any resources that get "moved in" to the core while a thread is operating there, so there's nothing to "move out" either.  The resources are all shared among the cores.  So "jumping between cores" is pretty much a zero-cost operation.  And it's not like Windows is going to gratuitously move stuff around anyway.  If a process has more cores allocated than it's actually using, it won't make Windows indecisive, and it won't make Windows try to spread work around that can't be spread around.  It's like if you were able to tell Windows "give this process 100 GB of memory" and the process only wanted to use 1 GB of memory: Windows wouldn't try to somehow force the process to use all that extra memory, it would just let the process use the 1 GB it needs and leave the rest unused, but ready to use if the program ever did need it.

 

 

Other than playing Visual Pinball, I am not a gamer. But magazines & articles typically say that most games do not use multiple cores, & that left with the impression if a game is designed for one core than that is all it will use. This made me wonder what does VP use or need. Obviously my understanding of how cores are used is very much lacking.

 

The magazines aren't wrong, exactly, but they're generalizing, and the generalizing doesn't fully extend to VP.  The thing about a program's design that determines how well it parallelizes across cores is how it uses threads.  A program that divides its work into N threads will generally be able to distribute effectively across N cores.  That's a gross simplification, but it's usually true to a first approximation.  The magazine articles you've seen are right about *most* video games, in that most video games are architected with a single physics/input/render thread that does almost all of the work, and one thread means it won't scale beyond one core.  It's not that having more cores available will be harmful; it's just that extra cores won't offer any scaling benefit, because a single-threaded game will be compute-bound on the one core where that one main thread is running, no matter how many cores you give it.  Video games in general therefore benefit more from a higher clock speed than from extra cores.

 

VP isn't quite like most games, though.  It actually *does* scale across cores to some extent.  The main reason is VPinMAME, which runs its ROM emulator as an independent thread.  The ROM emulator is quite compute-intensive, almost as much as the main VP render/graphics thread.  So VP + VPM distributes very nicely across two cores thanks to that.  It scales well to at least a third core because VP also has gobs of separate threads doing I/O tasks - D3D, DOF, DirectInput, and sound.

[Brer Frog]

mjr -

 

Thank you very, very much. Your detailed explanation cleared up a lot of things for me.

 

Mike

[metlfan2003]

I know this is an old topic, but I wanted to say thank you for curing the stuttering on all my VPX tables. Many of the VPX tables in my cabinet ran ok but were plagued by random stuttering and lag. I had started to just live with it, but it wasn't until I tried Hanibal's 4k edition Indiana Jones table (https://www.vpforums...showtopic=39467) that I had a truly unplayable table. My FPS were down into the 40's immediately after launching the game and dropped well below 30 after launching the ball. I started looking into potential causes and came across multiple threads that essentially pointed to the fact that I needed a faster processor and a better video card. Some people were even talking about buying the latest gen Core i7 processors and GTX 1070 and 1080 video cards, which I found insane considering that those setups should run newer AAA title games at 1440p resolution without issue. There had to be something more to it than this.

 

While my PC specs would never be considered high-end, I did consider them to be more than adequate for VP at 1080p resolution. I recently updated my PC hardware from a Athlon X4 750K and GTX 560 to a Core i3-6100 and GTX 750 Ti. I also moved from 8GB of DDR3 to 8GB of DDR4 during the upgrade and from Windows 7 to 10, but honestly there wasn't much difference in performance between the two setups. I found this odd, but figured that there was some tweaking to do within Windows 10. I also experimented with some of the Nvidia control panel settings (such as setting my vsync setting to "fast") and most of VPX graphics options with no real improvement. 

 

Anyway, after nearly pulling my hair out for days, came across this topic and figured I'd give it a try. I fired it up using the stock setup and immediately noticed a drastic improvement. I had been testing out Hanibal's excellent Cirqus Voltaire VPX table prior to this and had issues with stutter during DOF intensive moments. Even though the VP FPS counter wouldn't necessarily drop during these times, there was obvious and noticeable stutter and lag. After starting PinAffinity and firing it back up, I found NO perceivable stutter at any point while playing. The FPS counter stayed right around 120 FPS with vsync on and never dropped below that point during gameplay. At this point I decided to try Indiana Jones and was hopeful it would make that table playable again. Here again, I was able to play several full games locked at 60 FPS despite the amount of DOF effects in the game.

 

Thank you again for all your hard work on developing PinAffinity! 

[mjr]

metlfan2003 - I'm glad to hear it worked so well for you!  

[apophis]

Hey all, I just installed PinAffinity and initially it was making some of my tables worse. But then I realized that only tables using PinUpPlayer were negatively affected. Once I added PinUpPlayer.exe and PinUpDisplay.exe to my Pinball Type everything worked great!

[mjr]

Hey all, I just installed PinAffinity and initially it was making some of my tables worse. But then I realized that only tables using PinUpPlayer were negatively affected. Once I added PinUpPlayer.exe and PinUpDisplay.exe to my Pinball Type everything worked great!

 

Thanks for pointing that out - I should add those to the default process list.

[flstclasic]

Thanks mjr!

[cargo]

Sorry to necropost, but I wanted to share something that happened to me. When I ran PinAffinity in my machine, as launching through Task Scheduler when Windows 10 logs in, my PC would slow down to a crawl. It gave me the appearance as if Windows 10 had frozen, but it was running (just very slow). I eventually found out the culprit was a service program called "AMD User Experience Program". A telemetry tool that sends data to AMD about your PC hardware during startup. Apparently I forgot to opt out of this while installing the latest Radeon GPU drivers. It looks to me the program is kind of a CPU hog while calling home.

 

Guess I should mention I am using the latest Radeon video drivers.

 

To fix this I went to AMD's configuration panel, clicked on the gear icon at the top right corner of the window, clicked on "Preferences", then chose "Leave" at the "AMD User Experience Program" option offered in that preferences section. When I did this the AMD utility completely stopped and removed the service from the system. With this out of the way I was able to use PinAffinity without issues.

 

I found this Youtube Video that explains how to do this visually. Hope someone finds it useful.

Edited by cargo, 17 February 2024 - 04:09 AM.

[wrd1972]

Does this program still have any value with today's more powerful HW? I redid my whole cab last year with nearly the most powerful HW available.

[garnel]

I use PinAffinity to restrict VPX to the first three cores of my 5600X CPU - not so much for stutter, as Frame Pacing cured about 95% of that. But I still noticed an occasional "stutter gap" while playing TOTAN 4K with VP10.8.  The improvement I went for is reduced interrupt latency to kill that last 5%. This worked.

 

When a flipper is pressed or the ball hits a toy, it causes an interrupt that tells Windows to service it.

 

By default, Windows services interrupts in a round robin manner, trying to give roughly equal time to each, which will cause VPX interrupts to wait their turn in the queue to be serviced - which can result in flipper lag, stuttering, etc.

 

When PinAffinity is running in the background, and VPX assigned to the first three CPU cores, VPX gets priority over all of lhe non VPX interrupts.

CPU clock speed is NOT the critical factor - the time the CPU and Windows takes to respond to an interrupt is critical for VPX.

 

btw - i'm a retired embedded systems engineer, but the last half of my career was in management, so probably lost more than a few brain cells during that time.

Edited by garnel, 20 February 2024 - 08:19 PM.

[kaledev]

I'm also wondering if this program is still appropriate to use. I tried it out on my machine but it crashes whenever I try to minimize - and if I can get things to stay running it'll eventually crash on its own. May just be bugs that haven't been solved - I know the last update was 4 years ago.

[mjr]

kaledev - I'm not aware of any crash problems with the program, so it might be something specific to your configuration.  If you want to try tracking it down, grab the source from github and fire it up under the Visual Studio debugger to find out where it's crashing.  If you manage to figure out what's going on, let me know and I'd be happy to apply any fix you come up with.

 

Affinity setting is probably less likely to be beneficial on a newer machine, mostly because most of the newer CPUs have a lot of cores.  Things are probably going to naturally distribute more evenly on their own (well, under Windows's general-purpose supervision, I mean) with less contention for core access from I/O events.  But I expect it's very configuration-dependent, so it's something I'd experiment with, IF you're experiencing any of the symptoms that would make you want to do this kind of tuning in the first place, such as visual stutter.