How can I switch off hyperthreading?

[Vinvin]

Curious results running Houdini 3 Tactical on Arasan 15 test suite (5s position) on my i7 2600.

4 threads: 161/200 Average time 1.29s
8 threads: 167/200 Average time 1.57s

Maybe, after all, HT is beneficial?

Here are some tests ran by Sedat Canbaz on mate position (10 times the same position !) (but no affinity set) :

http://www.talkchess.com/forum/viewtopi ... 887#437887

Summary :
1) Houdini 2.0c HT OFF 6 physical cores
Houdini 2.0c HT OFF 6 Cores solves the mate average in 38s

2) Houdini 2.0c HT ON 12 Threads
Houdini 2.0c HT ON 12 Threads solves the mate average in 41s

3) Houdini 2.0c HT ON 6 Threads (100 % CPUs usage)
Houdini 2.0c HT ON 6 Threads solves the mate average in 61s
Houdini 2.0c 6T has been tested,when other (Hiarcs 13.2 6T) engine was thinking
In other words:All Computer's 12 CPUs usage was 100 %

4) Houdini 2.0c HT ON 6 Threads (50 % CPUs usage)
Houdini 2.0c HT ON 6 Threads solves the mate average in 45s
Houdini 2.0c 6T has been tested with 6 CPUs,i mean rest 6 CPUs were on idle
In other words:Houdini's during thinking process,there was no any other engine

[Houdini]

Does Houdini 3 still have the same bug as Houdini 2 with affinities set to physical cores (0,2,4 etc)?

When you set affinities in Houndini sometimes the threads are not created on different cores (using 6 threads on a 6 core 12 thread machine). Instead two worker threads are stuck on the same physical core (with one core idling) this slows down Houdini tremendously (sometimes 40% and sometimes even more). This is an awkward bug as it is relatively rare (once or twice a game) and also it can get unstuck after some moves. One can also provoke this in analysis mode by quickly going to new positions - usually after hopping around in a game 20 times one thread gets misallocated (for example two worker threads on core 2 and core 4 is idle). This only happens with afinities set. Without setting affinities and still using 6 threads on a 6 core 12 thread machine it seems not to happen or very very very rarely (i recall only one such incident). Off course with HT off in bios everything works fine.

Unless I don't understand what you're saying, what you describe is a Windows scheduler bug.
If you *force* process affinities in Windows, how could Houdini (or any other process) ever circumvent this?

Robert

[Vinvin]

Curious results running Houdini 3 Tactical on Arasan 15 test suite (5s position) on my i7 2600.

4 threads: 161/200 Average time 1.29s
8 threads: 167/200 Average time 1.57s

Maybe, after all, HT is beneficial?

Here are some tests ran by Sedat Canbaz on mate position (10 times the same position !) (but no affinity set) :

http://www.talkchess.com/forum/viewtopi ... 887#437887
...
4) Houdini 2.0c HT ON 6 Threads (50 % CPUs usage)
Houdini 2.0c HT ON 6 Threads solves the mate average in 45s
Houdini 2.0c 6T has been tested with 6 CPUs,i mean rest 6 CPUs were on idle
In other words:Houdini's during thinking process,there was no any other engine

If affinity worth 7% , this 4th test should be reduced from 45 sec to 42 sec ...

[Laskos]

Curious results running Houdini 3 Tactical on Arasan 15 test suite (5s position) on my i7 2600.

4 threads: 161/200 Average time 1.29s
8 threads: 167/200 Average time 1.57s

Maybe, after all, HT is beneficial?

I'm surprised that an experienced tester like yourself believes that this difference is significant.
Note also that the average time is a more relevant statistic than the number of solutions found.

Robert

Why? The difference is statistically significant, simple square root rule of thumb is not relevant here. I ran 3 times the test, 4 thread was ranging from 159 to 163, 8 thread was 165-169. The time taken was a bit higher with HT on.

[shrapnel]

The Fritz Benchmark is a poor performance indicator for Houdini.
What are your Houdini 3 "autotune" speeds with 4 and 8 threads?

Hi Mr Houdart, I'm a big fan of yours, so I don't wish to argue with you too much . I wonder why you want "autotune" speeds with 4 and 8 threads as I'm running an i7 3930 k. But anyway, here you go...
This with 8 threads :-


