
Processor Affinity in WB 078SP4
#1
Posted 30 December 2009 - 03:36 AM
I stumbled upon this when I was trying to monitor and debug some things, and say with the NativeWin7Ex project that creating the cache using 7zip mazed out at 25% CPU on my quad core Phenom. Knowing that it is multi-threaded, and can do better, I used ProcessExplorer to check the Affinity (using the Set Affinity...) and only ONE CPU was checked off.
I have dome some "googling" around, and the default should be ALL cores enabled. I know you can force it to be a specific CPU (and core 0 makes most sense if you have to do that) as a part of the executable. And if I change Winbuilder to use all 4 cores before I start building, all the child programs also use all 4 cores...so it is definately an inherited attribute.
So, for all the guru's who actually build the WB executable...Does this make sense? If so, can we "fix" it? (do I need to file a bug here or is this just the way it is on purpose?)
THANKS
Scott
#2
Posted 30 December 2009 - 02:22 PM
You are right.OK, this may sound weird, but it looks to me as if WB is limiting itslef to one core (core 0)...Not that this in itslef is a big deal, and maybe it's somehow needed to "cope" with the multi-core processors...BUT, this is kind of a pain because it also limits any program it also "spawns" (like 7zip) to also run on that same single core.
I stumbled upon this when I was trying to monitor and debug some things, and say with the NativeWin7Ex project that creating the cache using 7zip mazed out at 25% CPU on my quad core Phenom. Knowing that it is multi-threaded, and can do better, I used ProcessExplorer to check the Affinity (using the Set Affinity...) and only ONE CPU was checked off.
I have dome some "googling" around, and the default should be ALL cores enabled. I know you can force it to be a specific CPU (and core 0 makes most sense if you have to do that) as a part of the executable. And if I change Winbuilder to use all 4 cores before I start building, all the child programs also use all 4 cores...so it is definately an inherited attribute.
So, for all the guru's who actually build the WB executable...Does this make sense? If so, can we "fix" it? (do I need to file a bug here or is this just the way it is on purpose?)
THANKS
Scott
Several months ago I coded WinBuilder to use only core 0.
It has been on a special wish from the forum (Unfortunatelly I do not find the topic).
History:
...
changed - WinBuilder always runs in CPU #0 only, also on multiprocessor and multicore systems
...
*** preview as WB075 beta 4 p
Maybe it is a good idea to make that tunable by the user.
Peter
#3
Posted 30 December 2009 - 03:15 PM
http://www.boot-land...?showtopic=5481It has been on a special wish from the forum (Unfortunatelly I do not find the topic).

Maybe it is a good idea to make that tunable by the user.


Since we are following Markus footsteps, maybe tuneable priority too

If these are "approved requests" , should I put on bugtracker ?

#4
Posted 30 December 2009 - 03:36 PM
Yes, please!If these are "approved requests" , should I put on bugtracker ?
Peter

#5
Posted 30 December 2009 - 03:52 PM
DoneYes, please!

@sbaeder
Written by Peter before, bug request section is not a place to discuss.
As seen from current topic, approval is an important step before adding a request (which you are not sure) to bug tracker.

http://www.boot-land...;showproject=12
next time, with this example, I guess you can follow the path more easly (which you've done very good till now) , I feel you are a very good supporter

#6
Posted 30 December 2009 - 10:13 PM


Making this more easily configured can certainly be a low priority for now As mentioned, the main WB isn't multi-threaded, and other than the "zip" process spawned by WB, it doesn't make any measureable difference in processing speed. AND, with the caching that PSC implemented

Thanks for the quick response and I agree that limiting it is way better than taking 100% of a machine, and preventing other work from going on!
Scott
#7
Posted 30 December 2009 - 10:32 PM

Besides, current topic created by you remind that winbuilder not only use "single processor" but use CPU - 0 as default.
I do not have a powerfull machine, like quadcores or high cpu core2duo... But in case if One have such a machine and if One want wants to assign winbuilder to a single cpu other than cpu0 than it will be better winbuilder have such an option than using workaround

Some workarounds I found so far (in case i may be the one in future

1) works on most applications and older versions of winbuilder
start /belownormal /affinity 2 WinBuilder.exe2)TaskAssign from Tom's hardware
something like this works
Start /min TaskAssign.exe start /belownormal WinBuilder.exe sleep05.exe taskkill /f /im TaskAssign.exe3) WinAFC wonderful

start WinBuilder.exe start WinAFC.exe -once -minimizedaffinityinput.txt
*\WinBuilder.exe := PAIR0::CPU1
As you mentioned, not a big deal.

#8
Posted 30 December 2009 - 10:40 PM
One core:

Two cores:

Due to WinBuilder processing, there are some advantages of "Two cores" compared with "One Core".
But as Scott already said, mainly with 7z (used in BaseBuildEx).
And on the other side, Ctmag suggested the "One core" solution to have other apps fast when WB is working in the background.
(I'm thinking about switching when WB goes into the background ...)
I hope that I can offer a WinBuilder tuning possibility that allows everybody to use the way which is the best for him.
Peter
BTW: @Lancelot: When restricting the affinity to one CPU, IMHO it does not matter whether to #0 or #1 or #? (if you have it)

#9
Posted 30 December 2009 - 11:50 PM
I guess it would only matter if a person had already locked something else to that same core (for example I saw instances where people had locked anti-virus scanning and other OS background processing to a given core)...BTW: @Lancelot: When restricting the affinity to one CPU, IMHO it does not matter whether to #0 or #1 or #? (if you have it)
But for most of us, this is OK for now - until you figure out a better way to manage it!
#10
Posted 31 December 2009 - 04:24 PM
I guess it would only matter if a person had already locked something else to that same core (for example I saw instances where people had locked anti-virus scanning and other OS background processing to a given core)...BTW: @Lancelot: When restricting the affinity to one CPU, IMHO it does not matter whether to #0 or #1 or #? (if you have it)

But for most of us, this is OK for now - until you figure out a better way to manage it!

I hope that I can offer a WinBuilder tuning possibility that allows everybody to use the way which is the best for him.
@Peter:
Here is a "simple" thing to add winbuilder. Have only a checkbox to lock winbuilder to cpu0 (selected as default)
as a result "advanced" users, after unselecting the checkbox, can use /affinity which billy already made available and easy to use.
start /affinity 2 WinBuilder.exeonly an idea

#12
Posted 31 December 2009 - 08:06 PM
You are DA MAN!I already made this (working):




#13
Posted 31 December 2009 - 08:56 PM
I agree. Thanks for the new option.I use "unchecked" as default, because IMO the "one CPU" is a speciality of Ctmag and is different from standard Windows behaviour.
Regards,
Galapo.
#14
Posted 01 January 2010 - 05:38 PM
Peter
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users