bright 0.4a now public

[Jouni]

Allard,

Your i-perft gave perft(8) = 84 998 980 861. but i found different numbers in net. What's "correct" value actually?

Jouni

[Allard Siemelink]

Hi Allard!
Does Bright have an option to load all the egbbs into ram?

regards,
Daniel

Hi Daniel,

The warning "egbb dll not found" is printed if the call to LoadLibrary(dllpath) fails.
If LoadLibrary succeeds then load_egbb_5men is called with the following arguments:
- load the bitbases upto 4 pieces into ram.
- use 16Mb (or more if specified in INI-file) for the 5 piece bitbases cache

[Allard Siemelink]

Allard,

Your i-perft gave perft(8) = 84 998 980 861. but i found different numbers in net. What's "correct" value actually?

Jouni

Hm, I get the same number, it's probably an i-perft bug

[sje]

Code: Select all

Na3 3,193,522,577
Nc3 3,926,684,340
Nf3 3,937,354,096
Nh3 3,221,278,282
a3 2,863,411,653
a4 3,676,309,619
b3 3,579,299,617
b4 3,569,067,629
c3 3,806,229,124
c4 4,199,667,616
d3 6,093,248,619
d4 7,184,581,950
e3 8,039,390,919
e4 8,102,108,221
f3 2,728,615,868
f4 3,199,039,406
g3 3,641,432,923
g4 3,466,204,702
h3 2,860,408,680
h4 3,711,123,115

Depth: 8   Count: 84,998,978,956

[Matthias Gemuh]

Allard,

Your i-perft gave perft(8) = 84 998 980 861. but i found different numbers in net. What's "correct" value actually?

Jouni

Hm, I get the same number, it's probably an i-perft bug

Some perft numbers out there are cummulative, p(2)=420
Some are not, p(2)=400 (excluding p(1)=20)

Correction: I now see that even this does not explain Bright's numbers.

Matthias.

[Daniel Shawul]

I belive that it is the "renaming" issue then. I have now got many approvals from people that both the 64bit/32bit egbbdlls do infact work. Possible problems for users are
a) Not renaming the egbbdlls
b) Using the new egbbdlls for the old ones

Daniel

[Matthias Gemuh]

I belive that it is the "renaming" issue then. I have now got many approvals from people that both the 64bit/32bit egbbdlls do infact work. Possible problems for users are
a) Not renaming the egbbdlls
b) Using the new egbbdlls for the old ones

Daniel

Why are there no distinctions new/old 32bit/64bit in the naming of the egbbdlls ?
Then one could throw all into one folder and engines would always pick the right egbbdll by name.
The other advantage would be that the GUI could send that one folder path to engines at runtime, as was discussed in WB forum.

Matthias.

[Daniel Shawul]

I did not think of that during the first release. My first thought was
that one should compile for the relevant platform and then rename it
to egbbdll.dll. I missed the fact that 32bit and 64bit engines could
run on 64bit machines togehter, which necessitates use of different dlls
for probing.

BTW I do not know of the discussion in winboard forum about this.

If all users agree, then we can change it to a common egbb names like "egbbdll32" and
"egbbdll64" with the appropriate extension. Even that may not be requried if the os
can load it without complaining about the extension.

DAniel

[Matthias Gemuh]

I did not think of that during the first release. My first thought was
that one should compile for the relevant platform and then rename it
to egbbdll.dll. I missed the fact that 32bit and 64bit engines could
run on 64bit machines togehter, which necessitates use of different dlls
for probing.

BTW I do not know of the discussion in winboard forum about this.

If all users agree, then we can change it to a common egbb names like "egbbdll32" and
"egbbdll64" with the appropriate extension. Even that may not be requried if the os
can load it without complaining about the extension.

DAniel

Code: Select all

BTW I do not know of the discussion in winboard forum about this.

Among other pages : http://www.open-aurec.com/wbforum/viewt ... io#p186489

[Allard Siemelink]

Allard,

Your i-perft gave perft(8) = 84 998 980 861. but i found different numbers in net. What's "correct" value actually?

Jouni

Hm, I get the same number, it's probably an i-perft bug

Found the bug: when capturing en passant, diagonal
discovered checks were ignored for the captured pawn.
Now that this is fixed, I get the same numbers as posted by Steven.
I will put the new version on my homepage later this week.