Thursday, May 13, 2010

Endgame pages status update

It has been long time since I posted in this blog. However, the endgame database project is still undergoing, although in a slower pace. Nevertheless, there are some breakthroughs in this period of time. Maybe this period is so long. :-)

1. First of all, I have modified the endgame code so now it can handle steps to conversion greater than 240, which was the limit before due to one byte information less some maintenance space. When I was making krn*kr* endgames, I found out some lines are greater than 240. That forced me to modify the program. I believe this part is done correctly now. Just one example here:

http://lpforth.forthfreak.net/xiangqi-js/xiangqi.htm?3BK2R195B399992n64bk3r8

Look at the steps to conversion is now 273!

2. As you may notice from above example, I have to also modify the Javascript code so it can handle steps to conversion greater than 240. Now the number for draw is 999. The old draw number 255 now stands for win in 255 steps, just like the other odd number except 999.

3. In the previous post, I mentioned the multi-thread ability of the endgame code. It worked quite well. However, the hard disk access time became even more unbearable as the other parts are now so much faster. One day, I was talking to one of my friends, who had just brought an 8-core server with 24G RAM with price at around $5,000. This prompted me to research the price of RAM. I was then surprised to find the 4G RAM can be found at the price around $130 in Taiwan. I then maxed out the RAM space of the motherboard of the 8-core server that I am using, which is 32G RAM. With RAM this big, I can now put all the database information in the RAM while computing until I finish all the computation for each endgame database. I modified the endgame code again and the speed is much faster than the hard disk version. Now I can construct endgame databases at faster pace as long as the database size is under 32G. The limitation can be further raised by simply upgrading hardware. More cores, more RAM, and sadly more money going with it. :-)

4. The progress are not all rosy here. Since my computer is now working at much higher speed with motherboard harboring 32G RAM, I am seeing some new problems. The computer now shuts down by itself from time to time. One of my friend help me trace the cause to the overheating. It is not hard to imagine now that all 8 cores are running at 100% most of the time. I changed the harboring case for better heat dissipation. It was fine for some period of time until one day, one stick of memory failed. Replaced it, ran it, and then motherboard failed. I have just replaced the motherboard and running tests now. Hopefully, this time it can start doing some work and not just whining.

5. Another setback was the breakdown of my web server machine. It had severed me for many years and finally gave away. That forced me to move the web service to another machine. I have to modify the CGI code to accommodate the bigger conversion number and much much more endgame definitions anyway. It is not all bad that it is much easier for me to modify code in the newer machine. This work took me some time and I still have some problems with the server settings. It is very slow serving file bigger than trivial size, and it cannot serve the old Java chess board. As a result, the endgame databases are only usable with the Javascript interface, but at a slower pace. Please be patient waiting for me to solve these problems. If you have ideas on why it behaves this way, please let me know. I am running Apche2 web server on an Ubuntu distribution. I also have a firewall separating web serving space and my network space.

6. Since I still have some problems to solve, I have not updated the index pages yet. It means some available endgame databases are not listed in the index pages. You can try arrange endgame position of your choice. If you are lucky, you may find your position is available in the databases. :-)

7. I learned again that this Blog space is not available to the huge Chinese population. Is the relation of Google and Chinese government that bad? I may someday move this Blog to another space so Chinese Xiangqi fans can have access to it.

8. It looks like my main web pages need some updates. :-)

These are for now. Stay tuned....

7 comments:

tobywhcheng said...

No wonder the endgame database is not usable some days ago~ truly thanks for your effort~!

I found 車對馬雙士 and 車對馬雙象's endgame has some problem about 長將. 黑方通過叫將運馬至有利防守位置,最佳著法中,紅方避免被黑長將而被利用,大大增加了取勝難度

例如在以下盤面,紅方可走帥五退一,而非建議的帥五進一,黑方只能改走馬6退7

http://lpforth.forthfreak.net/cgi-bin/endgame.cgi?3K2E294E4998r5N394k49

Pai said...

Very deep understanding of the endgames. In building the endgame databases, I can only find a practical solution. When indefinite checking/chasing is involved, you definitely can find some shortcomings of this implementation. However, I have not learned a better solution yet. I can only say it is a practical solution for computer chess.

tobywhcheng said...

如果因為這個shortcoming而使某些局面的取勝步數超過100著自然限著,也算是一個practical的問題吧?

我聽說過雙炮雙相可以例勝士象全,而殘局庫裡未有這個形勢提供

另外,又聞說過馬兵專集和炮卒專集的作者陳廉庸先生曾研究出,炮兵無士象對單士象,兵在騎河一線的話為例勝,但進至對方卒林或以下就只有巧勝.在現有殘局庫的基礎之上,應該不難把高兵裡的卒林兵區分出來驗證一下

Pai said...

Some problems I can solve. Some problems not, at least for now.
I did separate high pawn and low pawn in statistic page of pawn endgame. However, it is not refine enough. To have your request, codes need to be written. Someday, when I have impulse and time.

Pai said...

kcceekbbee is now available.

Pai said...

雙炮雙相對士象全 is available.

tobywhcheng said...

Thanks