The table below shows some performance data for two computers, one with a 32-bits processor and the other with 64 bits. A special benchmark version was used, for which the search depth could be pre-fixed. Further, the graphical-user-interface, clock-control, and randomization were removed, while code to collect perfomance counters was added. Both computers used first a search depth of eight and subsequently a depth of ten. The board position after move 22. Bg4-d1 in the game shown on page Played Game was used for each of the four tests.

processor	Intel(R)Core™2CPU	Intel(R) i7 CPU		Intel(R)Core™2CPU	Intel(R) i7 CPU
	6600 2.40GHz	860 @ 2.80Hz		6600 2.40GHz	860 @ 2.80Hz
bits	32	64		32	64
memory (GB)	2	8		2	8
fixed search depth	8	8		10	10
used seconds	6	4		58	56
played move	Be4-c6	Be4-c6		Be4-c6	Be4-c6

You see that each of the four tests led to the same move  Be4-c6. And, the i7 is only who seconds faster. So, it does not matter whether or not you buy a 32 or an expensive 64-bits computer? Well, there are some more performance counters to look at.

processor	Intel(R)Core™2CPU	Intel(R) i7 CPU		Intel(R)Core™2CPU	Intel(R) i7 CPU
bits	32	64		32	64
fixed search depth	8	8		10	10
moves generated	30,788,467	30,788,467		380,294,447	744,121,981
moves per second	5,131,411	7,697,116		6,556,800	13,287,892

Note first that, for search depth 8, the number of moves generated for both computers are exactly the same. It should be like that, because it is a design criterion for GambitVB. So, why the difference between those numbers when going 10 moves deep? Of course, I saw more performance data than you can see here, because I keep it simple for you. I found that the 32-bits computer stopped the search, because after 380,294,447 moves, the allocated memory was exhausted. With more memory, the move count would have been 744,121,981.

More about memory in a minute, first a note about speed. The numbers for "moves per second" are more accurate calculated for search depth ten. This is caused by the rounding errors in the "used seconds" values 6 and 4. If we look at the more accurate numbers 6,556,800 and 13,287,892, then the I7 computer is twice at fast as the Core™2CPU. But does that really matter, assuming that both computers should have played exactly the same? Indeed, it does not matter for the played move in this benchmark, but it plays a role in a real game, without a fixed search depth, but with clock-control. In the same time, the I7 will examine twice as much moves and may see more opportunities.

processor	Intel(R)Core™2CPU	Intel(R) i7 CPU		Intel(R)Core™2CPU	Intel(R) i7 CPU
bits	32	64		32	64
fixed search depth	8	8		10	10
treenodes counted	1,036,130	1,036,130		11,470,814	24,376,150
mem bytes physical	2,144,563,200	8,580,550,656		2,144,563,200	8,580,550,656
mem bytes available	1,139,015,680	6,951,432,192		1,139,015,680	6,951,432,192
mem bytes allocated	392,491,004	3,044,740,600		392,491,004	3,034,735,864
mem bytes used for treenodes	35,140,616	50,638,664		392,491,000	1,186,515,352

Tree nodes are used to build (in memory) a sub tree of an enormous move tree. This is done with the hope that the stronger variations can be reused during the search process. Memory is always limited and should be of great attention by the programmer.  Above, the value "mem bytes physical" is what I bought in my computer store. The value "mem bytes available" are the bytes free for usage after GambitVB's startup. The value "mem bytes allocated" are the bytes allocated by GambitVB for its tree nodes. Actually, GambitVB claims twice as much memory. The second heap has the same size and is used for superfast maintenance of the tree nodes collection. Therefore, after allocation, there is only a minor portion of the available bytes left; GambitVB is hungry.

It is clear that GambitVB stopped the search on the 32-bits computer when there where only 4 bytes left in the allocated memory heap after 391.491.004 examined moves. The 64-bits computer had plenty of space left. Looking eight moves deep, the 64 bits computer uses much more bytes (50,638,664) than the 32 bits computer (35,140,616), while the "tree nodes counted" values are the same. Why? Well, 64-bits is a good choice if you really need much memory, such as for imaging and gaming. For most programs however, 32 bits is much more efficient. A program as GambitVB that build a big tree node collection, needs many memory address pointers. Those pointers are 32 bits long (4 bytes)  for a 32-bits computer, but 64 bits long (8 bytes) for a 64-bits computer. And while going deeper, the number of nodes grows exponentially!

Sure, GambitVB-64 sees more than GambitVB-32, but that is not enough to be invincible. It cannot look at everything and it is rarely effective to look deeper, it is just hoping to see opportunities. It is all in the game. A search depth of minimal eight is a criterion for GambitVB using the standard clock settings. GambitVB-32 is good enough for many chess players. With GambitVB v3.0, both GambitVB-32 and GambitVB-64 frequently lost their games against my chess-computer. With GambitVB v3.1 however, both frequently win against the same chess computer, although search approach or their hardware did not change; only the approach for strategy evaluation changed. Masters and grandmasters mostly do not look further than five moves deep, and that only for a selected number of moves. They know instantly where the problems are. And, they know it is all about strategy: where do you place your pieces? And when?