Running multiple instances of single threaded app - how to specify CPU core for each instance?

ss88

Weaksauce
Joined
Dec 1, 2019
Messages
101
I'm running thinkorswim ("TOS"), trading software that is a single threaded app built on java.

PC specs:
Dell XPS 8900 mid-tower
Intel Core i7-6700 @ 4.00 GHz
32gb DDR4 RAM
2 x Nvidia NVS 510 cards (because I'm running 5 monitors)
Windows 10, 64-bit

Because I was having lag issues in TOS (but not in any of the other apps that are running at the same time as TOS), TOS tech support suggested I install and run multiple instances, which is what I'm currently doing. That helped quite a bit with lag, but still have some lag.

How can I figure out if the lag is due to multiple instances using the same CPU core? And if that is the problem, how do I specify each instance use a different core?
 
How can I figure out if the lag is due to multiple instances using the same CPU core? And if that is the problem, how do I specify each instance use a different core?

Running multiple programs on a multi-core CPU is not a unique scenario. That's what they are built to do best. Multi-core CPUs have been mainstream for over 15 years at this point, and the Windows scheduler has received countless optimizations over the years. The windows scheduler can not only distribute load among cores efficiently, but also do it while taking into account things like SMT / hyper-threading, as well as modern CPUs where each core potentially has a different max boost clock (it will prioritize your fastest cores) . It's not going to stick two active threads on the same core while other cores sit there idle. That is very basic and something Windows has been able to handle for over 20 years at this point. Simply put, you're not going to improve anything by trying to manually set your affinity for each process. You would be more likely to decrease performance and/or cause more issues as you're basically just handicapping the scheduler from being able to do it's job (which it can do better than you can).
 
  • Like
Reactions: ss88
like this
Running multiple programs on a multi-core CPU is not a unique scenario. That's what they are built to do best. Multi-core CPUs have been mainstream for over 15 years at this point, and the Windows scheduler has received countless optimizations over the years. The windows scheduler can not only distribute load among cores efficiently, but also do it while taking into account things like SMT / hyper-threading, as well as modern CPUs where each core potentially has a different max boost clock (it will prioritize your fastest cores) . It's not going to stick two active threads on the same core while other cores sit there idle. That is very basic and something Windows has been able to handle for over 20 years at this point. Simply put, you're not going to improve anything by trying to manually set your affinity for each process. You would be more likely to decrease performance and/or cause more issues as you're basically just handicapping the scheduler from being able to do it's job (which it can do better than you can).
Makes sense. I tried setting affinity, but noticed no performance increase.
 
Running multiple programs on a multi-core CPU is not a unique scenario. That's what they are built to do best. Multi-core CPUs have been mainstream for over 15 years at this point, and the Windows scheduler has received countless optimizations over the years. The windows scheduler can not only distribute load among cores efficiently, but also do it while taking into account things like SMT / hyper-threading, as well as modern CPUs where each core potentially has a different max boost clock (it will prioritize your fastest cores) . It's not going to stick two active threads on the same core while other cores sit there idle. That is very basic and something Windows has been able to handle for over 20 years at this point. Simply put, you're not going to improve anything by trying to manually set your affinity for each process. You would be more likely to decrease performance and/or cause more issues as you're basically just handicapping the scheduler from being able to do it's job (which it can do better than you can).
I guess it could depend on the app. 5 years ago when I had my dual 8 core xeon setup Handbrake wouldn't use all the threads to 100%, it would be around 50% usage.
Running 2 instances also would only load up to 60% of the threads, changing the affinity for each process to 16 threads (0-15 for the first and 16-31 for the other) resulted in 100% cpu load.
hal-9000-handbrake-encoding.jpg


hal-9000-encoding-space1999.jpg



this was my machine
IMG_1695.JPG
 
I guess it could depend on the app
Or multi cpu vs single cpu, but in your case it is an higlhy multi threaded application in handbrake that has an hard time scaling after 6 core (depending of the codec use at the time, not sure if x265 was common 5 year's ago) but could try to use more of them if not limited, which open the door for your optimisation here to help I imagine.

That was a really nice machine.
 
Back
Top