Author: Bruce Moreland
Date: 14:19:52 02/04/99
Go up one level in this thread
On February 04, 1999 at 14:45:54, James Robertson wrote: >Actually, there was another bug as well. How much should the null move improve a >program's performance? It seems to be searching .5 to 1 plies farther, and >approx. 2/3 to 3/4 the number of nps. Is this normal? In matches against the >non-null move version, it seems to be edging it out by with 6 wins, 4 losses. In >a match against Cilian, the null moves actually seem to be doing worse. > >James Here is some data. The first section is LCTI running on a P6/200 for 210 seconds per position. I'll tell you how to read the first line. "12/9" means that the version with null move completed 12 plies, the version without completed 9 plies. The "!" simply indicates that the depth is different, I put this in so I could grep for it. The first time is the time it took the null-move version to complete the last ply that both finished, the second time is the time it took the non-null move version to complete the same ply. In the first line, it took the null move version 3 seconds to complete ply 9, and the non-null version 3 minutes. The percentage at the end is the ratio of these times. If you were to take all of the times and add them together, then compute this ratio, you'd get approximately 400%. So in the case of my program, you get to the same depth in 1/4 of the time, typically. position 001 12/ 9! 00:00:03.755 00:03:04.606 4916.27% position 002 11/ 8! 00:00:30.985 00:01:17.993 251.71% position 003 10/ 8! 00:00:11.797 00:01:09.400 588.29% position 004 11/ 9! 00:00:29.342 00:02:57.195 603.90% position 005 10/ 8! 00:00:14.221 00:01:30.951 639.55% position 006 13/ 9! 00:00:01.963 00:01:11.633 3649.16% position 007 10/ 8! 00:00:09.985 00:01:57.429 1176.05% position 008 10/ 8! 00:00:07.521 00:00:48.259 641.66% position 009 10/ 8! 00:00:04.827 00:00:53.887 1116.37% position 010 10/ 8! 00:00:11.046 00:01:43.399 936.08% position 011 13/ 9! 00:00:05.478 00:01:50.379 2014.95% position 012 11/ 8! 00:00:10.365 00:01:46.423 1026.75% position 013 10/ 8! 00:00:12.287 00:03:27.318 1687.30% position 014 10/ 8! 00:00:11.968 00:03:02.042 1521.07% position 015 12/ 9! 00:00:07.802 00:03:11.165 2450.21% position 016 10/ 8! 00:00:18.647 00:02:39.299 854.29% position 017 10/ 8! 00:00:17.816 00:02:49.254 950.01% position 018 9/ 7! 00:00:09.824 00:02:19.861 1423.67% position 019 11/ 8! 00:00:20.931 00:01:01.128 292.05% position 020 19/18! 00:00:57.643 00:02:21.143 244.86% position 021 17/15! 00:00:28.071 00:01:57.419 418.29% position 022 17/10! 00:00:28.030 00:01:28.037 314.08% position 023 14/13! 00:01:11.833 00:01:13.827 102.78% position 024 15/15 00:02:32.489 00:02:11.869 86.48% position 025 15/15 00:02:24.288 00:02:28.394 102.85% position 026 14/10! 00:00:06.139 00:01:07.227 1095.08% position 027 15/14! 00:01:19.274 00:02:15.115 170.44% position 028 15/11! 00:00:03.275 00:00:58.104 1774.17% I can produce a chart for ECM, but it'd be bigger. It looks the same. The next section is a comparison of solutions for the ECM suite. The null-move version solved 619 in 20 seconds, the non null-move version solved 565 in the same time. It's worth noting that the null move version solved in excess of 565 (meaning 569 in this case) in 9 seconds. I conclude from this that the null-move version is approximately twice as fast tactically, and this is approximately true if you look at other times, though not always strictly true. If you combine these results with the LCTI results I believe the data indicates that null-move search gets tactical problems more quickly, but it takes a little more depth to get them. It takes me 1/4 the nodes to get through depth D, but I only get the answer in 1/2 the time. I'll take it though. #### 444 447 ---- ---- ---- 0001 398 351 0002 461 410 0003 497 438 0004 525 459 0005 537 472 0006 545 487 0007 552 502 0008 562 511 0009 569 521 0010 575 525 0011 581 530 0012 585 534 0013 592 536 0014 594 540 0015 595 544 0016 599 549 0017 606 554 0018 609 556 0019 615 562 0020 619 565
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.