Project Mercury - An automatick process priority manager / booster

[SvenBent]

This is a branch of the conversation started here http://encode.su/threads/2143-TopWinPrio that I'm now giving its own thread.

Project Mercury Is an automatic process priority manager.
It sits in the background and monitors what programs/process The user has currently in focus, and givse it "Above normal" priority.
This makes navigation and usage of the computer feel more responsive despite heavy load in the background.
When you minimize a programs Project Mercury will give it "Below normal" priority, resulting in CPU resources being shared more natural according to user pattern.

Active Program: Above Normal
Inactive programs : Normal
Minimized program : Below normal

This programs is highly efficient with memory overhead and uses as little as 500 to 700kb and a unmeasurable small amount of CPU time.
This program is a simple start-and-forget program, as you don't need any advanced configuration or installation to go through. ( It's portable)
This program does not create files in your system or saves any registry info for basic usage. (Some advanced functions make changes to windows settings in registry)
It does not need internet access so you can easily block it in your firewall if you are on the paranoid side.
in short: Its simple, tight and clean.


newest version can be found here:
http://www.techcenter.dk
http://www.softpedia.com/get/Tweak/C...-Mercury.shtml

more information/documentation will come here

Any feedback are welcome.

[SvenBent]

Just uploading two experimental builds for Necroes.

Mercury_High.exe - Sets foreground application to "High" CPU priority instead of just "Above normal"
Mercury_Realtime.exe - Sets foreground application to "Realtime" CPU priority instead of just "Above normal"

So far a quick and dirty test gave me some very unpleasant windows experience

I started 7-zip benchmark and tested the 2 experimental builds.
With "Realtime" mode my entire windows would freeze now and then for a few seconds ( 6-8 ) every so often.
With "High" every so often ( same interval) my mouse would start to move very jittery

These bad experience occurred when 7-zip would hit >98% cpu usage.
Which is the exact effect i predict with going overboard with foreground boosting. It start to conflict with the system.
However my quick and dirty test was on a slow AMD based laptop so it might just be because of the computer.

Anyway These are uploaded for experimental usage.
Hopefully tomorrow i can work on the anti CPU choke monitoring.

[necros]

funny, high and realtime exes don`t run on my system, general exe runs ok
they just close after run 8-(
(10 x64 10135)

[SvenBent]

funny, high and realtime exes don`t run on my system, general exe runs ok
they just close after run 8-(
(10 x64 10135)

hmm thats weird. i assumed you have windows 64 ? well all 3 of them should bee 64bit so it shouldn't be that
Im going to retest them here in a bit to see what went wrong.

-- edit --

I just tested my local copies and they starter fine. Then i re-downloaded from above and they still ran fine.
it was a minor change to the source so I don't see what can be wrong. Maybe some heuristic AV that trigger about the high/real time priority i have no clue atm

[necros]

what os you run it on? i tried 8.1 64 vm

bingo! it runs on 7 64!
so i suggest fixing these builds to run above 7 64 8-)

[SvenBent]

what os you run it on? i tried 8.1 64 vm

bingo! it runs on 7 64!
so i suggest fixing these builds to run above 7 64 8-)

Bah I don't have a windows 8 to test or to figure out what itis that breaks . Is it 8 or 8.1 ?
But try these two alternates. Its a shot in the dark but hopefully they will work with Win 8

[necros]

yeah thanx it runs! 8-) testing...

[necros]

so far so good, no visible performance degradation, can you post 32 bit build?
p.s. can`t know if desktop mode selected - is it by default enabled?
would be nice to have checkmark beside it
src would be nice too
if you didn`t use mpress for security reasons have ya tried upx --overlay=strip --compress-icons=0 --lzma --ultra-brute?

[SvenBent]

so far so good, no visible performance degradation, can you post 32 bit build?
p.s. can`t know if desktop mode selected - is it by default enabled?
would be nice to have checkmark beside it
src would be nice too
if you didn`t use mpress for security reasons have ya tried upx --overlay=strip --compress-icons=0 --lzma --ultra-brute?

