Core i7 and chess

[bob]

I am still trying to understand this topic. What, if anything, should I infer by comparing lines 1 and 5 in the following table (copied from http://www.sedatchess.com/craftybenchmarks.html )?

Code: Select all

------------------------------------------------------------------------------------------- 
Program        Exe      Processor       GHz     Threads   Kn/s       Time    Hardware User 
------------------------------------------------------------------------------------------- 
Crafty v22.8   64 bit   i7 920 HT off  @4.00GHz   4CPU    18072085   8.27    Phil Harris 
Crafty v22.8   64 bit   2x QX9775      @4.00GHz   8CPU    21239451   9.34    Lukas Cimiotti 
Crafty v22.8   64 bit   i7 920 HT off  @3.80GHz   4CPU    16811057   9.63    Lukas Cimiotti 
Crafty v22.8   64 bit   Intel QX9650   @3.81GHz   4CPU    15404968   10.22   Sedat Canbaz 
Crafty v22.8   64 bit   i7 920 HT on   @4.00GHz   8CPU    18708859   12.17   Phil Harris 
Crafty v22.8   64 bit   Intel QX6700    2.66GHz   4CPU    11000419   14.52   Sedat Canbaz 
Crafty v22.8   64 bit   AMD X2 4600+    2.40GHz   2CPU    4084622    31.83   Sedat Canbaz 
Crafty v22.8   32 bit   AMD Turion Mob. 2.20GHz   2CPU    2286735    57.21   Sedat Canbaz 
Crafty v22.8   32 bit   AMD 64 3400+    2.40GHz   1CPU    1431694    78.64   Sedat Canbaz 
Crafty v22.8   32 bit   Pentium 4       3.20GHz   1CPU    839640     133.05  Levent Kaya
Crafty v22.8   32 bit   Intel Celeron   1.70GHz   1CPU    423000     264.25  Sedat Canbaz 
-------------------------------------------------------------------------------------------

that hyperthreading does not work for Crafty. looks like the i7 with 4 is about as good as previous processors with 8 real cores...

[bob]

Code: Select all

------------------------------------------------------------------------------------------- 
Program        Exe      Processor       GHz     Threads   Kn/s       Time    Hardware User 
------------------------------------------------------------------------------------------- 
Crafty v22.8   64 bit   i7 920 HT off  @4.00GHz   4CPU    18072085   8.27    Phil Harris 
 
Crafty v22.8   64 bit   i7 920 HT on   @4.00GHz   8CPU    18708859   12.17   Phil Harris 
-------------------------------------------------------------------------------------------

These two seem to state HT would be better left on!

Sean

No, you are using the _wrong_ comparison. HT on might slightly increase the NPS. But it will _significantly_ slow the time-to-solution down because of parallel search overhead (extra nodes searched).

[bob]

Code: Select all

------------------------------------------------------------------------------------------- 
Program        Exe      Processor       GHz     Threads   Kn/s       Time    Hardware User 
------------------------------------------------------------------------------------------- 
Crafty v22.8   64 bit   i7 920 HT off  @4.00GHz   4CPU    18072085   8.27    Phil Harris 
 
Crafty v22.8   64 bit   i7 920 HT on   @4.00GHz   8CPU    18708859   12.17   Phil Harris 
-------------------------------------------------------------------------------------------

These two seem to state HT would be better left on!

Sean

No they dont. I don't know where you get that. There is a measly increase in NPS for a gargantuan loss in parallel efficiency. A clear losing situation.

The search rates in NPS are essentially equal, but with HT enabled the search time is roughly 50% more. So with HT enabled, the search hits about 50% more nodes? Why is this bad (or inefficient)? Forgive me, I'm still confused. Please help me grasp this!

you just make the tree 50% bigger or so. So even if you search a faster NPS, you have to search way more nodes, a losing proposition...

[zullil]

you just make the tree 50% bigger or so. So even if you search a faster NPS, you have to search way more nodes, a losing proposition...

How would this situation change if there were eight actual cores but no hyper-threading? I'm still missing something here.

[Dirt]

The search rates in NPS are essentially equal, but with HT enabled the search time is roughly 50% more. So with HT enabled, the search hits about 50% more nodes? Why is this bad (or inefficient)? Forgive me, I'm still confused. Please help me grasp this!

I'll try to explain a little more. Most chess engines use alpha-beta search. This lets them discard large portions of the search tree without any loss of knowledge. You need to know what happened earlier in the search to know what to discard, and the the more parallel the search the less likely it is you'll have the necessary information available to do that. So it takes much more than just a few more nodes to make searching with more threads a net benefit.

[Dirt]

you just make the tree 50% bigger or so. So even if you search a faster NPS, you have to search way more nodes, a losing proposition...

How would this situation change if there were eight actual cores but no hyper-threading? I'm still missing something here.

Then you would be searching almost double the nodes, which would still be an improvement when searching the 50% larger tree.

[Karmazen & Oliver]

Some guy would run a fritz 9 benchmark and the results would be updated on that page. What about the Core i7? Has it been compared to those processors? Its a shame Intel do not support chess as it would be great to see Fritzmarks on mainstream websites.

Are there any Core i7's on Playchess and how many threads does it have? The core i7 supports hyperthreading which may not be such a good thing for chess if i recall from a conversation here.

I think that HT it´s not bad in this case...

Anyway, be careful with the iCore, they are "more of ~300 W" to full load, certainly something very I inconvenience in the home-sector, and inconvenience reduced spaces for humans... (hot and noise), in idle OK, but in chess, cpu runs a lot of full load... it´s to lot of hot

Evidently they are very strong in calculations, but there are times that he/she/we doesn't care to wait a little, if the temperature of the room doesn't go up 3 or 4 ºC, or if the computer makes an annoying noise. I like more... low watts cpu, it´s good for bill, and green.

bye. Oliver from Spain

[zullil]

The search rates in NPS are essentially equal, but with HT enabled the search time is roughly 50% more. So with HT enabled, the search hits about 50% more nodes? Why is this bad (or inefficient)? Forgive me, I'm still confused. Please help me grasp this!

I'll try to explain a little more. Most chess engines use alpha-beta search. This lets them discard large portions of the search tree without any loss of knowledge. You need to know what happened earlier in the search to know what to discard, and the the more parallel the search the less likely it is you'll have the necessary information available to do that. So it takes much more than just a few more nodes to make searching with more threads a net benefit.

So maybe you can search at a slightly improved rate, but at the cost of having to consider an awful lot of nodes that should have been pruned anyway? Thus despite the improved NPS, in reality you're taking a beating in terms of performance.

Thanks for the help. I think I understand now.

[Mark]

Kind of an aside here, but does a standard Q6600 have hyperthreading? If so, I'd like to be able to turn it off... Thanks!

Unless you can back it up with a link, I believe hyperthreading is not present in (earlier) Quads and Dual Cores. It has resurfaced in the Core i7 (dubbed Intel Core 3).

That's good. Thanks!

[bob]

you just make the tree 50% bigger or so. So even if you search a faster NPS, you have to search way more nodes, a losing proposition...

How would this situation change if there were eight actual cores but no hyper-threading? I'm still missing something here.

OK, if You have eight actual threads, the NPS (I am talking Crafty here) will be roughly 8x faster. Suppose you were searching 2.5M nps on a single CPU. With eight, you would see 20M nodes per second. But, again with Crafty, for each CPU you add beyond the first, the one-cpu tree size grows by 30%.

First, let's look at the 2 cpu numbers.

1cpu 2.5M nodes per second. takes 60 seconds to search 150M nodes

2cpu 5.0M nodes per second, but the tree grows to 150M + .25M extra overhead (I just ran a few tests to get an average for this number). So we search 175M nodes per second at 5M nodes per second, which takes about 35 seconds. The speedup is then 60sec/35sec = 1.7x faster.

4cpu. 10.0M nodes per second, but tree grows by 40M extra nodes for a total of 190M. 190M divided by 10M nps = 19 seconds. Speedup is 60/19 = 3.1x faster.

This continues at least thru 16 processors.

The problem with hyperthreading is that in the above 2 cpu example (one processor with two logical (hyper-threaded) CPUs. You search 175M nodes, but at not much over 2.5M nodes per second. And that is a big loser as you actually take significantly longer to do the same search compared to the time taken by one processor no hyperthreading...

hope that helps. If you have Crafty and a multiple-cpu machine, you can run the test yourself... Run a single position several times with 2 and 4 to get average results. You will see that if you double the nps by using two real CPUS, the overhead is more than compensated for by the extra NPS. But with hyperthreading, since the NPS doesn't go up very much, suddenly the overhead is enough to make it run slower rather than faster.