Not logged inRybka Chess Community Forum
Up Topic Rybka Support & Discussion / Rybka Discussion / Any chance of a version for Solaris (x64 + SPARC)?
- - By drkirkby (*) [gb] Date 2007-07-12 15:27
I gather a linux version is a possibility. Is there any chance of one for Solaris (I'm mainly interested on SPARC 64-bit hardware)?

I doubt it would sell well, so you might think it pointless, but I think there is something else to consider, which might make it very worthwhile for you...

My experience of programming has been that one of the best ways to find bugs in code is to try the code on multiple platforms. I recall a colleague of mine running his finite element code on a dual processor x86 box without problems. He then tried it on a Sun SPARCstation 20 (quad 125 MHz CPUs) and found a bug. Sure enough, it was a real bug that did not show on Linux, but it was real and could have potentially surfaced at any time.

In some finite difference code I wrote

http://atlc.sourceforge.net/

I too found bugs on one platform but not on another. The program is very portable - to quote from my web page

"In addition to the the commmon Linux PC, atlc has been tested on a Sony Playstation 2 as well as the Cray YMP-EL supercomputer, which is available for free public access at Cray-Cyber network. It has also been tested on Debian Linux, Slackware Linux, Gentoo Linux, Redhat  Linux, Suse Linux, IBM's AIX, Apples's OS X for Mac, HP's HP-UX (both PA-RISC and Itanium), SGI's IRIX, Sun's Solaris, SCO's UNIXWare, HP's Tru64, Cray's UNICOS, NetBSD, OpenBSD and FreeBSD. " (It runs on Windows too BTW).

There can't be many programs run on both toys and supercomputers! I too have found bugs on one platform, but not on another, so the multiple platforms has really helped reduce bugs. (There was a 'portability issue' on the Cray, perhaps rather than a real bug, as the Cray had sizeof(short)=8, but I worked around that. But other issues that come up were real bugs, which seem evident on one platform but not another.)

Also to quote from my Sourceforge web site on 'atlc':

"Previous version of atlc could use multiple-processors if present, to reduce execution time. This has been temporarily disabled, as the algorithm had some intermittent problems on IBM's AIX operating system. Careful checking showed the problem that only seemed to affect AIX, was a real bug with the potential to occur on other operating systems, although it only ever showed up under AIX. Hence the current release has disabled the support for multiple processors - atlc will run fine on multi-processor machines, but it will only use one of them."

I think testing on multiple platforms is very useful. If you manage to build a version on Solaris, why not make it available? I believe Sun sell machines with more than 100 CPUs - you might even get someone to run it on one!  I only have a quad CPU (450 MHz) Sun Ultra 80 myself which is obviously rather old, so I think Rybka would work better on my laptop (Sony VGN-XWN/C 2 Duo Processor T7200 2.0 GHz) than on my quad CPU Sun. but my Sun is on 24/7, where the laptop is not.

It's possible to buy a multi-processor (32-bit) Sun SPARCstation 20 for less than the cost of even the single CPU version of Rybka. A used dual 64-bit processor Sun Ultra 60 (2 x 450 MHz) could be purchased for less than twice the cost of the MP version of Rybka ,  so for portability/testing purposes, there is very cheap hardware available.

Dr. David Kirkby
Parent - - By Sesse (****) [no] Date 2007-07-12 23:44
Something tells me you'll have quite more luck porting one of the engines that are free software :-) (I'd appreciate ports of Rybka to every platform in the universe, too, but I think the chances are pretty slim given the business potential and the relative speed/cost of x86-based chips compared to almost everything else out there currently.)

/* Steinar */
Parent - - By drkirkby (*) [gb] Date 2007-07-13 00:14
If a Linux version existed, a simple recompile should get it working on a Sun, although that might not be true for a multi-processor version - it would depend how it was programmed.

Other engines such as Crafty and Toga do run on the Sun. The only change I had to make to Toga was to rename a function from 'quad' to 'quad2', as 'quad' is used by Sun in Solaris for something. Nothing else was necessary. It took me all of 10 minutes to have it running on the Sun.

I'm sure the business potential for a SPARC Rybka would be small to non-existant, but there would I think be a lot to be gained from the point of finding bugs. Bugs are likely to surface on the Sun which are just waiting on Linux to rear their ugly head at some time in the future.

BTW, Solaris runs on Intel & AMD hardware. I have Solaris on a AMD Opteron (64-bit), but it also runs on 32-bit Intel/AMD hardware. I tend to use SPARC (64-bit) myself more, but if built one built it on one system, the other should just need a recompile.
Parent - - By Sesse (****) [no] Date 2007-07-13 09:43
That depends. Structure alignment, endianness assumptions, unaligned accesses, Solaris shared memory vs. Linux shared memory, sizeof(long)... It's probably not that difficult, but it still has to be done; I've seen my share of x86 vs. SPARC bugs that didn't really help to do much except get it running on SPARC. :-) (Having a 64-bit port helps in the first place, of course.)

SMP in Rybka works, AFAIK, by separate processes, shared memory and pipes, but I guess this would change for Rybka 3 if Vas found a threading approach advantageous somehow.

/* Steinar */
Parent - By drkirkby (*) [gb] Date 2007-07-13 12:47
I don't think structure alignment woud be a big issue. Using the same compiler would I think help. Structures have never presented me problems in moving code.

Endianess is mainly an issue only when reading/writing files. That would be an issue if the book is written in an unknown format, but if Rybka goes to its own book, in a format Vas decides upon, that would not be an issue. (I gather a lot of people, myself included, would like a book that is not in a ChessBase format. Having a book that could be shared with Toga would for example be useful. ) 

I'm not an expert, but I don't think threads work too well on NUMA architectures, such as the AMD Opteron, since access to memory local to that CPU is much faster than to another CPU. That is not an issue on SPARC.

Perhaps I write highly portable, but buggy code, as I've never had much problem moving console based code (i.e. no GUI) from x86 -> SPARC or SPARC ->x86,  yet have found it useful for bug-tracking. I know that is the case too when an ex-colleage of mine tested his finite element code on SPARC.

Of course, if sections of Rybka were in assembler and no equivalent C/C++ existed, then it would be a time-consuming task, where the effort would exceed any benifits.
Parent - By Vasik Rajlich (Silver) [hu] Date 2007-07-14 06:45
I'm afraid that it just won't be possible to ever justify a port to this type of platform. I can promise to keep an open mind.

Re. debugging, your comments are valid but I'm not sure that they apply to a chess engine. Chess engines are weird beasts and their bugs tend to be a bit different than the normal array overflows, assumptions about memory contents or pointer indirections, etc.

Vas
Up Topic Rybka Support & Discussion / Rybka Discussion / Any chance of a version for Solaris (x64 + SPARC)?

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill