UnEvI: separating eval from search?

[Aleks Peshkov]

In my opinion programmers should share source code, not non-portable binary artifacts.

[Andres Valverde]

As I understood the idea was to pass a pointer to the board data structure, owned by the search, to the evaluation function - so not much different to what is currently done in most engines.

Sven

This is the way that Dirty worked (the DLL schema has been abandoned in last version). A copy of Buzz data structure along with other data needed for eval function were passed.

We did it in that way because I wrote the eval DLL in Pascal and the core of the program (Buzz) was in C ( dirty eh? ). There were not any other reasons

Experience :

- There is not a significant speed penalty (despiting that eval in pascal was 30% slower) calling the DLL eval function . We have tried Dirty+material DLL and Dirty only material in C and speed is practically the same even with the Pascal DLL.

- It is possible to compile the equivalent to a DLL for Linux (as Scorpio bitbases do)

- We tried to use the same DLL with several programs (they have to translate their data structures to Buzz one on the fly) and , although it did work, they play way worse. IIRC we experimented (as a curiosity) with Firefly, Danasah and Frenzee: bad results in all of them. The eval was tuned for Dirty and simply it worked badly with the other programs.

- We have migrated to C because there is no good (fast) Pascal compiler for 64 bit and to make things less complicated for going SMP.

Hope this answer Onno question

[Mincho Georgiev]

The first thing, comes in mind is that using the DLL model, you are going to dismiss some useful inter-procedural optimizations, generated by the compiler. Plus the evaluation function will be mapped in the DLL space (0x01000000) separately witch will lead to a tiny slow-down. You have to test that before draw any conclusions though.

[Onno Garms]

We did it in that way because I wrote the eval DLL in Pascal and the core of the program (Buzz) was in C ( dirty eh? ).

I don't think that combining different languages in a project is dirty. Pascal may have been a bad choice (as you found out now), but that is another question.

- There is not a significant speed penalty (despiting that eval in pascal was 30% slower) calling the DLL eval function . We have tried Dirty+material DLL and Dirty only material in C and speed is practically the same even with the Pascal DLL.

ACK. A significant speed penalty would have surprised me if a pointer to the board structure (owned by the search) is passed.

- It is possible to compile the equivalent to a DLL for Linux (as Scorpio bitbases do)

Thank you and the others for that information and the information that it can be loaded at runtime (which was the question I personally was uncertain about, simply because unlike in Windows, there was no reason for me to study loading mechanisms under Linux up to now.)

- We tried to use the same DLL with several programs (they have to translate their data structures to Buzz one on the fly) and , although it did work, they play way worse. IIRC we experimented (as a curiosity) with Firefly, Danasah and Frenzee: bad results in all of them. The eval was tuned for Dirty and simply it worked badly with the other programs.

This experiment might in deed settle the original thing because it makes separation pointless. Do you remember how much speed penalty there was for the data structure conversion? (I assume you did conversion at runtime rather than intensive modifications at implementation time) When measuring the performance of the other engines with your eval, did you compensate for the speed penalty?

[Onno Garms]

In my opinion programmers should share source code, not non-portable binary artifacts.

Even sharing code would not make it possible to plug an eval and a search by different authors together unless they agree on a common binary board representation (or at speed penalties on a common interface - not a good idea IMHO).

Even with a common binary board representation but without dynamically loaded libraries the combination of search and eval would have to be done at compile time. Not every engine user is familiar with a compiler, so I consider "binary artifacts" a good idea.

But anyway, Andreas said he already tried to combine different engines with the same eval and the engines payed poorly. This was not what I expected (but considered possible). If it is like that, forget about the idea.

[kbhearn]

Except they still need to agree on a common binary board representation for argument passing with the DLL setup (or suffer an even more significant speed penalty than using an interface class as the format would need to be converted). So it's no simpler than having a published source for a search with multiple forks for different evals.