Folding Forum

noorman wrote:Affinity only links a process to a processor core; FaH still works as before and still will only use 'free' cycles, I believe !.

Setting affinity doesn't really "link" a process to a CPU-core -- it RESTRICTS the process from running on other CPU-cores. That restriction means that FAH will back off quicker and interfere less with foreground applications.

Let's assume that you have a Quad machine and you're running SMP which creates 4 copies of FahCore_A1.exe. If you start up a foreground process, it will grab one of the CPU-cores for some amount of time. During that time, one specific copy of FahCore_a1 cannot run even if the other three copies finish the block of work assigned to them. The other three copies may need to synchronize their results with the results from the first copy so they, too, may have to wait. Overall, FAH will run slower than if affinity restrictions had not been placed on the first copy of FahCore_a1.

When no foreground application is running, FAH may run more efficiently. When a foreground application is running, the foreground application may run more efficiently because FAH will run less efficiently.

bruce wrote:Setting affinity doesn't really "link" a process to a CPU-core -- it RESTRICTS the process from running on other CPU-cores. That restriction means that FAH will back off quicker and interfere less with foreground applications.

That's assuming the priority setting for the application is the same or less than the foreground application . While I've yet to compile and run the source, it appears foreground applications don't take immediate priority over the SMP FAH apps using SMP Affinity Changer. With a dedicated crunching box, this is a good thing. The C2Q that is running it is remote and currently offline due to a power failure, but I can test with it in a few days....

-jim

gwildperson wrote:If the software only runs its detection process once every 10 minutes, I don't think it's going to be acceptable. If I start watching a video, I won't be happy if the first 5 or 10 minutes are choppy before FAH yields enough CPU time. This may be an excellent tool for a machine that's dedicated to folding but it's not possible to make it as dynamic as the process scheduler in the OS, which is what people are going to want.

There should not be any problem. The SMP client will release the cores immediatly. I run SMP on P4s, PDs, and C2Ds. At any given time I can start a game, (and forget to shut down client) and don't have any problems. The client slows way down (depending on game and machine) but the game plays fine. If you are having problems running programs with the SMP client running, something must be set up wrong. IMO

RAH wrote:There should not be any problem. The SMP client will release the cores immediatly. I run SMP on P4s, PDs, and C2Ds. At any given time I can start a game, (and forget to shut down client) and don't have any problems. The client slows way down (depending on game and machine) but the game plays fine. If you are having problems running programs with the SMP client running, something must be set up wrong. IMO

Are you running all those same procs with the SMP Affinity Changer?

-jim

Jeannie wrote:

rilian wrote:As far as i know AMD processors have different cpu-bus architecture and affinity changer does not work very well for them

I've tried the various versions of the affinity changer on my AMD 5000 a few times, and every time it has lowered my PPD by as much as 300, so it doesn't seem to work for me. In the 'old' forum, I only remember one other person posting results with an AMD and that person did get more points, so I'm glad to see some confirmation that it's not that I've been doing something wrong!

I noticed a similar drop on my Athlon 64 X2 2.6GHz system...good at least to know that it's not just me.

Disappointing that there seems to be no "free" boost in PPD for AMD systems, but as I also have a Core 2 1.6GHz laptop running FaH that benefits from it, I guess I can't complain all that much.

Is the changer dead?
Can't get to the site, and can't find it with google, as yet.

Need to try it with my Vista Ult 64 service install.

no it is alive

and we are going to make same thing for boinc

we are moving to another hoster atm

How does it work? Is it possible to run 2 SMP clients with quad core cpu (q6600)? If so, how do I install 2 SMP clients? And at what point do I set up Affinity Changer?

Affinity Changer need to be installed. After that - it works itself

And you may install two clients in different folders following instruction on official site

C:\FAH\1
C:\FAH\2

Zebulunite wrote:

Jeannie wrote:

rilian wrote:As far as i know AMD processors have different cpu-bus architecture and affinity changer does not work very well for them

I've tried the various versions of the affinity changer on my AMD 5000 a few times, and every time it has lowered my PPD by as much as 300, so it doesn't seem to work for me. In the 'old' forum, I only remember one other person posting results with an AMD and that person did get more points, so I'm glad to see some confirmation that it's not that I've been doing something wrong!

I noticed a similar drop on my Athlon 64 X2 2.6GHz system...good at least to know that it's not just me.

Disappointing that there seems to be no "free" boost in PPD for AMD systems, but as I also have a Core 2 1.6GHz laptop running FaH that benefits from it, I guess I can't complain all that much.

.


In the end, it could have something to do with the Intel compiler thing; it 's because of that that other things also run slower on AMD systems ...
It 's through their software that Intel keep the upper hand or don't fall behind too much !

I found the same thing when I ran Aff. Changer on my C2D, then later, on my A64X2 ...
On the C2D around 10% rise in production, on the AMD A64X2 lower production.
I now run the C2D with and my AMD without Aff. Changer (v1.0.3)


.

noorman wrote:In the end, it could have something to do with the Intel compiler thing; it 's because of that that other things also run slower on AMD systems ...

Sorry, but that's not true. The Intel compiler produces standard code without optimizations for a specific chip. What that chip does with it is the responsibity of the hardware people.

There are two exceptions.
1) The SSE/SSE2/AltiVec/3DNow+ optimizations were written by the folks at GROMACS.org. There once was a special AMD optimization for 3DNow+ but Intel added one instruction and called it SSE and AMD licensed SSE so it's still back to what the hardware guys do with standard code.
2) One FahCore did use the Intel Library which did have Intel specific code in it. The Library is totally independent of the Compiler and there have not been any projects that use the Library for a long, long time.

In any case, this has nothing to do with Affinity.

Bruce, is it posible Pande Group will add affinity assigning code into SMP client anytime soon? It is now clear that it will fasten research and it is easier than optimize folding code to work 10% faster for Intel Core_ processors

rilian wrote:Bruce, is it posible Pande Group will add affinity assigning code into SMP client anytime soon? It is now clear that it will fasten research and it is easier than optimize folding code to work 10% faster for Intel Core_ processors

They've heard the suggestion and discussed some options but I have no idea if (or when) they'll do anything. I would not be surprised either way. They almost never reveal anything about future features until they have them working the way they want them to (and rarely say anything, even then).

Just a quick thanks from a fellow folder at Team MPC. Got it installed on my wife's Core2Duo and am looking forward to seeing what it does. Thanks again!

@rilian: Why is the affinity changer not accessible? (Your entire website seems to be down along with your forum.)

There are a few in my team that wish to download it, can this be solved in some manner?