Author: Vincent Diepeveen
Date: 03:41:28 08/17/00
Go up one level in this thread
On August 16, 2000 at 17:12:46, Dann Corbit wrote: >On August 16, 2000 at 17:06:18, Severi Salminen wrote: > >>>The efficiency difference is not important enough to worry about. Any >>>differences in strength will be far more dominated by your choice of algorithms >>>than by your choice of compiler. The biggest difference a compiler will make >is a small constant factor. >> >>What I ment was the difference between C and C++ in efficiency? Do objects have >>any tendency to be faster/slower than traditional implementations of same >>algorithms? > >Depends on what you use. > >Try/Catch will give you about 1% speed penalty. I don't think that will break >the bank. And RTTI is expensive, but if you already know the types of your >objects in advance, you won't have to use it. > >The real difference in speed between an object model and a procedural model >might be 5% or less (probably 1 or 2 ELO). On the other hand, I think OO models >are a lot easier to understand and maintain. Hence, you can improve them more >rapidly. Oh well, in this same thread Tom explains that even TSCP already got 5% slower just litterary changing code to .cpp and after having put it in a class. That's quite a penalty for doing exactly the same! Not to mention the so many times slowdown you get if you work with objects that get deleted and allocated quite a few times. >The difference in choices of algorithm can make orders of magnitude of >difference. That is the place to focus your effort. I remember i implemented my draughtsprogram first in Gofer, a functional algorithm. Then i translated it to C. This first version ran about 10000 times faster in C as in Gofer. I got 20k nodes a second in C, 2 nodes a second in Gofer. This was at a pentium100 Later i managed to improve the draughtsprogram speedwise after quite some effort (about a week worth of programming in the summer). Then a few months later after having studied my Gofer code closely a smart student managed to improve this gofer code and got an in his eyes dramatic speedup: 2 times. So even the first straight translation to C was 5000 times faster then. Now we can talk about algorithms and smart searches, but there is a point where speed matters a lot. That point lies around 10 ply to 12 ply. You really need over 10 ply each search, no matter the language you use. Or you simply don't get through the what i call tactical barrier. If the program improves you'll notice that 12 ply is an important barrier as well, and that's not an 'accident' depth. Above 12 ply i don't give a penny for more plies. I'd focus on quality of the evalution code. Note that in WMCC i expect to search 10 ply With DIEP. Usual that's also enough, but especially at the start of the game, where all programs play real bad, there i would love to get 12 plies. >>>I would write in whichever I was more comfortable with, if I were you. Since >>>you are new to OOP, I suspect your C++ implementation would be dissapointing. >>>On the other hand, it would be a good way to learn the language better. >> >>>You will be dissapointed with the free Borland compiler for Chess programming. >>>If you just want something free, I think you will find that Cygnus GCC emits >>>better binaries. >> >>Well, the compiler performance is not a big issue here as I can allways chance >>to more efficient compiler. I hope Borland follows the normal ANSI-C >>standards... Where can this Cygnus GCC be found? > >At redhat.
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.