Lazy SMP, part 2

[Joerg Oster]

Well, I discovered at least one issue that might have affected my results.... Turbo-boost. I realized that Turbo-boost may be affect my tests of multiple-cores... both the time-to-depth test and the game playing tests. My chip is an i7, so when I ran the single core time-to-depth test, it was 15-20% faster than it would have been if the chip had been fully loaded. So this makes the relative improvement in time to depth for multiple threads is actually somewhat better than my first post indicates.

On the game results the interpretation is more difficult, in the single-thread case all four cores are running all the time because I am playing four games in parallel, but in the four-thread case, one core is running for the opponents (and therefore might get turbo-boost) while all four are running for my program. In principle, this reduces the rating of the four-thread version relative to the single-thread version because the opponents are stronger for the four-thread version, but given the tiny time-slices the opponents are playing in, I am not sure this matters.

The only way to tell is to try to disable TurboBoost. Anyone know a safe way to do this? There is no option in the BIOS. Here is a website claiming to have an approach, but I don't know anything about the tool they are referencing.

http://luisjdominguezp.tumblr.com/post/ ... t-in-linux

Are there any other adaptive speed changes the i7 does that might also affect the results? What do others do when testing to avoid problems like these?

- Dan

You need to disable that for sensible testing. It's ok to run with it in real games, as when it kicks in, you get a performance boost. But it does screw up SMP comparisons significantly, because you now have yet another variable in the equation.

So the rating agencies should have this disabled. Do you have a sense of whether it would benefit MP or SP more or is it just random?

Idea is, that if only 1 core is busy and the others are idle, to raise the cpu frequency for this one core to speed up this SP application. If all 4 cores are at full load, Turbo Boost has most likely no effect. Thus SP does benefit more.

[bob]

Well, I discovered at least one issue that might have affected my results.... Turbo-boost. I realized that Turbo-boost may be affect my tests of multiple-cores... both the time-to-depth test and the game playing tests. My chip is an i7, so when I ran the single core time-to-depth test, it was 15-20% faster than it would have been if the chip had been fully loaded. So this makes the relative improvement in time to depth for multiple threads is actually somewhat better than my first post indicates.

On the game results the interpretation is more difficult, in the single-thread case all four cores are running all the time because I am playing four games in parallel, but in the four-thread case, one core is running for the opponents (and therefore might get turbo-boost) while all four are running for my program. In principle, this reduces the rating of the four-thread version relative to the single-thread version because the opponents are stronger for the four-thread version, but given the tiny time-slices the opponents are playing in, I am not sure this matters.

The only way to tell is to try to disable TurboBoost. Anyone know a safe way to do this? There is no option in the BIOS. Here is a website claiming to have an approach, but I don't know anything about the tool they are referencing.

http://luisjdominguezp.tumblr.com/post/ ... t-in-linux

Are there any other adaptive speed changes the i7 does that might also affect the results? What do others do when testing to avoid problems like these?

- Dan

You need to disable that for sensible testing. It's ok to run with it in real games, as when it kicks in, you get a performance boost. But it does screw up SMP comparisons significantly, because you now have yet another variable in the equation.

So the rating agencies should have this disabled. Do you have a sense of whether it would benefit MP or SP more or is it just random?

Hard to say. Suppose you have a quad-core. Running just one game on one core will see turbo-boost on 100% of the time. With 2 or 3, it will bounce on and off pretty randomly. With 4, it will be off completely.

In essence, having it on randomly speeds up the hardware in 133mhz steps. How many steps depends on the CPU you have. Whether this is particularly bad or not probably depends on what you want. Since most rating lists already have mixed hardware, it is probably something that can be ignored.

I turn it off for obvious reasons.

[Don]

Well, I discovered at least one issue that might have affected my results.... Turbo-boost. I realized that Turbo-boost may be affect my tests of multiple-cores... both the time-to-depth test and the game playing tests. My chip is an i7, so when I ran the single core time-to-depth test, it was 15-20% faster than it would have been if the chip had been fully loaded. So this makes the relative improvement in time to depth for multiple threads is actually somewhat better than my first post indicates.

On the game results the interpretation is more difficult, in the single-thread case all four cores are running all the time because I am playing four games in parallel, but in the four-thread case, one core is running for the opponents (and therefore might get turbo-boost) while all four are running for my program. In principle, this reduces the rating of the four-thread version relative to the single-thread version because the opponents are stronger for the four-thread version, but given the tiny time-slices the opponents are playing in, I am not sure this matters.

