Page 1 of 1
Node counting
Posted: Thu Jan 20, 2011 5:30 pm
by BB+
Since Jeremy seems to like this forum to be a holding place for commonly desired information, here are some comments about node counting by VR.
Firstly, with Rybka 1.3 the node count was "normal", over 1Mnps on the given machine in 2004:
Subject: Rybka @ 64 bit
From: Vasik Rajlich
Message Number: 356880
Date: March 27, 2004 at 04:14:02
Rybka 1.3
---
Athlon 3400+, 32 bit win XP: 1,201,030 nps
Athlon 3400+, 64 bit win server '03, 32 bit .exe: 1,201,030
Athlon 3400+, 64 bit win server '03, 64 bit .exe (win DDK compiler): 1,506,580
The speedup is around 20%.
There is a small hopefully-temporory caveat, something is choking the UCI output
under the 64 bit OS. When Rybka sends all of the UCI "info XXX" commands to the
GUI, the nps rate drops by about 20%! The above is with all UCI "info XXX"
commands disabled.
Vas
Next (well, actually 4 days previous) there is part of a long post about the "Top Three" engines:
Subject: Re: Shredder 8 secret: search depth?
From: Vasik Rajlich
Message Number: 356131
Date: March 23, 2004 at 05:05:56
True. What exactly the "Big Three" engines do is not 100% clear, however after considerable
playing around I can make some observations/hypotheses.
Shredder is the most aggressively tuned, and the "deepest" searcher.
It's possible that it is not reporting its NPS rates truthfully
[...]
Depth I agree about [that it is hard to compare between engines].
There aren't too many ways to calculate NPS, though, this is real info IMO.
Finally, in response to Cozzie concerning Carrisco's noting that "nodes" in Rybka 1.0 actually
decreased in some examples:
Subject: Re: The Rybka Flamewar & question for Vasik
From: Vasik Rajlich
Message Number: 487297
Date: February 17, 2006 at 04:23:50
[...]
>I would think that no matter how creative your counting scheme is, it should still increase monotonically.
>
>anthony
[...]
Actually, if you go in a debugger, you can trivially see that two quantities are being combined.
One I call "gulp", this is for me the interesting figure (for my private tests).
The second is a simple ticker for the next I/O check.
As I've pointed out elsewhere, the "modern" Rybka node-counting method simply counts White make-moves and divides by 7, so it is low by a factor of ~14, or maybe 15-16 if you include null moves in your accounting. I've never been interested in figuring out how the parallel speed-up is computed, but I think only the primary cpu counts nodes, and there is a generic multiplier folded in.
Re: Node counting
Posted: Thu Jan 20, 2011 8:10 pm
by hyatt
what more can you say beyond "obfuscation"???
There is one correct way to count nodes. One can quibble about whether only legal positions (or all positions) are counted, but a node is a node. One can make a case that the transposition table causes the nodes search to be significantly understated, since a hash hit replaces a significant search effort (and number of nodes) with an instant result that avoids searching. And I suppose one could store the node count as part of the hash entry and correct using that. But to me, if you make a move, you create a new position. Period. That is the classic graph theory definition and everyone (apparently until Rybka came along) used. And still use, with that one notable exception Trying to justify nonsense is, in itself, nonsense.
Re: Node counting
Posted: Thu Jan 20, 2011 8:32 pm
by BB+
Responding to Enrico Carrisco's first inquiries, claiming that he suspects "[...] Hiarcs is doing something similar to Rybka. The per-node tactical strength of Hiarcs is phenomenal".
Subject: Re: Fairly good examples of eval inconsistencies between Rybka versions...
From: Vasik Rajlich
Message Number: 476477
Date: January 03, 2006 at 06:16:29
>> [VR to Enrico]: If you don't mind, I have two nosy questions for you:
>> 1) What is the Hiarcs definition of node?
>I'm not clear on what you're asking here with your inclusion of HIARCS. Our
>definition does not differ from the general definition of a node (any move
>made by the program in its "thinking" - i.e. updating a data structure.)
>
>Perhaps I am missing some sarcasm?
[...]
Re. Rybka Beta vs Rybka Preview 1.01, I changed Rybka's node-counting to give
partial credit for "extra work done inside a node". This was done to stabilize
the nps figure as in Rybka Beta it can fluctuate wildly. [...]
Re: Node counting
Posted: Fri Jan 21, 2011 11:11 pm
by hyatt
Years ago there was an "anti-nps" movement. Where the assumption was that "intelligence" was inversely proportional to NPS. So a slower/lower NPS implied more intelligence. And it made for good advertising. And fertilizer.
Somewhat akin to the PIV from intel. Fastest clock speed around. But slowest CPU overall. A 2ghz AMD would smoke my old PIV at 2.8ghz. But for those that demanded the highest mhz, Intel got the business...