Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: C and C++ --- NPS

Author: Sune Fischer

Date: 02:40:59 12/28/02

Go up one level in this thread


On December 27, 2002 at 12:12:41, David Rasmussen wrote:

>On December 27, 2002 at 07:06:02, Dave Gomboc wrote:
>
>>On December 26, 2002 at 21:36:49, Matt Taylor wrote:
>>
>>>C has been around for more than 30 years. C++ is still somewhat young. Some of
>>>the C++ constructs optimize very well, but many don't, particularly templates.
>>
>>I think this advice is a few years behind the curve.  It's precisely templates
>>that allow C++ linear algebra libraries, for instance, to exceed the speed of
>>their Fortran counterparts.
>>
>
>Agreed. But I think I will refrain from posting in this thread from now on.

That's too bad, I have a question now :)

During my transformation from C to C++ I have noticed a few things.
Granted I'm not the most gifted C++ programmer, but I don't think that matters
here.

1) I have noticed the size of the binary is growing rapidly, even a fairly small
change in the code and the binary is suddenly 50 kB larger.

2) I have seen no loss of speed, what so ever (in spite of the larger binary!).

3) It takes longer to compiler C++ code, in some cases up to 5 times longer.

I don't care about 3), that just means the compiler is doing all the hard work
for me :)
But I am concerned about 1), is there any way to explain it, and perhaps do
something about it? It doesn't show on my benchmarks, but I still don't like
such huge binaries.

My latest has grown from 136 kB to 540 kB (!) during the transformation.
I believe it is mostly from linking to STL and iostream, things like that.

I dl the source code for GreKo, and saw the same thing when I compiled it: 353
kB, I think in pure C it wouldn't have been much larger than 100 kB.

What is your take on that?
My guess would be that most C++ constructs are not handled in the compile phase,
but at runtime??

-S.


>The
>subject of the thread is whether NPS is inherently affected by the choice of C
>versus C++, and implicitly whether C++ is a suitable language for a chess
>engine. And the answers are obvious in both cases to anyone who is not a novice
>at C++. A novice at C will write a poor engine in that language too, as is the
>case for any other language. The question in itself is reasonable, if you don't
>know the answer. After all, asking the same question for Perl, Python, SML and
>Common Lisp (given existing and widely used implementations) will yield a
>totally different question. NPS will drop immensely in those cases, and I for
>one don't think that those languages are a good choice in practice for a
>competitive engine. For C++, these problems aren't true. That doesn't mean that
>C++ is necesarily better than, say, C. But it is definitely not worse, as some
>people here seem to think. If a programmer knows only Perl, we will have a
>problem creating a competitive engine. If a programmer knows only C++, he will
>have no problem generating a competitive engine.
>
>/David



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.