The only way to tell is to try to disable TurboBoost. Anyone know a safe way to do this? There is no option in the BIOS. Here is a website claiming to have an approach, but I don't know anything about the tool they are referencing.

http://luisjdominguezp.tumblr.com/post/ ... t-in-linux

Are there any other adaptive speed changes the i7 does that might also affect the results? What do others do when testing to avoid problems like these?

- Dan

You need to disable that for sensible testing. It's ok to run with it in real games, as when it kicks in, you get a performance boost. But it does screw up SMP comparisons significantly, because you now have yet another variable in the equation.

So the rating agencies should have this disabled. Do you have a sense of whether it would benefit MP or SP more or is it just random?

Hard to say. Suppose you have a quad-core. Running just one game on one core will see turbo-boost on 100% of the time. With 2 or 3, it will bounce on and off pretty randomly. With 4, it will be off completely.

In essence, having it on randomly speeds up the hardware in 133mhz steps. How many steps depends on the CPU you have. Whether this is particularly bad or not probably depends on what you want. Since most rating lists already have mixed hardware, it is probably something that can be ignored.

I turn it off for obvious reasons.

I'm trying to figure out how to turn it off (in Linux) for experimentation. I use Linux. I know you compile your own kernels so do you simply compile a kernel that has it turned off?

I found some google tools called i7z that I am taking a look at.

[bob]

Well, I discovered at least one issue that might have affected my results.... Turbo-boost. I realized that Turbo-boost may be affect my tests of multiple-cores... both the time-to-depth test and the game playing tests. My chip is an i7, so when I ran the single core time-to-depth test, it was 15-20% faster than it would have been if the chip had been fully loaded. So this makes the relative improvement in time to depth for multiple threads is actually somewhat better than my first post indicates.

On the game results the interpretation is more difficult, in the single-thread case all four cores are running all the time because I am playing four games in parallel, but in the four-thread case, one core is running for the opponents (and therefore might get turbo-boost) while all four are running for my program. In principle, this reduces the rating of the four-thread version relative to the single-thread version because the opponents are stronger for the four-thread version, but given the tiny time-slices the opponents are playing in, I am not sure this matters.

The only way to tell is to try to disable TurboBoost. Anyone know a safe way to do this? There is no option in the BIOS. Here is a website claiming to have an approach, but I don't know anything about the tool they are referencing.

http://luisjdominguezp.tumblr.com/post/ ... t-in-linux

Are there any other adaptive speed changes the i7 does that might also affect the results? What do others do when testing to avoid problems like these?

- Dan

You need to disable that for sensible testing. It's ok to run with it in real games, as when it kicks in, you get a performance boost. But it does screw up SMP comparisons significantly, because you now have yet another variable in the equation.

So the rating agencies should have this disabled. Do you have a sense of whether it would benefit MP or SP more or is it just random?

Hard to say. Suppose you have a quad-core. Running just one game on one core will see turbo-boost on 100% of the time. With 2 or 3, it will bounce on and off pretty randomly. With 4, it will be off completely.

In essence, having it on randomly speeds up the hardware in 133mhz steps. How many steps depends on the CPU you have. Whether this is particularly bad or not probably depends on what you want. Since most rating lists already have mixed hardware, it is probably something that can be ignored.

I turn it off for obvious reasons.

I'm trying to figure out how to turn it off (in Linux) for experimentation. I use Linux. I know you compile your own kernels so do you simply compile a kernel that has it turned off?

I found some google tools called i7z that I am taking a look at.

Supposedly the mar tools will let you do this. But for every machine I have had, excepting my current macbook, the BIOS had a setting to disable this. MacBooks don't use a BIOS, of course, so one has to tweak the right MSR register bit to turn it off. And the setting is per core, so you have to do it N times...

Somewhere a while back I had seen a reference to how to do this with the MSR tools you can download for linux.

[dchoman]

I've found what appears to be another (small) improvement to this simple parallel, shared hash search. The idea is simple... the first move at the root node is searched in parallel in all threads, but after that, have threads at the same depth search alternating move numbers (odd/even). When they complete their allotment of moves, they just go back and run through the others.. which should be quick because those results are already in the hash table unless one of those moves is taking the other thread a lot of time (in which case the two threads are working in parallel again).

Seems to be worth 5-10% speed up over just searching all the moves in the same order in each thread.

- Dan