Stockfish 1.7

Discussion of anything and everything relating to chess playing software and machines.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
BrandonSi

Re: Stockfish 1.7

Post by BrandonSi » Fri Apr 09, 2010 12:26 am

i7 820QM (mobile i7) HT enabled = 5 cpu under Fritz 12

I should mention this has happened with every version of Stockfish, even 1.6.x. No idea why it would get an odd number? :)

PauloSoare
Posts: 1335
Joined: Thu Mar 09, 2006 4:30 am
Location: Cabo Frio, Brasil

Re: Stockfish 1.7

Post by PauloSoare » Fri Apr 09, 2010 12:28 am

I will have much fun ! Thanks to Tord, Marco and Joona !

Dann Corbit
Posts: 10182
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: Stockfish 1.7

Post by Dann Corbit » Fri Apr 09, 2010 12:38 am

Eelco de Groot wrote:
Dann Corbit wrote:
Aaron Becker wrote:
nepossiver wrote:Was Dann Corbit smooth scaling introduced into the source? I remember the few tests done showed either no difference or a 20-30 increase in ELO (which is what I found in 1+1 games).
Here is the new nullmove depth reduction calculation:

Code: Select all

        // Null move dynamic reduction based on depth
        int R = 3 + (depth >= 5 * OnePly ? depth / 8 : 0);

        // Null move dynamic reduction based on value
        if (refinedValue - beta > PawnValueMidgame)
            R++;
I don't know how close this is to Dann's formulation.
it's a new and very interesting idea (I never saw it before) that will prune more and more aggressively as a function of existing search depth.

For instance, if you are at a depth of 32, R would be 3+4=7.
Did you ever see a 7 ply reduction before? It's the most unheard of thing I have ever heard of!
;-)
Am I hearing some criticism here? This too simple Dann :) ? You want to do a reduction of seven plies only for very promising moves and the rest should be reduced by cos²ln√π(α + Δ(approximateEval - β) + depth) + log(number of days between Easter 2010 and the start of the new Mayan calendar)?

I'm sure we can arrange that!

We can nullmove, faster, deeper, better than anybody in the business regards,

Eelco
I am interested to try also a factor that depends on mobility, but for the current stockfish, it seems that it is only available for the root move search.

PauloSoare
Posts: 1335
Joined: Thu Mar 09, 2006 4:30 am
Location: Cabo Frio, Brasil

Re: Stockfish 1.7

Post by PauloSoare » Fri Apr 09, 2010 12:53 am

Q6600, WinXP64, 2 threads.

Uri Blass
Posts: 8599
Joined: Wed Mar 08, 2006 11:37 pm
Location: Tel-Aviv Israel

Re: Stockfish 1.7

Post by Uri Blass » Fri Apr 09, 2010 12:57 am

bigo wrote:why bother to realease something if it's not stronger?? do you enjoy wasting everyones time???
:evil:
It is clearly stronger and it seems to me that it perform better at longer time control so I will not be surprised if it can top the CEGT 40/20 list or if it can top the CCRL 40/40 list

From the IPON rating list I see the following data that suggests 65 elo improvement relative to stockfish1.6:

STOCK17_1

Stockfish 1.7 JA - Rybka 3 mp (2907) 30.5 - 26.5 53.51% Perf=2931
Stockfish 1.7 JA - Naum 4.2 (2823) 35.0 - 23.0 60.34% Perf=2895
Stockfish 1.7 JA - Deep Shredder 12 (2801) 37.5 - 19.5 65.79% Perf=2914
Stockfish 1.7 JA - Komodo64 1.0 JA (2781) 38.0 - 19.0 66.67% Perf=2901
Stockfish 1.7 JA - Zappa Mexico II (2709) 44.0 - 12.0 78.57% Perf=2934
Stockfish 1.7 JA - Protector 1.3.2 JA (2698) 44.5 - 11.5 79.46% Perf=2933
Stockfish 1.7 JA - Onno-1-1-1 (2682) 41.0 - 16.0 71.93% Perf=2845
Stockfish 1.7 JA - Spark-0.3 VC(a) (2672) 44.5 - 12.5 78.07% Perf=2892
Stockfish 1.7 JA - Deep Sjeng WC2008 (2671) 46.5 - 10.5 81.58% Perf=2929
Stockfish 1.7 JA - Toga II 1.4 beta5c BB (2661) 43.5 - 12.5 77.68% Perf=2877
405.0 - 163.0 71.30% Perf=2898




