Winboard Forum

The program compiles without problems but unfortunately it crashes immediately when it is out of book. The only error message is something like "memory access error" (translated from German).

An executable compiled for an Athlon-XP does works correctly even on the other processor, but it does not quit correctly (one process occupies one cpu and has to be killed to stop).

As far as I know gcc 4.1.1 goes not support Core 2 Duos officially yet. I compiled Crafty, Glaurung, Arasan, Toga-Fruit and Needle succesfully and the programs also run as expected. Does someone have an idea what do do (except waiting for updates)?

Volker

Volker Pittlik wrote:As far as I know gcc 4.1.1 goes not support Core 2 Duos officially yet.

It doesn't? That's strange, because the older gcc 4.0.1 does...

I compiled Crafty, Glaurung, Arasan, Toga-Fruit and Needle succesfully and the programs also run as expected. Does someone have an idea what do do (except waiting for updates)?

Install an older version of GCC in addition to 4.1.1, perhaps? You can use 4.1.1 when it works, and revert to the older version when it doesn't. It is unproblematic to have several GCC versions installed, I think.

Tord

Tord Romstad wrote:...
Install an older version of GCC in addition to 4.1.1, perhaps? You can use 4.1.1 when it works, and revert to the older version when it doesn't. It is unproblematic to have several GCC versions installed, I think.

I didn't notice any problems when I had. However, there are some more (even more annoying issues). I'll use the old executable of Scorpio until I find a better solution.

I don't claim to be right about the official support of Core 2 Duo. I read it some days ago in a Linux forum somewhere. I didn't check it.

Volker

Hi Volker,

I heard that the Linux Kernel may still have problems with certain chipsets on a Core 2 Duo, did you check this?

Which Linux version are you using?

When Scorpio crashes, do you get a core dump, and if yes, did you have a look into the stacktrace with gdb?

GCC "not supporting" Core 2 Duo may mean either that some code will not run on it, or that the code will run but GCC is not yet able to optimize the code for this platform. In general I would expect the latter.

I doubt that GCC 4.0.1 has already had explicit support for it because according to Wikipedia most Core 2 Duo processors appeared end of July 2006 which is one year after the release of GCC 4.0.1.

Sven

Sven Schüle wrote:...
I heard that the Linux Kernel may still have problems with certain chipsets on a Core 2 Duo, did you check this?...

No.

Sven Schüle wrote:...Which Linux version are you using?...

2.6.18-1.2849.fc6 #1 SMP. Fedora Core 6 with small changes to support the nvidia graphic stuff (Livna).

Sven Schüle wrote:...When Scorpio crashes, do you get a core dump, and if yes, did you have a look into the stacktrace with gdb?...

No as I wrote the only output is "Speicherzugriffsfehler" (most likely not by Scorpio itself) and it terminates.

Sven Schüle wrote:...GCC "not supporting" Core 2 Duo may mean either that some code will not run on it, or that the code will run but GCC is not yet able to optimize the code for this platform. In general I would expect the latter....

Me too, gcc -dumpmachine tells me "x86_64-redhat-linux" therefore I suppose has done something to support this processor. I can include the "inline64.h" stuff when I compile Crafty and everything works as expected. However, I didn't find something like "-march=core2duo" in the documentation. In some Linux forums people suggested tp use pentium-m or -nocona. IIRC I tested nocona but there was no change in program's speed.

Sven Schüle wrote:...I doubt that GCC 4.0.1 has already had explicit support for it because according to Wikipedia most Core 2 Duo processors appeared end of July 2006 which is one year after the release of GCC 4.0.1....

At the moment the this is not to important for me. I can live with the 32-bit version of Scorpio. At the moment I limit myself to a few engines only (open source preferred). I have some strong ones for analyses and tests and some weaker to play against myself.

Regards

Volker

