13 replies to this topic

[sbaeder]

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

[pscEx]

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

You are right.

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

[Lancelot]

It has been on a special wish from the forum (Unfortunatelly I do not find the topic).

http://www.boot-land...?showtopic=5481

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

Markus indicated using only one cpu, never wrote which number

Since we are following Markus footsteps, maybe tuneable priority too


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

[pscEx]

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

Yes, please!

Peter

[Lancelot]

Yes, please!

Done

@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

[sbaeder]

I sort of figured that we needed to discuss this a bit first During my web searching on processor affinity, I saw other examples of where people needed to do things like this (i.e. constrain the # of CPU's that could be used to allow older, single threaded programs to behave "better")...So, I had assumed it was something like this...But I needed some of the "old timers" to confirm, since I didn't think to look at all the older history by hand, and the searches I used didn't have the right key words to uncover the post you mentioned (or the release notes).

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 , I's so much faster than it used to be that another 20-30 seconds isn't any big deal...

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

[Lancelot]

sbaeder


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.exe

2)TaskAssign from Tom's hardware
something like this works

Start /min TaskAssign.exe

start /belownormal WinBuilder.exe

sleep05.exe

taskkill /f /im TaskAssign.exe

3) WinAFC wonderful

start WinBuilder.exe

start WinAFC.exe -once -minimized

affinityinput.txt

*\WinBuilder.exe := PAIR0::CPU1

As you mentioned, not a big deal.

[pscEx]

Just for the record, I made a test
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)

[sbaeder]

BTW: @Lancelot: When restricting the affinity to one CPU, IMHO it does not matter whether to #0 or #1 or #? (if you have it)

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)...

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

[Lancelot]

BTW: @Lancelot: When restricting the affinity to one CPU, IMHO it does not matter whether to #0 or #1 or #? (if you have it)

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)...

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.exe

only an idea

[pscEx]

I already made this (working):

I use "unchecked" as default, because IMO the "one CPU" is a speciality of Ctmag and is different from standard Windows behaviour.

Peter

[sbaeder]

I already made this (working):

You are DA MAN! Happy New Year!

[Galapo]

I use "unchecked" as default, because IMO the "one CPU" is a speciality of Ctmag and is different from standard Windows behaviour.

I agree. Thanks for the new option.

Regards,
Galapo.

[pscEx]

Available in WB 078 SP5

Peter