568 out of 1000 games played

Daniel Shawul
Posts: 3762
Joined: Tue Mar 14, 2006 10:34 am
Location: Ethiopia
Contact:

Re: Stockfish 1.7

Post by Daniel Shawul » Fri Apr 09, 2010 1:03 am

I use that too. I belive it is a matte of time before R=3 becomes obsolete.

yanquis1972
Posts: 1762
Joined: Tue Jun 02, 2009 10:14 pm

Re: Stockfish 1.7

Post by yanquis1972 » Fri Apr 09, 2010 1:24 am

under the shredder GUI i am getting 99% usage with max and threads settings @ 8, so if anyone knows how to get it run fullbore in aquarium lemme know, seems to be a GUI issue.

after seeing the incredible IPON scores i've decided to run a 2+12 silver suite match ponder off against R3, i hope to complete it & will post results if i do.

yanquis1972
Posts: 1762
Joined: Tue Jun 02, 2009 10:14 pm

Re: Stockfish 1.7

Post by yanquis1972 » Fri Apr 09, 2010 4:03 am

can i get some rough NPS estimates for stockfish? even though it's reporting 99% CPU usage its getting slaughtered by rybka. doesn't seem to gel... (-4 =2 +0)

i'm running it on a remote 2.93 ghz nehalem and it looks like it gets around ~6.5M nps out of the openings.

Marc MP

Re: Stockfish 1.7

Post by Marc MP » Fri Apr 09, 2010 4:13 am

yanquis1972 wrote:can i get some rough NPS estimates for stockfish? even though it's reporting 99% CPU usage its getting slaughtered by rybka. doesn't seem to gel... (-4 =2 +0)

i'm running it on a remote 2.93 ghz nehalem and it looks like it gets around ~6.5M nps out of the openings.
6 games is not a lot. I ran a 100 games match out of 50 opening positions and SF 1.7 got beaten badly by Robbolito 0.085g3: + 13, -54, =33 for 29.5/100. My time control was extremely fast (2min + 2 sec) considering I have an old pentium.

mcostalba
Posts: 2684
Joined: Sat Jun 14, 2008 7:17 pm

Re: Stockfish 1.7

Post by mcostalba » Fri Apr 09, 2010 5:36 am

michiguel wrote:
mcostalba wrote:
alpha123 wrote: I'd agree with you. It detected 2 threads on my quad, fortunately I saw that before I started testing it on playchess :wink:. It does use all 4 when set too, though.

Guys, maybe a 1.7.1 with proper thread detection and null move bug fix is needed.

Peter
Could you (and also all the other people that experience problems with CPU detection) please post type of CPU you have ? Thanks.

The null move bug will require regression test anyway so although the fix could be quick the testing will take some time and we would wait at least a week or two to collect all the bug reports before to release a mainteinance version.
What is the philosophical idea behind auto detecting then number of cores? Based on the things I read before, in the spirit of SF it looked like it should leave this task to the interface. Right?

Miguel
The GUI does not set this value.

Until 1.6.3 we used what is now called builtin_cpu_count() in misc.cpp to detect the number of cores, this works but has the problem that _if_ hyper threading is enabled it _usually_ reports the double of the real physical cores.

So this time we add function HT_enabled() to detect hyperthreading and, in this case, divide by two the number of reported CPUs, see cpu_count().

The idea is that if you have, say 4 physical cores, but with HT enabled the builtin_cpu_count() returns 8 then you really want to consider only 4 cores for optimal performance because SF, as also all the other SMP engines works best if the number of CPU is set to the real physical cores, not the "logical" ones when HT is enabled.

The problem that is arising is that function HT_enabled() is broken at least for some i7 CPU models.

So we have two options:

1) Fix HT_enabled() to works always: but this is very difficult because, reading Intel documentation, the proper way to detect HT is brain damaged complex (this time Intel made a real idiotic decision with HT detection design). Current routine works always on older types of CPU, but newer ones require a much more complex approach.

2) Remove HT_enabled() entirely and revert to 1.6.3 behaviour. In this case people should remember of disable HT or, when HT is enabled to manually set the correct number of cores through UCI options "threads" to the number of real cores (that normally is the half of what is reported with HT enabled).

Post Reply