The CPU Slice mode or more correctly CPU quantum mode is bit tricky here.
Project Mercury doesnt directly handle this at all. It tells Windows what "you prefer" by changing values in the registry.
The default value is depending on you windows version. Desktop versions has well "Desktop" as default and server version has "Server". The annoying thing is that a freshly installed windows with no changes to these values are set at a value that just says "Hey I'm running default" and not exactly how they are running. I could of cause crosscheck with windows versions.
The other issue is this registry value can be changed by windows GUI as well as potential other programs so Project Mercury would have to constantly poll this registry value, which cost CPU cycles.
Third is that it gets a bit messy code wise to make sure only one option is marked. not a big big issues but i would easily triple some of the source code regarding this.
All these 3 a really small hurdles but together I figured i would leave no check mark also to better underline that this is not something that is actually turned on or off inside Project Mercury, but is actually just a command to windows to change its way. The automatic mode is though code running inside Project mercury and therefor has it check marked.
How about a simple manual click option to read the current mode ? Would that be helpful ?


Hmm about Source i prefer to keep it a bit to myself, but its really nothing big to be honest. Nothing compared to other peoples work here.

I tried UPX with --ultra-brute a while back. but mpress came out a tiny bit smaller and mpress had less warnings on Virustotal.
Both UPX and mpress increased the inactive memory footprint size bit a few MB, but if i understand correctly Project Mercury discard this to page file immediately at launch buy using its memory clear feature on itself only.
Which was the only reason i made a clear memory feature. The code was already included. I do however not recommend Using memory clearing/Optimizer on a general usage.


P.S.
Keep in mind the CPU slice mode should be considered experimental as Im not sure you have to actually reboot after changing it, which would make the automatic mode unworkable.
I'm hoping to get in contact with Cbloom he seems to know a bit about the Windows scheduler and how CPU slice / Quantum works.

I will post 32bit version tonight, 32bit version might run a tad slower or use a tad more CPU time.

[SvenBent]

Just quickly updating some 32 binaries.

I'll try to benchmark the 32 bit vs 64 bit tonight or tommorow to see which are indeed faster

[SvenBent]

Just a heads up on the performance benchmark 32bit vs 64

I removed all my sleeps in my main loop forcing the code to run as fast as possible and just gople up CPU time as much as possible.
I changed the part whre it check if you have selected a new program from if new<> old then... to if new = old then. so the programs would try to adjust priority in each loop as long as the same process was active
i made sure to keep same process active during benchmarks
basically doing check and adjust loops non stop and see which version was faster

i becnhmarks 10 million loops this way

3 runs of 64 bits came out etween 14.3 ti 15.0 secs
3 runs of 32 bit came out to 16.3 - 16.6sec
3 reruns of 64bits came out to 14.3 to 14.7 sec

Soo 64bit code is aprox 10% faster and I, therefore assume it uses less CPU time


Ill recheck tommorow with just the outerloop but with no prioroty adjustments tommorow

[SvenBent]

There might be a tiny bug in version 1.0.4.0.
Its none fatal (Not crash or destructive for usage) but how it handles exceptions with programs that already have a specified CPu priority ( like taskmangager has priorty of high) it might not always retstore the 2nd application afterwards to normal priority

E.g. If you shuffle through programs likes this
Taskmanger ( high)
programs one
Program two (This one might be left in above normal priority)
Programs tree

I need to trace through my loops once get a bit more time to go through it.

[SvenBent]

Previous mentioned bug is not there i traced and traved my sooruce code keeping an eye on how all variables would change indifferent situations and i swore i always came up with situation where it would lose proper count on how to deal with previous used programs priority. But under actually testing it showed no such bug.

it was a misaligned tab in my source code so it looked like it was inside a loop it was actually not, so the source was always correct, I just misread it when i traced it.

[necros]

did you use cppcheck to check your src?
paked files with 7z + No HT stuttering = no performance difference

[SvenBent]

What was you cpu and number of used threads ?

[necros]

i7 3770k 16 threads

[SvenBent]

