Problem: bitbase access by Scorpio versions... Dan Shawul?

[ernest]

But with option 3 that loads all five men, it took almost 4 minutes to initialize as shown below, and the task manager says 446mb used, so it does load the egbbs along with indexing tables. But if you wait a couple of seconds when scorpio is not analyzing any endgame position the usage goes down. That is ok.

Code: Select all

feature done=0
ht 1048576 X 64 = 64MB
eht 524288 X 16 = 8MB
pht 349525 X 24 = 7MB
EgbbProbe 3.3 by Daniel Shawul
Egbbs loaded !
loading_time = 234s

Hi Daniel,

After I corrected my stupid # mistake
#egbb_load_type 3
(thanks to Guenther!)
I do indeed see the loading of the 5-men egbb in memory (takes 2 min. here, why so long?...)

But how do you get your log?

feature done=0
ht 1048576 X 64 = 64MB
eht 524288 X 16 = 8MB
pht 349525 X 24 = 7MB
EgbbProbe 3.3 by Daniel Shawul
Egbbs loaded !
loading_time = 234s

I don't get
EgbbProbe 3.3 by Daniel Shawul
Egbbs loaded !

Here is my log:

Code: Select all

ht 8388608 X 64 = 512MB
eht 4194304 X 16 = 64MB
pht 699050 X 24 = 15MB
+ Thread 1 started.
processors [2]
loading_time = 116s
<COMMAND LINE>
==============================
<000000116765>xboard
<000000116765>protover 2
feature name=1 myname="Scorpio_2.7 JA"
feature sigint=0 sigterm=0
feature setboard=1 draw=0 colors=0
feature smp=0 memory=0 egt="scorpio"
feature option="log -check 0"
feature option="clear_hash -button"
feature option="resign -spin 800 100 30000"
feature option="smp_depth -spin 4 1 10"
feature option="cluster_depth -spin 1 8 16"
feature option="message_poll_nodes -spin 200 10 20000"
feature option="use_iid -check 1"
feature option="use_singular -check 0"
feature option="singular_margin -spin 30 0 1000"
feature option="futility_margin -spin 125 0 1000"
feature done=1
<000000116765>accepted done
<000000116765>accepted name
<000000116765>accepted myname
<000000116765>accepted sigint
<000000116765>accepted sigterm
<000000116765>accepted setboard
<000000116765>accepted draw
<000000116765>accepted colors
<000000116765>rejected smp
<000000116765>rejected memory
<000000116765>rejected egt
<000000116765>rejected option
<000000116765>rejected option
<000000116765>rejected option
<000000116765>rejected option
<000000116765>rejected option
<000000116765>rejected option
<000000116765>rejected option
<000000116765>rejected option
<000000116765>rejected option
<000000116765>rejected option
<000000116765>accepted done
<000000116781>new
<000000117015>random
<000000117015>level 0 5 0
<000000117015>post
<000000117015>hard
<000000120922>force
<000000120922>new
<000000121172>random
<000000121172>level 0 5 0
<000000121172>post
<000000121172>hard
<000000121172>force
<000000121172>setboard 8/8/8/7p/5kq1/P6Q/8/1K1N4 w - - 0 1
<000000135750>analyze
[0] 2 4916 3 214  Qh3xg4 h5xg4
[0] 2 4916 3 296  Qh3xg4 h5xg4
[0] 3 4916 3 305  Qh3xg4 h5xg4
[0] 3 4916 3 549  Qh3xg4 h5xg4
[0] 4 4916 3 558  Qh3xg4 h5xg4
[0] 4 4916 3 996  Qh3xg4 h5xg4
[0] 5 4916 3 1005  Qh3xg4 h5xg4
[0] 5 4916 3 1612  Qh3xg4 h5xg4
[0] 6 4916 3 1621  Qh3xg4 h5xg4
[0] 6 4916 3 2437  Qh3xg4 h5xg4
[0] 7 4916 3 2446  Qh3xg4 h5xg4
[0] 7 4916 3 3785  Qh3xg4 h5xg4
[0] 8 4916 3 3794  Qh3xg4 h5xg4
[0] 8 4916 3 5325  Qh3xg4 h5xg4
[0] 9 4916 3 5334  Qh3xg4 h5xg4
[0] 9 4916 3 8034  Qh3xg4 h5xg4
[0] 10 4916 3 8043  Qh3xg4 h5xg4
[0] 10 4916 4 12966  Qh3xg4 h5xg4
[0] 11 4916 4 12975  Qh3xg4 h5xg4
[0] 11 4916 6 19940  Qh3xg4 h5xg4
[0] 12 4916 6 19949  Qh3xg4 h5xg4
[0] 12 4916 7 33358  Qh3xg4 h5xg4
[0] 13 4916 7 33367  Qh3xg4 h5xg4
[0] 13 4916 7 50820  Qh3xg4 h5xg4
[0] 14 4916 7 50829  Qh3xg4 h5xg4
[0] 14 4916 10 88557  Qh3xg4 h5xg4
[0] 15 4916 10 88566  Qh3xg4 h5xg4
[0] 15 4916 15 150783  Qh3xg4 h5xg4
[0] 16 4916 15 150792  Qh3xg4 h5xg4
[0] 16 4916 20 230528  Qh3xg4 h5xg4
[0] 17 4916 20 230537  Qh3xg4 h5xg4
[0] 17 4916 26 342210  Qh3xg4 h5xg4
[0] 18 4916 26 342219  Qh3xg4 h5xg4
[0] 18 4916 39 548147  Qh3xg4 h5xg4
[0] 19 4916 39 548156  Qh3xg4 h5xg4
[0] 19 4916 57 839705  Qh3xg4 h5xg4
[0] 20 4916 57 839714  Qh3xg4 h5xg4
[0] 20 4916 90 1345645  Qh3xg4 h5xg4
[0] 21 4916 90 1345654  Qh3xg4 h5xg4
[0] 21 4916 134 1972180  Qh3xg4 h5xg4
[0] 22 4916 134 1972189  Qh3xg4 h5xg4
[0] 22 4916 203 2932563  Qh3xg4 h5xg4
[0] 23 4916 203 2932572  Qh3xg4 h5xg4
[0] 23 4916 293 4246516  Qh3xg4 h5xg4
[0] 24 4916 293 4246525  Qh3xg4 h5xg4
[0] 24 4916 423 6075539  Qh3xg4 h5xg4
[0] 25 4916 423 6075548  Qh3xg4 h5xg4
[0] 25 4916 589 8476299  Qh3xg4 h5xg4
[0] 26 4916 589 8476308  Qh3xg4 h5xg4
[0] 26 4916 859 12289253  Qh3xg4 h5xg4
[0] 27 4916 859 12289262  Qh3xg4 h5xg4
[0] 27 4916 1187 16862742  Qh3xg4 h5xg4
[0] 28 4916 1187 16862751  Qh3xg4 h5xg4
[0] 28 4916 1756 24722971  Qh3xg4 h5xg4
[0] 29 4916 1756 24722980  Qh3xg4 h5xg4
[0] 29 4916 2400 33217812  Qh3xg4 h5xg4
[0] 30 4916 2400 33217821  Qh3xg4 h5xg4
[0] 30 4916 3353 45627085  Qh3xg4 h5xg4
[0] 31 4916 3353 45627094  Qh3xg4 h5xg4
[0] 31 4916 4706 63053918  Qh3xg4 h5xg4
[0] 32 4916 4706 63053927  Qh3xg4 h5xg4
[0] 32 4916 6554 86186222  Qh3xg4 h5xg4
[0] 33 4916 6554 86186231  Qh3xg4 h5xg4
<000000212875>exit
nodes = 99992747 <39 qnodes> time = 77140ms nps = 1296250
lazy_eval = 93 splits = 11956 badsplits = 219 egbb_probes = 8760829
<000000212890>quit
Bye Bye

