Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: C++ programmers: the price of syntactic sugar

Author: Bas Hamstra

Date: 22:18:15 02/24/01

Go up one level in this thread


On February 23, 2001 at 15:18:32, Pat King wrote:

>On February 22, 2001 at 15:46:20, Dann Corbit wrote:
>
>>On February 22, 2001 at 09:28:24, Pat King wrote:
>>
>>>On February 21, 2001 at 12:34:49, Jon Dart wrote:
>>>
>>>>
>>>>I predict that you find using piece declared as a class causes a significant
>>>>performance penalty.
>>>
>>>LOL that one doesn't take the psychic ability of the Great Kreskin.
>>>
>>>> You will wind up creating a lot of such objects. If created
>>>>on the heap, you will have the overehad of malloc() plus the cost of calling
>>>>your object constructor once per instance.
>>>
>>>I create exactly 32 objects at startup. I don't destroy and rebuild with
>>>captures and unmoves. So your point is true, but irrelavant.
>>>
>>>>Furthermore virtual functions are
>>>>slower to call than regular functions, due to the extra indirection.
>>>>
>>>True, but for my humble program worth the decrease in complexity. I've come a
>>>lot farther with Z2k than with the previous versions of Zotron, and I believe
>>>it's do to the OO approach and the elimination of as many "if" and "switch"
>>>statements as possible.
>>>
>>>>In my opinion, backed by experience, you'd be better off using a primitive
>>>>type such as "int" for piece values. Not as elegant perhaps but speed
>>>>counts in a chess program.
>>>
>>>Getting it working counts more. Zotron will admittedly never be as fast as a C
>>>program, but I never planned for it to be a world beater. It's just something
>>>for me to tinker with.
>>
>>A well crafted C++ program can perform as well as C or even Assembly.  Just ask
>>Amir Ban or look at Junior's ability.  While tortuous hours spent tweaking
>>assembly in some inner loop may yield a small payoff (and from time to time it
>>is worthwhile to do so) for the most part, clarity of expression will result in
>>bug free code which is far more important than many people realize.
>>
>>Some language choices will be a clear handicap (e.g. BASIC).  But for the most
>>part, the algorithm implementations will dominate the performance.
>
>Preaching to the choir, brother. But you can't convert the heathens in one
>fell swoop ;)
>
>Pat

Probably Junior is not a C++ program, but a 'Better C' program. Junior carefully
avoids all OO overhead.

Bas.









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.