Summary:
==========================================================
Split Depth 10, Position 1: 20281 kN/s, idle 87M/s
Split Depth 10, Position 2: 20601 kN/s, idle 58M/s
Split Depth 10, Position 3: 19762 kN/s, idle 76M/s
Split Depth 10, Position 4: 20450 kN/s, idle 78M/s
Split Depth 10 - Average speed: 20273 kN/s, idle 75M/s
==========================================================
Split Depth 12, Position 1: 19614 kN/s, idle 96M/s
Split Depth 12, Position 2: 19945 kN/s, idle 69M/s
Split Depth 12, Position 3: 19677 kN/s, idle 98M/s
Split Depth 12, Position 4: 20698 kN/s, idle 114M/s
Split Depth 12 - Average speed: 19983 kN/s, idle 94M/s
==========================================================
Split Depth 14, Position 1: 19682 kN/s, idle 122M/s
Split Depth 14, Position 2: 19987 kN/s, idle 125M/s
Split Depth 14, Position 3: 20048 kN/s, idle 134M/s
Split Depth 14, Position 4: 19546 kN/s, idle 164M/s
Split Depth 14 - Average speed: 19816 kN/s, idle 136M/s
==========================================================
Split Depth 16, Position 1: 20105 kN/s, idle 155M/s
Split Depth 16, Position 2: 20012 kN/s, idle 162M/s
Split Depth 16, Position 3: 19916 kN/s, idle 153M/s
Split Depth 16, Position 4: 19347 kN/s, idle 215M/s
Split Depth 16 - Average speed: 19845 kN/s, idle 171M/s
==========================================================
Split Depth 18, Position 1: 19262 kN/s, idle 243M/s
Split Depth 18, Position 2: 19840 kN/s, idle 211M/s
Split Depth 18, Position 3: 18986 kN/s, idle 279M/s
Split Depth 18, Position 4: 19218 kN/s, idle 274M/s
Split Depth 18 - Average speed: 19327 kN/s, idle 252M/s
==========================================================
Average CPU time per thread: 598.999 s
CPU-corrected average speed: 19882 kN/s
==========================================================
And this with 4 threads :-

Summary:
==========================================================
Split Depth 10, Position 1: 13490 kN/s, idle 13M/s
Split Depth 10, Position 2: 13651 kN/s, idle 10M/s
Split Depth 10, Position 3: 13295 kN/s, idle 15M/s
Split Depth 10, Position 4: 13765 kN/s, idle 15M/s
Split Depth 10 - Average speed: 13550 kN/s, idle 13M/s
==========================================================
Split Depth 12, Position 1: 13180 kN/s, idle 20M/s
Split Depth 12, Position 2: 13593 kN/s, idle 16M/s
Split Depth 12, Position 3: 13222 kN/s, idle 19M/s
Split Depth 12, Position 4: 13913 kN/s, idle 22M/s
Split Depth 12 - Average speed: 13477 kN/s, idle 19M/s
==========================================================
Split Depth 14, Position 1: 13409 kN/s, idle 24M/s
Split Depth 14, Position 2: 13619 kN/s, idle 22M/s
Split Depth 14, Position 3: 13262 kN/s, idle 28M/s
Split Depth 14, Position 4: 13938 kN/s, idle 29M/s
Split Depth 14 - Average speed: 13557 kN/s, idle 26M/s
==========================================================
Split Depth 16, Position 1: 13336 kN/s, idle 36M/s
Split Depth 16, Position 2: 13566 kN/s, idle 31M/s
Split Depth 16, Position 3: 13196 kN/s, idle 38M/s
Split Depth 16, Position 4: 13160 kN/s, idle 49M/s
Split Depth 16 - Average speed: 13315 kN/s, idle 38M/s
==========================================================
Split Depth 18, Position 1: 12964 kN/s, idle 61M/s
Split Depth 18, Position 2: 13270 kN/s, idle 58M/s
Split Depth 18, Position 3: 12926 kN/s, idle 65M/s
Split Depth 18, Position 4: 13322 kN/s, idle 71M/s
Split Depth 18 - Average speed: 13120 kN/s, idle 64M/s
==========================================================
Average CPU time per thread: 598.919 s
CPU-corrected average speed: 13428 kN/s
==========================================================
Hmm..... a 48 % increase with 8 threads as compared to 4 threads.... seems that you were right about the Fritz benchmark being a poor indicator.... only, 'autotune' results only seem to reinforce the point I was trying to make

The strength increase would be at most about 10 Elo, it would be difficult to see the difference unless you play many hundreds of games.
Your "much much STRONGER" can only be a placebo effect.

Hmm... nothing much to say about that, except that the ELO increase is much more than a measly "10 ELO". This is more of a subjective matter I think and whether you agree with me or not about the percentage of ELO increase, I think you will agree that I've proved that enabling HT is certainly NOT "detrimental" to the performance of the Houdini 3 engine.
As for the 'placebo effect' that you so condescendingly talk about , I think a sudden and drastic increase in the number of my wins, on enabling HT and no change of hardware, against strong Engine players also using Houdini 3, whom I play day in and day out, certainly has to count for more than a mere 'placebo effect', to my way of thinking !
Anyway, I'm happy that you thought my post worth replying to !
On another note, I read somewhere that you will soon be working on a Houdini 4. I suggest you start doing that real soon, as I have inside information that THERE WILL be a Rybka5 soon, before this year ends...... and no, I'm not just speculating like most of the people on the chess forums !
All I know is that its a chess engine developed on LINUX/ UBUNTU by someone other than Mr Vasik who has sold it to the latter. (Sorry, I don't know much about Linux, so I can't explain more). Anyway, from what I can understand, this brilliant guy, an Indian engineering student, who developed this engine in his spare time, doesn't much like Windows, and has sold it to Mr Vasik. Needless to say, this unknown engine has beaten both Houdini 2 and 3 with ease, even only using slow hardware like a Core2Duo and has so impressed Mr Vasik that he has paid a lot of money for it and is busy converting this engine into UCI or something, so that it will run on the more popular and commercially viable Windows... and he will sell it as Rybka 5 !
So, buck up Mr Houdart !

