my private rating list: GPL Blitz

[Pablo Vazquez]

Very interesting list, I'm also an open source fan, whatever the strength of the engine.

Glad to see that some people still understand the spirit of free software nowadays

I would love to test the new Sungorus derivative, if I can get a 64-bit Linux compile. Is the code likely to be portable ? Or is it going to be MSVC//Windows only ?

Hi Lucas,

I managed to compile it with g++ -O3 *.c */*.c -Dinline=. Without the last option, the compiler complains about inlined functions. I don't know if there is a big speed penalty for disabling inlining.

The node counts are the same as Pawel's exe so everything looks ok.

[lucasart]

Very interesting list, I'm also an open source fan, whatever the strength of the engine.

Glad to see that some people still understand the spirit of free software nowadays

I would love to test the new Sungorus derivative, if I can get a 64-bit Linux compile. Is the code likely to be portable ? Or is it going to be MSVC//Windows only ?

Hi Lucas,

I managed to compile it with g++ -O3 *.c */*.c -Dinline=. Without the last option, the compiler complains about inlined functions. I don't know if there is a big speed penalty for disabling inlining.

The node counts are the same as Pawel's exe so everything looks ok.

Thank you. I managed to compile it this way.

But for code portability it's important to comform to the ISO C++ standard, and these "extern inline" are not incorrect. It must be an extension of Microsoft, and a really bad one, as it gives bad habits to programmers...

So I compiled as follows:

Code: Select all

lucas@megatron:~/Downloads/rodent_0.08$ g++ -O3 -flto *.c */*.c -o ./rodent008

I don't think inlining is really usefull, as GCC 4.6 has a *very* powerful compiling optimizer (-O3) and link time optmizer (-flto).

Anyway, it works fine and I'm starting the test now! Results will be available tomorrow !

[PK]

I can scrap inlining, it has been only a minor speed gain. Is it the only thing that gcc compiler dislikes? Anyhow, I will try to compile next version with it, but expect it in two months or so.

[Michel]

I can scrap inlining,

The standard design pattern in C is to define (and not just prototype) inlined functions which are used in more than one file in a header file.

Of course with link time optimization it might be no longer necessary to do this.

[Pablo Vazquez]

I can scrap inlining, it has been only a minor speed gain. Is it the only thing that gcc compiler dislikes? Anyhow, I will try to compile next version with it, but expect it in two months or so.

I used g++ 4.6.1. It's the only thing that it complained about. When I get home I'll post the exact message. As Michel said, it was about having to define the inlined function in the header itself.

[lucasart]

I can scrap inlining, it has been only a minor speed gain. Is it the only thing that gcc compiler dislikes? Anyhow, I will try to compile next version with it, but expect it in two months or so.

I used g++ 4.6.1. It's the only thing that it complained about. When I get home I'll post the exact message. As Michel said, it was about having to define the inlined function in the header itself.

If compiler and linker optimizations (-O3 and -flto) prove inlining to be useless, then you can remove then Unfortunately there's no general rule that says if inlining is useless of useful, the only way is to test! But generally, even if it's useful it's so negligible... One could argue that it makes sense to specify the "inline" keyword anyway, as other compilers than GCC may not have such powerful optimizations. Anyway, modern compilers don't understand the word "inline" as an order anymore, but rather as a hint.

But yes, the only correct way to inline these functions is to define the body of the function in the header file. I can't understand how MSVC manages to compile such an abomination as "extern inline". Compiling units (ie. each cpp file) are compiled independantly, and linked together afterwards. So an extern inline is like asking the compiler to inline something that is not even defined in the compiling unit. MSVC probably doesn't care about your extern inline and considers them as an extern, and (perhaps?) writes a note for the linker optimizer somewhere when it compiles.

I've found 3 little bugs worth fixing:
- "Hash Size" should be called "Hash" to comply with the UCI protocol (no GUI should understand that the option "Hash Size" corresponds to anything in particular)
- Rodent doesn't seem to know how to mate a lone king with a rook, at least at fast time control. It's the most trivial code fix in the world: just make sure your king piece on square table for endgames will incentivisde king in the center. that way the stronger side will push the lone king into a corner or an edge, and the search will easily find the forceful mate.
- there was a third one, but it seems to have slipped off my mind... Anyway, I'll remember it again at some point

Otherwise great work, it's showing a big improvement (+230 elo on my list) compared to Sungorus 1.4

[Pablo Vazquez]

I can scrap inlining, it has been only a minor speed gain. Is it the only thing that gcc compiler dislikes? Anyhow, I will try to compile next version with it, but expect it in two months or so.

I used g++ 4.6.1. It's the only thing that it complained about. When I get home I'll post the exact message. As Michel said, it was about having to define the inlined function in the header itself.

If compiler and linker optimizations (-O3 and -flto) prove inlining to be useless, then you can remove then Unfortunately there's no general rule that says if inlining is useless of useful, the only way is to test! But generally, even if it's useful it's so negligible... One could argue that it makes sense to specify the "inline" keyword anyway, as other compilers than GCC may not have such powerful optimizations. Anyway, modern compilers don't understand the word "inline" as an order anymore, but rather as a hint.

But yes, the only correct way to inline these functions is to define the body of the function in the header file. I can't understand how MSVC manages to compile such an abomination as "extern inline". Compiling units (ie. each cpp file) are compiled independantly, and linked together afterwards. So an extern inline is like asking the compiler to inline something that is not even defined in the compiling unit. MSVC probably doesn't care about your extern inline and considers them as an extern, and (perhaps?) writes a note for the linker optimizer somewhere when it compiles.

I've found 3 little bugs worth fixing:
- "Hash Size" should be called "Hash" to comply with the UCI protocol (no GUI should understand that the option "Hash Size" corresponds to anything in particular)
- Rodent doesn't seem to know how to mate a lone king with a rook, at least at fast time control. It's the most trivial code fix in the world: just make sure your king piece on square table for endgames will incentivisde king in the center. that way the stronger side will push the lone king into a corner or an edge, and the search will easily find the forceful mate.
- there was a third one, but it seems to have slipped off my mind... Anyway, I'll remember it again at some point

Otherwise great work, it's showing a big improvement (+230 elo on my list) compared to Sungorus 1.4

I try to touch MS products as little as possible. g++ compiles with a warning and then the linker fails. Here are the messages:

Code: Select all

bitboard/bitboard.h:55:19: warning: inline function ‘U64 ShiftNorth(U64)’ used but never defined [enabled by default]

init.c:(.text+0x455): undefined reference to `ShiftNorth(unsigned long long)'

[lucasart]

I try to touch MS products as little as possible.

+1

for a start it is not ANSI/ISO C++ compliant and teaches programmers very bad things (the very idea of wanting to write "extern inline" in the code denotes a complete lack of understanding of what compiling and liking mean, which you typically understand when you do manually writing your gcc ,akefiles)

[PK]

most of the fixes are done, but I'll wait with the release for some more substantial changes. after all Rodent is not yet at the stage where any Elo gain requires a hard-fought battle.

Lucas, did the engine actually fail to checkmate with KR vs K, or was it just unusually long process?

Anyhow, bits and pieces of endgame knowledge are on my todo list before the release.

[Evert]

- Rodent doesn't seem to know how to mate a lone king with a rook, at least at fast time control. It's the most trivial code fix in the world: just make sure your king piece on square table for endgames will incentivisde king in the center. that way the stronger side will push the lone king into a corner or an edge, and the search will easily find the forceful mate.

Sounds like a null-move problem to me.
For the record, I've seen a similar problem with gk-0.90.