[Daniel Shawul]

Dear god Earnest! I am kidding , it happens to everybody once in a while. I used the console mode to produce my output so that is why you see that message. The dll is an external library and it can not directly write Egbb loaded message to a log file of scorpio (maybe it can but I don't know yet).
cheers
Daniel

[ernest]

Dear god Earnest! I am kidding , it happens to everybody once in a while. I used the console mode to produce my output so that is why you see that message.

OK, good joke!

BTW, my question about "loading of the 5-men egbb in memory (takes 2 min. here, why so long?...)":
when using the "old" bitbases which are much less compressed (361 MB) than the "new" ones (Dann Corbit, 223 MB), the loading of the 5-men egbb in memory of course takes much less time...

[Daniel Shawul]

Dear God (no "joke") I thought your question was why you don't see the egbb loaded message and I did ? Well that is answered. If you put your questions in one page, and not use bold letters, and not put my name on your title , I may be more inclined to answer all your questions...
If you say the 361mb takes more time to load than 223mb,then I don't know the reason. Neither the 4 or 5 men bitbases get decompressed when loaded in RAM, so I don't see any reason why the smaller should take longer. Sure you didn't put a "#" this time (a joke).

[ernest]

If you say the 361mb takes more time to load than 223mb,then I don't know the reason. Neither the 4 or 5 men bitbases get decompressed when loaded in RAM,

Nono! I say the opposite:
the 361 MB take less than half the time to load, than the 223 MB.

I am surprised when you say
neither the 4 or 5 men bitbases get decompressed when loaded in RAM
since after loading the 223 MB, the memory used by Scorpio increased by approx. 350 MB (as seen by the TaskManager)

P.S. see, no bold this time...

[Daniel Shawul]

If you say the 361mb takes more time to load than 223mb,then I don't know the reason. Neither the 4 or 5 men bitbases get decompressed when loaded in RAM,

Nono! I say the opposite:
the 361 MB take less than half the time to load, than the 223 MB.

Sure that is what I meant. I read your ridiclous claim and my cerebral coordination obviously couldn't allow me to write it out as you said it..
it can't be like I explained because nothing gets decompressed. If the case was about the kind of compressor used that may have made sense but it doesn't. More compression takes more decompression time as well. That is what I am trying to tell you.

I am surprised when you say
neither the 4 or 5 men bitbases get decompressed when loaded in RAM
since after loading the 223 MB, the memory used by Scorpio increased by approx. 350 MB (as seen by the TaskManager)

Again it doesn't get decompressed if it did it would have been a lot lot more. Why you are interested in this as a regular user is beyond me ?
You are just wasting my time and yours too.

P.S. see, no bold this time...

Good.

[ernest]

Again it doesn't get decompressed if it did it would have been a lot lot more. Why you are interested in this as a regular user is beyond me ?

Well maybe I am just not a regular user... (but trying to understand concepts)
Actually, since 5-men tablebases are readily available, it is 6-men bitbases that would really be a breakthrough (SMK has them, but probably thinks he cannot sell them well enough).

Last, concerning our little misunderstanding concerning the messages
EgbbProbe 3.3 by Daniel Shawul
Egbbs loaded !

...I finally got them, not in the scorpio logs, where I initially looked, but in Wb2Uci.log
Here we are, for the old egbb (361 MB) and the new egbb (223 MB).
Really wonder about the difference in loading_time!

Code: Select all

Wb2Uci.log
egbbold
1.281: S> EgbbProbe 3.1 by Daniel Shawul
1.281: S> Cache Size = 16 Mb (2070 entries)
30.609: S> Loading egbbs....Egbbs loaded !
30.609: S> loading_time = 29s
30.641: S> feature name=1 myname="Scorpio_2.7 JA"

egbb
1.141: S> EgbbProbe 3.3 by Daniel Shawul
61.062: C< readyok
120.156: S> Loading egbbs....Egbbs loaded !
120.156: S> loading_time = 119s
120.266: S> feature name=1 myname="Scorpio_2.7 JA" 

P.S. God! Do you really consider boldface for a few words as netiquette?