Computer Chess Club Archives


Search

Terms

Messages

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

Author: Matt Taylor

Date: 12:30:23 12/25/02

Go up one level in this thread


On December 25, 2002 at 06:05:39, David Rasmussen wrote:

>On December 24, 2002 at 13:32:42, Matt Taylor wrote:
>
>>
>>I am aware of the virtues of C++. I have been programming in C++ for the past 10
>>or 11 years. Not as long as some, but plenty long enough to be intimately
>>familiar with the language.
>>
>
>That depends on how you've used it, and whether you've tried to keep up. C++ of
>today is not C++ 5 or 10 years ago. Besides from the standardization in 1998, we
>know a lot more today than we did 10 years ago.
>
>>My point was that polymorphism would be the main benefit for a chess engine.
>
>I disagree.

Please name some other uses then.

>>I
>>don't see any particularly clever use for templates or operator overloading
>>here. Of course, some will always do it because they can, even if it's a bad
>>idea.
>>
>
>Imagination is the key here. C++'s features can be used for chess programs in a
>positive and constructive manner.
>
>>A switch statement will always be faster if the compiler is any good at
>>optimizing it. The difference is that it avoids extra stack usage, function call
>>setup costs (preserving registers), and in some cases you can get a branch
>>prediction hit.
>>
>
>It depends. You can't just compare a virtual function call to a switch statment.
>Often this switch statement will be inside some function, so there is function
>call overhead anyway. The cost of this function call + the switch statement
>needn't be lower than that of a virtual call. Also, I don't want to "optimize"
>just for the sake of doing it. Virtual functions, if needed at all in this case,
>can be used many places in a chess program without affecting overall speed. If
>you find on your particular implementation that with your particular design and
>program, skipping virtual functions will give you 5% more speed (which will
>depend on your implementation, and only be the case if you use them at the heart
>of some often used code, check with a profiler), you can decide whether you want
>to break your design for that 5% gain. It practice, it's not an issue if you do
>it right.

In the case of a direct call, the pipeline is not broken as the address can be
predicted. Furthermore, if you profile, you can inline in some cases for more
performance.

Most switch/case statements get implemented using a table of pointers, but for
small ones (such as move generation where you have a limited number of pieces),
you can do it extremely efficiently. Also, since static prediction predicts "not
taken," you're putting useful code in the cache.

>>>>If you convert to C++ without using virtual functions, you probably won't take
>>>>much of a hit at all. Personally, I've never seen a -need- to convert to C++.
>>>
>>>I see no need to use an inferior language to express the same thing for no gain
>>>at all. C++ gives my type safety, better I/O and a lot more.
>>
>>Better I/O? You mean you like the I/O library better?
>
>I mean first of all type safe I/O unlike printf etc.
>Also, the expressibility of iostreams cannot be compared to the printf family of
>classes. iostreams are much more expressible.
>
>> I find printf-style easier
>>to read. I've never had a problem with %f bugs in my code because I don't pass a
>>user string into printf directly.
>>
>
>Lack of type safety.
>I have seen many bugs of this kind, if not in my own code.

Actually the gcc compiler will type check printf arguments in C or C++ code.

>>In terms of "good language" vs. "bad language", C++ really maintains no
>>advantage over C.
>
>Sure it does. Even pure C with a C++ compiler is better than C, because several
>holes in the type system have been closes, enums etc.

Only within a module. Name decoration is required to check between modules. The
biggest source of type check bugs lies in header files that don't match
libraries.

>>Someone who wants a "good language" can write their code in
>>Ada. I will write mine in C.
>>
>
>Ada is a much better language in C, I'll give you that. And I would prefer Ada
>over C++ in most cases. Though, templates of C++ are far more powerful than
>generics of Ada. Look at the Booch components. In Ada they were 125.000 lines,
>in C++ they were 10.000 lines. Also, Alex Stepanov gave up implementing the STL
>in Ada (his prefered language) and turned to C++. There are some real advantages
>there. My ideal of a systems programming language (which we're talking about
>here) would be the basics of Ada (basic language features, syntax etc.) with the
>C++ OO model and templates, or in fact, a full generic programming language
>subset. And skip the built concurrency model, since it is too restrictive for
>many different tasks.
>As things are today, I would go with C++. If someone forced me to go with Ada, I
>wouldn't cry. If someone forced me to go with C, I would. A lot.

I must confess that I do not particularly like Ada or Java. I prefer C++
templates to Ada generics, though I prefer the block structure of Ada generics.
My problem with Java is that it has no unsigned types, does not permit
procedural code, and I do not like its exception mechanism. (I will save my
compelling arguments as I feel they are OT here.)

The power of abstraction can be nice, but in the case of inheritance and
templates, it can often cost more than it is worth in a
computationally-intensive program. Multiple inheritance is difficult to
implement, and complex templates can be extremely difficult to get right.

Truthfully, I do not find any language really to my liking, though perl is my
favorite for small projects. As a side project, I've spent the last month
working on a compiler that has most of the semantics of C/C++, but the goal is
to (1) implement a method to abstract machine details within C-like constructs,
(2) allow for optimization beyond what can currently be achieved, and (3)
implement type safety in excess of what popular languages currently implement. I
can make guarantees about bounds of variables and validity of any memory access
regardless of pointer arithmetic.

In short, I do not believe any C-like language currently offers what it SHOULD,
and I intend to implement a compiler that addresses that.

-Matt



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.