- Welcome to Bitsum Community Forum.
Development (period)
Recent posts
#1
Process Lasso / Re: Instance Balancer and spre...
Last post by MPB - Today at 10:27:33 AMOn a related note, I don't know if this is still the case, but it used to be that core #0 was the only one that could handle interrupts, so if possible, core 0 should be excluded from sticky assignments. I'm not sure if that's still the case now but I still try to adhere to it by skipping that first core whenever possible. The old servers I worked on (Proliant) would usually have some documentation buried deep that mentioned that (and on multi-socket systems, it would spell out that the first socket would be the one handling interrupts, etc).
I could be wrong, and maybe newer OS and systems will spread INT handling and I'm just an old fogey for still paying attention to my first core.
I could be wrong, and maybe newer OS and systems will spread INT handling and I'm just an old fogey for still paying attention to my first core.
#2
Process Lasso / Re: Instance Balancer and spre...
Last post by MPB - Today at 10:12:23 AMThanks, that would be a nice addition.
The algorithm to handle the spreading (at least as far as I'm concerned) could be as simple as assigning cores in a "first available, then last available" and so on. It seems like right now it assigns affinity in incremental order like I mentioned (0, 2, 4, 6, etc) but let's say we had an 8 core CPU just for example, it could assign the cores like 0, 6, 2, 4 (skipping the HT/SMT cores). Or on my 56-core system, 0, 54, 2, 52, 4, 50, etc.
On a 2-socket system that would spread the load. It wouldn't spread it equally on 4 or 8 socket systems but at least it's a simple solution for the most likely use cases.
One other option for core assignments is simply to randomize it. It won't be deterministic, but it may be the best and easiest way to really spread the load no matter the underlying architecture. Throw the available cores in an array and pick one at random for the next assignment.
The OS can be queried to get mappings of cores to numa nodes, so the more complicated solution would be to do that and figure out "okay, I've got 2 sockets of 28 cores each" or maybe "I have 4 sockets of 20 cores each" and then write the routine that'll space the core assignments out over however many sockets.
Whatever the case, it'll be nice to see. I have a feeling that even single-socket systems would have a little benefit to spreading the loads out on the physical package. I don't know if there's a common method of assigning the logical cores to their physical placement on the die, but if you've seen those x-ray images of a CPU die, you'll see the tiles that make up the multiple cores, and if you were able to spread out the high usage threads onto different physical sections, I can't help but think that would help with thermal dissipation. But then again, for all I know, there's no consistent mapping of logical cores (as exposed to the OS) to the physical tiles, or if there is, what is that relationship (are cores 1 and 3 next to each other? or cores 1 and 2?)
The algorithm to handle the spreading (at least as far as I'm concerned) could be as simple as assigning cores in a "first available, then last available" and so on. It seems like right now it assigns affinity in incremental order like I mentioned (0, 2, 4, 6, etc) but let's say we had an 8 core CPU just for example, it could assign the cores like 0, 6, 2, 4 (skipping the HT/SMT cores). Or on my 56-core system, 0, 54, 2, 52, 4, 50, etc.
On a 2-socket system that would spread the load. It wouldn't spread it equally on 4 or 8 socket systems but at least it's a simple solution for the most likely use cases.
One other option for core assignments is simply to randomize it. It won't be deterministic, but it may be the best and easiest way to really spread the load no matter the underlying architecture. Throw the available cores in an array and pick one at random for the next assignment.
The OS can be queried to get mappings of cores to numa nodes, so the more complicated solution would be to do that and figure out "okay, I've got 2 sockets of 28 cores each" or maybe "I have 4 sockets of 20 cores each" and then write the routine that'll space the core assignments out over however many sockets.
Whatever the case, it'll be nice to see. I have a feeling that even single-socket systems would have a little benefit to spreading the loads out on the physical package. I don't know if there's a common method of assigning the logical cores to their physical placement on the die, but if you've seen those x-ray images of a CPU die, you'll see the tiles that make up the multiple cores, and if you were able to spread out the high usage threads onto different physical sections, I can't help but think that would help with thermal dissipation. But then again, for all I know, there's no consistent mapping of logical cores (as exposed to the OS) to the physical tiles, or if there is, what is that relationship (are cores 1 and 3 next to each other? or cores 1 and 2?)
#3
Process Lasso / Re: Instance Balancer and spre...
Last post by Jeremy Collake - Today at 07:23:15 AMThat sounds like a great use case for the Instance Balancer!
Unfortunately, as you discovered, it has no awareness of processor sockets or NUMA nodes.
We can, however, add such an option. I believe it would be generally useful. We'll consider this for addition early next week and I'll reply again here with any news.
Unfortunately, as you discovered, it has no awareness of processor sockets or NUMA nodes.
We can, however, add such an option. I believe it would be generally useful. We'll consider this for addition early next week and I'll reply again here with any news.
#4
Process Lasso / Instance Balancer and spreadin...
Last post by MPB - Yesterday at 10:24:35 AMI'm interested in Process Lasso for a project I'm working on, specifically the "Instance Balancer" feature. I installed the trial version and was just testing it with "notepad.exe" and it works basically enough that I see the potential.
In essence, we have an executable that is not multi-threading, so it works best on a single core, and it will use 100% CPU while its running. Currently we're launching the multiple instances using "start /affinity" options from the command line which is kind of cumbersome and requires carefully tracking what cores are in use so additional launches will use a different CPU.
While "Instance Balancer" alone seems like a great way to spread the load across multiple cores exactly the way we want, it's worth mentioning that this is on a dual socket server, and we also want to try to spread the process loads across both sockets. Memory access is another consideration here, so having all of the processes huddled on just one socket and hammering the memory of that NUMA node isn't ideal.
So, the question is, is there any feature or setting I'm missing that will tell Instance Balancer to spread the utilization equally over all of the NUMA nodes? When testing, it seemed like it was merely assigning affinity in numerical order, so my "notepad" instances would start with CPU 0 and then 2, 4, 6, etc (I told it not to do hyper-threads). On my dual 14-core Xeon I was hoping for an option that would start it with 0, then 28, then 2, then 30, etc.
It's also efficient from a thermal perspective because if we loaded up all of the cores on socket #1 first, that CPU could get thermally throttled while socket #2 is twiddling it's thumbs waiting for something to do.
Any thoughts on how to accomplish this? The alternative we're looking at is redesigning our executable itself to either pass in a parameter telling it what core to run on, or give it the smarts to pick a suitable idle core on its own, but considering Process Lasso is pretty reasonably priced I figured it might be a good solution.
In essence, we have an executable that is not multi-threading, so it works best on a single core, and it will use 100% CPU while its running. Currently we're launching the multiple instances using "start /affinity" options from the command line which is kind of cumbersome and requires carefully tracking what cores are in use so additional launches will use a different CPU.
While "Instance Balancer" alone seems like a great way to spread the load across multiple cores exactly the way we want, it's worth mentioning that this is on a dual socket server, and we also want to try to spread the process loads across both sockets. Memory access is another consideration here, so having all of the processes huddled on just one socket and hammering the memory of that NUMA node isn't ideal.
So, the question is, is there any feature or setting I'm missing that will tell Instance Balancer to spread the utilization equally over all of the NUMA nodes? When testing, it seemed like it was merely assigning affinity in numerical order, so my "notepad" instances would start with CPU 0 and then 2, 4, 6, etc (I told it not to do hyper-threads). On my dual 14-core Xeon I was hoping for an option that would start it with 0, then 28, then 2, then 30, etc.
It's also efficient from a thermal perspective because if we loaded up all of the cores on socket #1 first, that CPU could get thermally throttled while socket #2 is twiddling it's thumbs waiting for something to do.
Any thoughts on how to accomplish this? The alternative we're looking at is redesigning our executable itself to either pass in a parameter telling it what core to run on, or give it the smarts to pick a suitable idle core on its own, but considering Process Lasso is pretty reasonably priced I figured it might be a good solution.
#5
Process Lasso / Re: What settings can I change...
Last post by damabbot22 - Yesterday at 06:15:45 AMQuote from: justaquestion on July 15, 2024, 02:11:28 AMon windows 11 and sometimes new installs of windows 10 depending on the manufacturer. these settings no longer work.
https://www.youtube.com/watch?v=qW7QfAZ3ST4
the game runs at 14 fps in this footage. It originally ran at around 18 fps at the beginning. heres how to improve performance to get the level of performance im currently getting.
c1 undemotion
c3 demotion
pkg demotion in throttlestop turn off c1e
speedshift 36 min 36 max
speedshift controls the e cores in throttlestop. theres also this important page.
https://answers.microsoft.com/en-us/windows/forum/all/max-processor-state-setting-in-control-panel-power/d560664d-1e39-4ab6-9948-c4cb8a3f3b82
sets performance while plugged in
powercfg /setacvalueindex id from powercfg /list goes here SUB_PROCESSOR PROCTHROTTLEMAX 100". efficiency cores
Give command "powercfg /setacvalueindex id from powercfg /list goes here SUB_PROCESSOR PROCTHROTTLEMAX1 5". performance cores
powercfg /setacvalueindex id from powercfg /list goes here SUB_PROCESSOR PROCTHROTTLEMIN 100". efficiency cores
Give command "powercfg /setacvalueindex id from powercfg /list goes here SUB_PROCESSOR PROCTHROTTLEMIN1 5". performance cores
sets performance while on battery almost always
powercfg /setdcvalueindex id from powercfg /list goes here SUB_PROCESSOR PROCTHROTTLEMAX 100". efficiency cores
Give command "powercfg /setdcvalueindex id from powercfg /list goes here SUB_PROCESSOR PROCTHROTTLEMAX1 5". performance cores
powercfg /setdcvalueindex id from powercfg /list goes here SUB_PROCESSOR PROCTHROTTLEMIN 100". efficiency cores
Give command "powercfg /setdcvalueindex id from powercfg /list goes here SUB_PROCESSOR PROCTHROTTLEMIN1 5". performance cores
this will improve battery life and also make the efficiency cores help performance significantly. the constant switching of frequencies with e cores hurts e core performance significantly.
What are the recommended steps to optimize performance and battery life on Windows 11 or newer Windows 10 installations by adjusting power settings and processor throttling using the Throttlestop utility and PowerCfg commands?
#6
Process Lasso / Re: Automatically change Lasso...
Last post by luettgen - Yesterday at 12:49:58 AMYour suggestion to link processes to specific Lasso profiles and automate profile changes based on events like starting a Steam game is an excellent one. It aligns perfectly with Process Lasso's core function of automating process management. I think so...
#7
Process Lasso / Re: Automatically change Lasso...
Last post by Jeremy Collake - July 24, 2024, 08:04:38 AMThat's what the Config Profile Switcher feature does. Let me know how it goes if you try it!
#8
Process Lasso / Automatically change Lasso pro...
Last post by anatolewilson - July 24, 2024, 03:31:01 AMProcess Lasso has a feature called Lasso Profiles (not to be confused with process power profiles). As things are now, I find little use for the feature if I have to manually change them from the UI as needed. Therefore I request a way to link a process to a profile - better yet, change to a user-selected profile as the user starts a Steam game, just like inducing the performance power profile kicks in. After all, Process Lasso is all about automation, is it not?
#9
Process Lasso / Re: Guide for Using Lasso for ...
Last post by Forwas - July 23, 2024, 10:14:24 PMAs far as I know, Process Lasso may not be necessary for Microsoft Flight Simulator (MSFS) 2020, because the simulator itself is quite optimized https://www.avsim.com/forums/topic/634833-process-lasso-and-fs2020-best-settingsspace waves
#10
Process Lasso / Re: Does childof include the n...
Last post by samkatakouzinos - July 23, 2024, 09:03:31 AMThank you.