Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: c,c++5,c#.

Author: Uri Blass

Date: 20:14:22 08/13/04

Go up one level in this thread


On August 13, 2004 at 06:01:49, Tord Romstad wrote:

>On August 12, 2004 at 15:07:51, Sune Fischer wrote:
>
>>On August 12, 2004 at 06:01:32, Tord Romstad wrote:
>>
>>>On August 11, 2004 at 15:33:16, Sune Fischer wrote:
>>>
>>>>For chess, since you ask, it must be fast so either C or C++.
>>>
>>>I don't quite agree.  Speed is vastly overrated in computer chess.
>>>Except for a few games between the top professional engines, speed
>>>is rarely the decisive factor.  Bugs and efficiency on a higher
>>>level (i.e. good algorithms) are far more important.
>>
>>I know what you mean of course, but speed really is a factor in computer chess.
>>It's not the most important factor, but not something to be ignored either.
>
>I think it is something that can and should be ignored, until you have a
>rather strong engine.  Bugs is one factor, as mentioned above.  Another
>important point, which you bring up later in the thread, is testing and
>experimentation.  For a not very strong engine, it is not a bad idea to
>sacrifice some speed in return for flexibility.

I can say that I did it but the problem is that I like improvement and I do not
like to going one step backward for the hope to go later forward.

This is one of the main reasons that I spent time about optimizations(and the
optimization that I did were only about better algorithm when I have no
assembler code).

This is also a reason that I decided not to go for starting to write a new
engine and I prefer simply to think about replacing the structures that I have
in the old code(I already did part of it and old movei has struct for moves when
new movei have int for moves).

I have no problem with the fact that it is possible to do the program faster but
I really do not like to see the program becomes slightly slower when I did only
cosmetical change like having class for time varaibles(I plan to do more
cosmetical changes and I find myself waste time about thinking if there is a
reason for it and trying to see if I can change something else to prevent the
demage that is only about something like being 3% slower).

There was already time when I got 5-10% slower when I got rid of my incremental
piece square table evaluation when I decided that when I have more than one
piece square table for the king and I need to do averages it is hard to remember
everything incrementally without bugs.

Fortunately I probably did other changes both in evaluation and search that
worth more than the demage.
>
>>>It is better to just choose some language with which you feel comfortable,
>>>and with which you are able to write clear and reasonably bug-free code.
>>
>>I'm not sure I see the point of writing an engine in a slow language, why
>>handicap yourself from the beginning?
>
>To a certain extent we agree.  We both think that uncompiled languages
>are too slow, and that languages with enforced bounds checking should not
>be used.  A sufficiently fast language is required.  Our disagreement
>seems to be about what "sufficiently fast" means.  Apparently we agree
>that it is not necessary to go all the way down to assembly language.  My
>opinion is that it is also not necessary to go all the way down to C/C++.
>
>>Do you not want to write the best engine you can?
>
>Not if it means writing everything in assembly language.  A few other
>people might reply "not if it means writing everything in C/C++" (for
>me, however, C is OK).  This does not mean that there projects are doomed
>to failure.  After all, there is at least one Delphi chess engine which
>is far stronger than both of our engines.  ;-)

I am not sure about it and Delfi has similiar strength to Gothmog but Delphi has
almost the same speed as C.

The main problem is when you are twice slower or more than it because of not
using C.

Uri



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.