allowing more memory for transposition table always better?

[cyberfish]

For x86 compilers, look up _mm_prefetch with Google.

or __builtin_prefetch on gcc.

[hgm]

The fluctuations are so big that I am reluctant to draw any conclusion. However, it seems like the best size is somewhere around 128-256MB for my engine.

Yes, in alpha-beta search the fluctuations are terrible. Most of it is 'noise', not really related to the size of the table per se, but to the different mapping of key positions into the table that a change in size gives you as a side effect. You would already have similar fluctuations if you would keep the table size the same, and change your Zobrist random keys. (So perhaps it would be an idea to reduce this noise by averaging over many different choices for the Zobrist keys.)

For this reason I always use perft, rather than a search, to evaluate performance of hashing (e.g. replacement algorithms).

As your search time is ~30 sec, and I can hardly imagine that you search much faster than 1 Mnps, it seems that all table sizes above 32MB should be basically equivalent, as they can all hold the entire search tree. Especially if your replacement algorithm is smart enough to solve most collisions between important positions in a not-too-clumsy way.

Prefetch is tricky in search, as it might backfire through fetching positions that later turn out to be beta-pruned. And memory bandwidth is as important as access time, if you also hash QS nodes. So you should do it only (for hash probes) when you are pretty certain that you are in an alpha node, and will need to search all moves that you are prefetching. I tried this in perft, and could achieve some gain there (but not spectacular, as it seemed mainly a bandwidth problem).

[FrancoisK]

I tried this some time ago, unsucessfully.
I tried the various flavours of prefetch at various distances (from as far as fossible to really close) from the actual table lookup, and was not able to measure any noticeable gain on my AMD. Moreover, any gain is very likely to be very hardware dependant.
I still want to try and speed up my evaluation hash table this way.

François

[cyberfish]

(So perhaps it would be an idea to reduce this noise by averaging over many different choices for the Zobrist keys.)

sounds like a good idea... except I don't have an automatic way of doing this... and several hours of mouse-clicking don't sound too inviting... =)