P.S I know that people will only laugh at this post disbelievingly, but every word I have written is true. I won't bother defending myself though as I've already probably said too much.
The only reason I have revealed this is because the brilliant inventor of this engine died tragically of Cerebral Malaria just a few days ago, in India.
Now that he is no more, I don't know see why I should keep it a secret any longer..... Mr Vasik means nothing to me.

[Laskos]

Does Houdini 3 still have the same bug as Houdini 2 with affinities set to physical cores (0,2,4 etc)?

When you set affinities in Houndini sometimes the threads are not created on different cores (using 6 threads on a 6 core 12 thread machine). Instead two worker threads are stuck on the same physical core (with one core idling) this slows down Houdini tremendously (sometimes 40% and sometimes even more). This is an awkward bug as it is relatively rare (once or twice a game) and also it can get unstuck after some moves. One can also provoke this in analysis mode by quickly going to new positions - usually after hopping around in a game 20 times one thread gets misallocated (for example two worker threads on core 2 and core 4 is idle). This only happens with afinities set. Without setting affinities and still using 6 threads on a 6 core 12 thread machine it seems not to happen or very very very rarely (i recall only one such incident). Off course with HT off in bios everything works fine.

Unless I don't understand what you're saying, what you describe is a Windows scheduler bug.
If you *force* process affinities in Windows, how could Houdini (or any other process) ever circumvent this?

Robert

It happened to me too in test suites with affinities set to physical cores. In the middle of the suite, one core becomes idle, and everything slows down dramatically (by some maybe 70%). Both in Fritz and in Arena. I have my cheapo i7 2600 system for only 2 days now, I was so much worried that my CPU is broken (I overclocked it a bit with the stock cooler) that I left overnight the Prime95 torture test, all was fine. Probably a Windows 7 bug.

Kai

[Houdini]

Why? The difference is statistically significant, simple square root rule of thumb is not relevant here. I ran 3 times the test, 4 thread was ranging from 159 to 163, 8 thread was 165-169. The time taken was a bit higher with HT on.

During the development of the Tactical Mode I've seen differences in the number of solutions of up to 10 between successive runs - with as few as 2 threads.
The average solution time has been a much more reliable indicator.

Robert

[Houdini]

I wonder why you want "autotune" speeds with 4 and 8 threads as I'm running an i7 3930 k.

My bad, for your computer it's obviously 6 and 12 threads.
Results with 4 and 8 threads are meaningless for your system.

[IQ]

Does Houdini 3 still have the same bug as Houdini 2 with affinities set to physical cores (0,2,4 etc)?

When you set affinities in Houndini sometimes the threads are not created on different cores (using 6 threads on a 6 core 12 thread machine). Instead two worker threads are stuck on the same physical core (with one core idling) this slows down Houdini tremendously (sometimes 40% and sometimes even more). This is an awkward bug as it is relatively rare (once or twice a game) and also it can get unstuck after some moves. One can also provoke this in analysis mode by quickly going to new positions - usually after hopping around in a game 20 times one thread gets misallocated (for example two worker threads on core 2 and core 4 is idle). This only happens with afinities set. Without setting affinities and still using 6 threads on a 6 core 12 thread machine it seems not to happen or very very very rarely (i recall only one such incident). Off course with HT off in bios everything works fine.

Unless I don't understand what you're saying, what you describe is a Windows scheduler bug.
If you *force* process affinities in Windows, how could Houdini (or any other process) ever circumvent this?

Robert

Let me explain again. System: a 990X with HT on (6 real cores 12 HThreads), LP in use and affinities set to the even cores (0,2,4,6,8,10). Houdini will sometimes not use all even cores. Very rarely it will get stuck and use only 5 (sometimes even less cores). As Houdini is set for 6 Threads this means that two of houdinis threads are allocated to the same physical core. This slows Houdini down (sometimes 40%, and if more threads are glued to the same core even worse). This is rare! But one can provoke it. I tried it on several I7 processors on different machine - on the 4 core (8HT) is was extremly difficult to reproduce - so much that it is a non issue. But on the 6 core (12HT) machines it happens much more frequently. Without setting affinities this did not happen - the load is distributed evenly between the 12hthreads (or Houdnini recovers much quicker and unnoticably). So if you have a 6 physical core+ machine, i would advise to turn HT off, if you only want to use 6 threads.

P.S.: It might not be a Windows 7 scheduler error. I believe it could also be a race condition in the houdini multithreaded code.

[syzygy]

P.S.: It might not be a Windows 7 scheduler error. I believe it could also be a race condition in the houdini multithreaded code.

Assuming Houdini leaves the allocation of threads to cores to the OS (which is very very likely), it can only be the OS that messes this up. You write that sometimes there are idle cores, while other cores are executing two threads. That should not happen, at least not for longer than 1/100th of a second or so. The OS should take care of this.