Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Symbolic: A doomed effort, or it's time to get my lead-lined jockstr

Author: Robert Hyatt

Date: 10:13:49 02/17/04

Go up one level in this thread


On February 17, 2004 at 12:39:52, Daniel Clausen wrote:

>On February 17, 2004 at 10:55:42, Robert Hyatt wrote:
>
>[snip]
>
>>>In which area a certain chess engine belongs to is not at all clear. Depending
>>>on your goals it may very well be a good idea to use a high-level language and
>>>therefore have more time to test lots of new ideas than implementing it in C
>>>and be somewhat less flexible.
>>
>>I won't disagree.  But once I get the ideas firmed up, lower-level-language
>>here I come.  Because then I want speed...
>
>Well, it depends on what you mean with "ideas firmed up". The moment you go to a
>lower-level-language (say Asm, to be extreme) you won't have the possibility to
>ever change big parts of your ideas later on. (w/o having lots of work or simply
>start with a new engine)

Let's take Cray Blitz as an example.

I had the classic SEE function.  Re-wrote in assembly to make it 5x faster
because I could use some hardware instruction and vector tricks that the
compiler thought were unsafe.  Never changed it again.

Move generator.  Same song.  Second verse.

Make/Unmake.  Same song, third verse.

Those simply don't change often, although of the three mentioned, make/unmake
had the greatest probability of change due to adding some incremental update
stuff for speed.

We later did most of the evaluation the same way, piece (function) by piece.

Then the last thing I did by myself was to rewrite the search itself, but only
after we were happy with everything including the singular extension
implementation.  And this ended up being a headache at times as search (and the
evaluation) tend to be the most dynamic parts of a chess engine.  However, we
kept the pure FORTRAN versions of everything, and changes were first made there,
then ported to the asm so that it was easier to debug.

Some parts of a chess engine are pretty safe to do in asm.  Some parts would
produce pain due to frequency of change.

IE in Crafty, all I have is PopCnt(), FirstOne() and LastOne().  We really don't
use the PopCnt() any longer (assembly version), and FirstOne()/LastOne() don't
change, but also are not needed for compilers that have C intrinsics that access
the bsf/bsr-type instructions...




>
>Depending on your goals that may be OK. And for commercial engines it's probably
>needed in order to be on the very top of the list. But w/o basically starting a
>new engine, I don't think you can ever come up with something drastically
>different afterwards. Depends on your goals. I think Edwards aim is not to win
>the coming CCT7 but investigate computer-chess in a direction where not many
>people went yet.

Absolutely nothing wrong with that, either...


>
>
>>A good question: "why do you suppose nearly _all_ current programs are written
>>in C?  (the only exception I can point to for a successful program was Cray
>>Blitz which was fortran)???"  Answer -> performance.
>
>That's probably true, I agree. It doesn't mean though, that if some of the guys
>would have used another language and would have had more time to develop others
>ideas, the missing 50-100 ELOs from lack of speed would be regained again. Maybe
>even more. :)
>
>
>>A few have even gone all
>>the way to assembly (Older Fritz versions for example).  Again for performance.
>>Not because they like asm programming.
>
>Well, it seems the Fritz team switched from Asm to something else. (probably C)
> Sounds like a stupid idea to me! Afterall they lose speed! ;) There were
>obviously more important issues, why they decided to switch. Likewise, I can see
>chess programmers, who think that _for them_ it's better to make yet another
>step and go to a high-level language.

They switched because of the portability issue.  IE that haunted us on the Cray
many times.  The XMP added new instructions.  The YMP added some instruction
changes that produced debugging.  The C90 extended the vector register length to
128 words, which required significant changes to use (if we wanted to take
advantage of the new architectural features).

That is the main down-side to asm programming, IMHO.  Through 1980, every O/S I
worked on (IBM OS/360, Xerox UTS and CP-5/CP-6, etc) were written in assembly
language, yet they were changed dramatically from release to release.  The good
thing about C is that I just use the amd64 compiler and I run on an AMD64
efficiently.  With assembly, I could run more efficiently, but it would have
taken far longer to "port" the thing...

>
>I guess our POVs are not as far away as it seems to me. :)
>
>On a larger scale: If I understood you correctly (in other posts) you POV is
>that mini-maxing will always be the heart of a chess engine. I think that too to
>a certain degree, but I can imagine that it's possible to develop a chess engine
>which uses the mini-maxing more as a 'verifier' whether the engine-developed
>plan works tactically or not. So it still would be an important part of the
>engine, but not its heart.

Hard to say.  Minmax/alpha-beta is what works today.  Nothing says that
something better won't come along tomorrow.  Nothing suggests that it will, but
nothing says that it won't either.



>
>(more later, but I have to run to the train!)
>
>
>Sargon



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.