Evaluation as a composite

[cdani]

Fizbo seems to deliberately...

Maybe is just tuning against other engines, and Fizbo being the only of the top engines doing mostly this. Just my imagination, no idea if is like this.

[Henk]

Factory method creating an evaluator is easier to use than evaluator state. Disadvantage is that each time a new evaluator object is created. To repair that you can select one that had been created in advance. But that one may be outdated.

Currently I assume C#.NET has an excellent garbage collector.

[Ras]

Currently I assume C#.NET has an excellent garbage collector.

Shouldn't matter because the only stuff that needs to be allocated on the heap are pseudo-static items like hash tables.

If you are allocating/deallocating stuff during search, the performance will be abysmal no matter what.

[Henk]

Currently I assume C#.NET has an excellent garbage collector.

Shouldn't matter because the only stuff that needs to be allocated on the heap are pseudo-static items like hash tables.

If you are allocating/deallocating stuff during search, the performance will be abysmal no matter what.

I remember a Skipper version doing no extra allocations during search but I did not notice any difference in performance. Might be hash table was already bottleneck or something else.

I don't care at this moment about performance. Some days like today you have no extra time and want keep it simpel. For now I think three times before doing any optimizations. Somehow I don't like writing/updating documentation. So simplicity must rule.

[AlvaroBegue]

Currently I assume C#.NET has an excellent garbage collector.

Shouldn't matter because the only stuff that needs to be allocated on the heap are pseudo-static items like hash tables.

If you are allocating/deallocating stuff during search, the performance will be abysmal no matter what.

I remember a Skipper version doing no extra allocations during search but I did not notice any difference in performance. Might be hash table was already bottleneck or something else.

I don't care at this moment about performance. Some days like today you have no extra time and want keep it simpel. For now I think three times before doing any optimizations. Somehow I don't like writing/updating documentation. So simplicity must rule.

There is nothing simple about allocating memory. I programmed for about 7 years before I ever used dynamic memory allocation (it wasn't even available in the environment I was using before that), and I still view it with suspicion. Allocating memory is a calling function from some library that manages a big chunk of memory. It's hard to understand exactly how this function does its job and what the resulting performance will be. Many languages incorporate dynamic memory allocation in ways that make its use very natural, but some high-level stuff is going on whenever you use it. Newer programmers are often unaware of how big an operation this is.

During the search in a chess engine there is nearly no reasonable use of dynamic memory allocation, even if you don't care about performance. I can see perhaps using a vector to store a move list, but a fixed-length array does the job just fine.

[CheckersGuy]

The way it was used in Giraffe will, IMO, not be competetive because the neuro net was used in the wrong place. Neuro nets produce similar outputs for similar inputs, i.e. they are useful for pattern matching. But in chess, just one piece one square away can decide the whole game. Unlike Go, chess isn't suited for this approach.

Actually, per the Giraffe paper, the neural net used was specifically designed to address the "one square away" issue. Moreover, Giraffe's eval is quite good. The problem was that it is currently too slow to run the net. See the Texel tests with the Giraffe eval posts.

Those small patches won't get us to a breakthrough but if the small 1 elo-patches are actually 1 elo at LTC, engines will continously get stronger. There is nothing wrong with 1-elo patches just with measuring that they are actual 1 elo-patches. One does not need a breakthrough if we can make small incremental improvements like that

[Henk]

Currently I assume C#.NET has an excellent garbage collector.

Shouldn't matter because the only stuff that needs to be allocated on the heap are pseudo-static items like hash tables.

If you are allocating/deallocating stuff during search, the performance will be abysmal no matter what.

I remember a Skipper version doing no extra allocations during search but I did not notice any difference in performance. Might be hash table was already bottleneck or something else.

I don't care at this moment about performance. Some days like today you have no extra time and want keep it simpel. For now I think three times before doing any optimizations. Somehow I don't like writing/updating documentation. So simplicity must rule.

There is nothing simple about allocating memory. I programmed for about 7 years before I ever used dynamic memory allocation (it wasn't even available in the environment I was using before that), and I still view it with suspicion. Allocating memory is a calling function from some library that manages a big chunk of memory. It's hard to understand exactly how this function does its job and what the resulting performance will be. Many languages incorporate dynamic memory allocation in ways that make its use very natural, but some high-level stuff is going on whenever you use it. Newer programmers are often unaware of how big an operation this is.

During the search in a chess engine there is nearly no reasonable use of dynamic memory allocation, even if you don't care about performance. I can see perhaps using a vector to store a move list, but a fixed-length array does the job just fine.

No not simpel but flexibel. With flexibility one must be careful.