This is obtained by comparing the nodes/sec in infinite analysis of a few positions (early game / middle game positions, not endgame positions), using the 64-bit exe and the 32-bit exe.
(for some of the data, see http://www.talkchess.com/forum/viewtopic.php?t=30013)
I recall that with Glaurung 2.1 (BTW, where Jim Ablett's 64-bit and 32-bit compiles behaved identically ), I found the 64-bit to be around 40% faster than the 32-bit...
And with Rybka, Zappa, you get +70%, +80% (you can also say, with reason, that the 64-bit is the reference, and that means that the 32-bit is 40-45% slower)
Any explanation for the (only) +24-28% of Stockfish?
Stockfish 1.5 64bit seems (only) 24 to 28% faster than 32bit
Moderators: hgm, Rebel, chrisw
-
- Posts: 2041
- Joined: Wed Mar 08, 2006 8:30 pm
-
- Posts: 2684
- Joined: Sat Jun 14, 2008 9:17 pm
Re: Stockfish 1.5 64bit seems (only) 24 to 28% faster than 3
Measuring nodes/sec works only when compile behaves identicallyernest wrote:This is obtained by comparing the nodes/sec in infinite analysis of a few positions (early game / middle game positions, not endgame positions), using the 64-bit exe and the 32-bit exe.
(for some of the data, see http://www.talkchess.com/forum/viewtopic.php?t=30013)
I recall that with Glaurung 2.1 (BTW, where Jim Ablett's 64-bit and 32-bit compiles behaved identically ), I found the 64-bit to be around 40% faster than the 32-bit...
And with Rybka, Zappa, you get +70%, +80% (you can also say, with reason, that the 64-bit is the reference, and that means that the 32-bit is 40-45% slower)
Any explanation for the (only) +24-28% of Stockfish?
You have big difference in node /sec for different positions. Of course if the two compiles are functional equivalent (not identical) as in this case the net difference is zero and you still can use the node/sec metric but you need much more positions, hundreds at least.
An indirect measure of speed difference in this case is possible after testing the two engines and comparing elo, from elo difference you can infere the _average_ speed difference.
Another possibility, if you are willing to compile yourself, is that I send to you the sources modified with std::stable_sort() instead of std::sort(), so that you compile the two sources and can correctly compare speed difference with a direct measure.
Your choice
-
- Posts: 12541
- Joined: Wed Mar 08, 2006 8:57 pm
- Location: Redmond, WA USA
Re: Stockfish 1.5 64bit seems (only) 24 to 28% faster than 3
From:ernest wrote:This is obtained by comparing the nodes/sec in infinite analysis of a few positions (early game / middle game positions, not endgame positions), using the 64-bit exe and the 32-bit exe.
(for some of the data, see http://www.talkchess.com/forum/viewtopic.php?t=30013)
I recall that with Glaurung 2.1 (BTW, where Jim Ablett's 64-bit and 32-bit compiles behaved identically ), I found the 64-bit to be around 40% faster than the 32-bit...
And with Rybka, Zappa, you get +70%, +80% (you can also say, with reason, that the 64-bit is the reference, and that means that the 32-bit is 40-45% slower)
Any explanation for the (only) +24-28% of Stockfish?
http://www.talkchess.com/forum/viewtopi ... 39&t=30013
I got:
JA Intel builds:
1499604 / 1172057 = 1.2794633708087575945538484903038
DC MSVC builds:
1454803 / 1162137 = 1.2518343362271401736628297696399
So my figures agree with yours. That only indicates to me that it is not move generation and bitmap manipulation that dominates now.
-
- Posts: 2041
- Joined: Wed Mar 08, 2006 8:30 pm
Re: Stockfish 1.5 64bit seems (only) 24 to 28% faster than 3
How about Rybka and Zappa (still quite dominating...)? Do you think they intentionally degraded their 32-bit version?Dann Corbit wrote:That only indicates to me that it is not move generation and bitmap manipulation that dominates now.
-
- Posts: 12541
- Joined: Wed Mar 08, 2006 8:57 pm
- Location: Redmond, WA USA
Re: Stockfish 1.5 64bit seems (only) 24 to 28% faster than 3
I think that we get carried away over NPS. (For instance, people get genuinely offended that Rybka NPS seem to be scaled lower than other NPS for commensurate engines).ernest wrote:How about Rybka and Zappa (still quite dominating...)? Do you think they intentionally degraded their 32-bit version?Dann Corbit wrote:That only indicates to me that it is not move generation and bitmap manipulation that dominates now.
The proof of the pudding is in the eating. The real question is "Does it play better?"
It appears at first blush that SF 1.5 is stronger than SF 1.4.
On the other, other hand -- it might be worth doing a profile to see where the time is going with the 64 bit version.
-
- Posts: 1808
- Joined: Wed Mar 08, 2006 9:19 pm
- Location: Oslo, Norway
Re: Stockfish 1.5 64bit seems (only) 24 to 28% faster than 3
No. The 64-bit speedup of Rybka and Zappa is precisely what you would expect for a bitboard program which does exactly the same thing in 32-bit and 64-bit mode. Stockfish doesn't do the same. Several of the most time-consuming low-level bitboard operations exist in two versions; a plain and simple version for 64-bit mode, and an uglier and more complex version optimized for 32-bit mode. Most programs don't do this, and therefore Stockfish doesn't slow down as much as some other bitboard programs on 32-bit computers.ernest wrote:How about Rybka and Zappa (still quite dominating...)? Do you think they intentionally degraded their 32-bit version?Dann Corbit wrote:That only indicates to me that it is not move generation and bitmap manipulation that dominates now.
In other words, Stockfish doesn't gain "only" 24-28% because the 64-bit version is slow, but because the 32-bit version is fast.
For the comparison between Stockfish and Glaurung, it's hard to say exactly where the difference comes from, but a lot of low-level code has been changed, so it isn't a huge surprise that the speedup is not exactly the same.
-
- Posts: 2041
- Joined: Wed Mar 08, 2006 8:30 pm
Re: Stockfish 1.5 64bit seems (only) 24 to 28% faster than 3
I understand, Tord.Tord Romstad wrote:...a plain and simple version for 64-bit mode, and an uglier and more complex version optimized for 32-bit mode.
Well, that is quite a big programming work supplement!
And it can make it more difficult for the 2 versions to behave exactly the same...