Printable View
So I wondered what it would give to run 2smp's on a dualcore. I tested it on a E6750 @3GHz.
I had frametimes of about 13minutes with one smp. Now with 2smp's it takes 20minutes. So I suddenly gain 6minutes out of thin air?:shrug:
And a caution to everyone to check if you can do this before you do it. One smp was about 22hours so with 2smp's I can still keep a big enough margin.
:nono:Don't do this unless you are 100% certain you still have a very big margin!
wow, that's impressive. I wonder how much of the seemingly spare cycles is a result of the priority these projects are run at? Could someone test one client at super high thread prioritisation ? I don't have a box where this would make sense. the Intels with larger L2 cache might have problems getting fed enough data at low priority.
We can forget about doing this on a core2duo. I redone the calculations this morning on a period of 8% this night and over the same period of time at night when only running one smp.
1SMP average 12m51s /%
2SMP's average 30m /% (average smp1 29m43s and average smp2 30m18s, yet over the same period of time this night)
So you actually lose 4minutes and I think that's the reason why affinity changer wins those minutes when you run it on a normal setup.
An smp on a dualcore would go best with only two threads but then there is affinity changer who manages 2threads/core and you gain time. So I guess affinity changer doesn't manage 4threads/core and you once again "lose" the extra gain that affinity changer gives.
Normally I was going to upgrade that box to a quadcore and then change the setup but I figured I might aswell test what 2smp's on a dualcore act like :)
Result is that it's pointless but also makes me wonder if affinity changer handles 4threads/core or not. The data would suggest it doesn't.