In that case Hyper Threading helps you and enabled not hyper threading conflicts would/can reduce performance
Its for cases where your thread counts is lower than you virtue cores (optimally lower than you physical cores) if you try the same with just 4 threads the "No HT conflicts" feature should boost you performance.

You CPU has 4 real cores. each cores consist of different sub parts. before Hyper threading one core could only run one thread at a time. but one thread might no use up all the sub parts of a core.
lets pretend one 7-zip thread can utilize 80% of a core's sub parts. that's 20% going unused.
now with hyper threading on it creates two virtual cores for one physical core. so now one physical core can take instruction from 2 threads at once and fill the unused parts with instruction from the 2nd thread.
now we are using the one physical core 100%.

going back to you CPU you have 4 cores each with 2 virtual cores. lets say 7-zip uses 4 threads
without hyper threading:
thread 1 -> physical core 1 (80% utilization)
thread 2 -> physical core 2 (80% utilization)
thread 3 -> physical core 3 (80% utilization)
thread 4 -> physical core 4 (80% utilization)
we are getting 80% of 4 cores aka 320% performance of a physical cores max performance


now with hyper threading one we get 8 virtual cores
Thread1 > Vcore 1 (80%) > Core1
Thread2 > Vcore 2 (20%) > Core1 (100%)
Thread3 > Vcore 3 (80% > Core2
Thread4 > Vcore 4 (80%) > Core2 (100%)
now we er getting 100% usage but form only 2 physical core so we end up with 200%


With my feature affinity is controlled so the programs ignore every other virtual cores so instead you end up with this
Thread1 > Vcore 1 (80%) > Core1 (80%)
Thread1 > Vcore 3 (80%) > Core2 (80%)
Thread1 > Vcore 5 (80%) > Core3 (80%)
Thread1 > Vcore 7 (80%) > Core4 (80%)

and we are back at the full 320% performance aka the same as disabling Hyper threading to begin with (except HT is still running and can take care of backgrounds task)


That's the optimal case for the feature and when you should use it
But in your case you ran with 16 threads and it would go like this without my programs


Thread1 > Vcore 1 (40%) > Core1
Thread2 > Vcore 2 (10%) > Core1 (50%)
Thread3 > Vcore 3 (40% > Core2
Thread4 > Vcore 4 (10%) > Core2 (50%)
Thread5 > Vcore 5 (40%) > Core3
Thread6 > Vcore 6 (10%) > Core3 (50%)
Thread7 > Vcore 7 (40% > Core4
Thread8 > Vcore 8 (10%) > Core4 (50%)
Thread9 > Vcore 1 (40%) > Core1
Thread10 > Vcore 2 (10%) > Core1 (50%)
Thread11 > Vcore 3 (40% > Core2
Thread12> Vcore 4 (10%) > Core2 (50%)
Thread13> Vcore 5 (40%) > Core3
Thread14> Vcore 6 (10%) > Core3 (50%)
Thread15> Vcore 7 (40% > Core4
Thread16 > Vcore 8 (10%) > Core4 (50%)

you are using all resources for your CPU there is nothing my program can do to enhance that. on the contrary it might reduce performance cause it shouts out every other virtual core and you are back to having that 20% unused resource


a rough way to look at it, is like you programs threads are line of cars that has go into parking lots (your physical cores)
without hyper threading you have one individual road into each parking lot so if you have 2 lines of cars, they are going in fine but if there are only long space or waits for the next car in the line, the parking lots is not getting filled as fast as possible
With hyper threading there are two roads leading up to the parking lots so now two lines of cars can get up to the parking lot entrance but still only one car can enter at a time. so when there is a pause in one line or a long space because grandma refuse to drive more the 20 mph, you can let the other line of cars into the parking loot an archive 100% of the parking lots fill rate

What is bad about this is if you have two lines of cars only, and they use the two roads into the same parking lot. The parking lot entrance becomes the bottle neck.
by closing every other road the second line of cars now have to use a different road into a different parking lot and we go a lot faster.
but in your case you had 16 lines of cars going and all roads are being used as well as all parking lots. no matter how I would rearrange the roads, they will be running with the full speed.


So in short "No HT conflicts" is wfor hen you are using less numbers of heavy CPU threads than your physical core. if you thread count is between you physical and you virtual core count its an grey area. The more threads above your physical core counts, the less likely it is to help.

[SvenBent]

oh wait I just saw you did wrotet "no HT co" its either "No Ht conflicts" or "No multicore stuttering). if its the later that would be weird since that locks processes to only use one core.
Did you use command line or GUIfor 7-zip? remember no HT stuttering is for old games

[necros]

My bad,sorry. No HT conflicts option of course

[necros]

Hi. I noticed that Mercury sometimes don`t apply priority to some applications. I mean after say 2 hours i check tskmgr.exe priority it says normal and other apps also show no priority change to realtime - still normal. 8-( (win 10 64)

[SvenBent]

Project mercury does not apply priority adjustments if you current active application has "Low(idle)" "Above normal". "High" or Realtime. It only touches applications hat has "normal" or "below normal" Priority (to recover those it set to below normal from minimizing it). Thats to avoid affecting any manual priority you might have done and to avoid giving priority to things like Dnetc or setiathome/Boinc etc. etc.
So if say taskmanager(default is High) is you active process then nobody gets "Above normal". Well except for project mercury itself off cause, since it always runs in above normal.

I'm not sure if its that effect you are seeing.

The realtime version was just a quick hack. do you see the same behavioer with the normal 64bit version ?


My current PC has a 23h uptime and project mercury changes fine but Im using the "officiel" version. it could offcause be a windows 8 thing.

[necros]

not tried cause i need realtime, hmm 3delite does the same - not change to realtime, i guess it`s somehow internal windows 10 feature

[SvenBent]

oh so its the realtime version you are using> and only seen this behavior with the realtime version ?
Is it on all applications you re not getting the boosted realtime cpu priority under win1? or is it just one some or after some time ?

Im trying to solve some issues with Win10 and the ballon tip. for some reasone windows 10 cue up the ballon tips instead of overwritten them

[necros]

yes only realtime version tested, i don`t get it randomly on all applications

[SvenBent]

yes only realtime version tested, i don`t get it randomly on all applications

I think i might have a vague idea of what is going on. just more of the code that needs to be adjusted to take care of real time priority in a proper way
I will look into it this weekend. maybe even implant high and real time selection in the main branch, if i can do it in a way that don't eat up to much CPU time in the outer loop.

I've Updated Project Mercury to try to fix the annoying balloon tip behavior under Windows 10.

[SvenBent]

A quick discovery. in regards to windows10
If you run applications in administrator mode Project mercury cannot adjust its priority. To fix this start Project Mercury in administrator mode as well

[necros]

is there a way to compile it running in adm mode by default?

[SvenBent]

Yes there is already a Working fix. I haven't pushed that out since its pretty easy for the user to temp fix it by just ticking of "run ad administrator" under compatibility mode of the .exe file.
This weekend om hoping to solve the last issues with the excessive mode. If not i will just push a release with the admin fix and selectable priority.

[SvenBent]

V1.2 got released yesterday and can be downloaded from www.techcenter.dk/Mercury.exe

This new version has been restructured from a timed loop into using shell hooks instead. So instead of using CPU power to check what program is active every 500ms. windows now calls project Mercury when you change windows. This has 2 benefits

1: A lot less CPU usage.
CPU usage dropped 0.03-0.04% to below 0.0000000000000001 %

2: Faster response time.
Prior version could have a worst case off up to 500ms delay before it started changing priority. This version should do it "immediately"


The Automatic CPU slice mode had to be taken out due to incompatibility with the new structured. and this features has to be rewritten from scratch.

[nikkho]

1: A lot less CPU usage.
CPU usage dropped 0.03-0.04% to below 0.0000000000000001 %

2: Faster response time.
Prior version could have a worst case off up to 500ms delay before it started changing priority. This version should do it "immediately"

Working smooth here.