FC 6 supports core duo and core 2 duo with no problems. As does gcc. I have such a processor, and am running suse 10.1 (FC 6 would not install correctly with my video card (dell laptop) although it ran crafty just fine in non-X mode...

This was X86_64 versions of both and they both ran find. Suse has a timing glitch but it runs flawlessly except for minor issues with gettimeofday()...

I have a similar (maybe the same) problem with scorpio 1.8 on my x86_64 linux system, but I use a Athlon64. When the engines leaves the book and calculates itself, it gives a segmentation fault. I tried to debug with gdb:
I removed the book file for debugging.

Code: Select all

(gdb) run
Starting program: /home/andreas/Chess/engines/xb/Scorpio18/src/scorpio

scorpio.ini not found!
e2e4

Breakpoint 1, SEARCHER::eval (this=0x7fff12c8ff90, try_lazy=1) at eval.cpp:689
689                     c_sq = current->sq;
(gdb) p c_sq
$1 = 5403872
(gdb) p WB
$2 = (UBMP8 * const) 0x0
(gdb) step
690                     WB[c_sq + RU] += PAW_INC;
(gdb) step

Program received signal SIGSEGV, Segmentation fault.
0x0000000000406683 in SEARCHER::eval (this=0x7fff12c8ff90, try_lazy=1)
    at eval.cpp:690
690                     WB[c_sq + RU] += PAW_INC;

I think WB should not point to 0x0, but I don't get any further. It always hangs in eval.cpp line 690.
Surprisingly, the same source runs fine on my G5 Mac in 64 bit.

Hi all
I know that there were bugs in the smp version especially when running under linux. Last week i managed to dual boot linux on xp, and fixed those smp bugs. Also I implemented a shared object library to access the egbbs in linux too. I will upload the files after i arranged a free website to host the files.
best
Daniel

Hi Daniel,
a good free host is 110mb.com which gives you 2 gb of free space.
IGotFree.com is also good.
I would like to know if the 5 pieces bitbases are completed and if it's possible to generate them using the 5 pieces nalimov tablebases.
Thanks.

Hi Daniel,

I will upload the files after i arranged a free website to host the files.

I'd be glad to host them for you if you like.

Regards,
Jim.

Hi Ubaldo
They were finished a long time ago. Infact Leo used them for scorpio in the previous tournament. The problem is that they are too big to upload (360mb), and they are too slow to generate (2 months minimum). If you implement the access code in chiron, i think you can use it at least in WBEC. But you should test it before using it. I can not generate the bitbases from Nalimov otherwise they wouldn't be free to use.
regards,
Daniel

Hi Jim
Great! I will send the source code for scorpio 1.84 to you tommorrow. You can make a windows and linux exe and host them for me.

Daniel Shawul wrote:Hi Ubaldo
They were finished a long time ago. Infact Leo used them for scorpio in the previous tournament. The problem is that they are too big to upload (360mb), and they are too slow to generate (2 months minimum). If you implement the access code in chiron, i think you can use it at least in WBEC. But you should test it before using it.

Yesterday I've implemented and tested the access to your 4 pieces bitbases. It seems everything works fine, but I've not tested with any 5 piece bitbases.

I would like to make my own bitbases. Did you study something in particular to make your owns?
Thanks

Hi Daniel,

You can make a windows and linux exe

Unfortunately someone else will have to compile the 64bit or Linux sources.
I don't have those systems. (Time to upgrade I think before I get left behind.)

I'd be happy to compile the Windows 32bit stuff and host any files you wish.

Jim.

Jim Ablett wrote:... someone else will have to compile the 64bit or Linux sources. ...

I can try the Linux sources.


Volker

Daniel Shawul wrote:Hi Ubaldo
They were finished a long time ago. Infact Leo used them for scorpio in the previous tournament. The problem is that they are too big to upload (360mb), and they are too slow to generate (2 months minimum). If you implement the access code in chiron, i think you can use it at least in WBEC. But you should test it before using it. I can not generate the bitbases from Nalimov otherwise they wouldn't be free to use.
regards,
Daniel

Daniel, if you have a fast connection you could upload them as a zip file at http://www.badongo.com/ that lets you upload files up to 1 gb. So everybody will be able to download them. I've asked the same to Leo.
Regards,
Ubaldo

I don't have a fast internet connection. But i will try to upload them at night when it is faster. Anyway since Leo is going to upload them the problem is solved

To Jim:
I have sent the source code at the email address provided on your website.

Daniel

Daniel Shawul wrote:Anyway since Leo is going to upload them the problem is solved

I don't know if Leo is going to upload them, I've just asked him and I've not receieved an answer yet

What did you study to implement your bitbases Daniel?
Thanks

Ubaldo

I don't know if Leo is going to upload them, I've just asked him and I've not receieved an answer yet

Leo already contacted me and is willing to upload the files.

[quote]
What did you study to implement your bitbases Daniel?
[\quote]

I read the papers by E.Heinz on indexing of endgame tbs. Also an Msc desertation paper by Jasper (?) was a very good one.
You can find the link to it in this form if you search for the bitbase discussion.

The most difficult part I found was the compression part. Even though i managed to write a compressor which can compress the bitbases as good as zip, i am still not satisfied. I think that a domain dependent compressor, using genetic algorithms like ID3 and neural nets, could be much successful.

Daniel

Daniel Shawul wrote:Leo already contacted me and is willing to upload the files.

great

I read the papers by E.Heinz on indexing of endgame tbs. Also an Msc desertation paper by Jasper (?) was a very good one.
You can find the link to it in this form if you search for the bitbase discussion.

Jesper. I've downloaded them, thanks.