c vs c++

[ethanara]

BTW, talking about languages, I stumbled across this go language:

http://golang.org/

I have to say that it has some good ideas...it is not bad ! But I have not coded in this language, so my opinion is very very just a guess.

Interesting. Nearly all things made by google has been succesful, so maybe one will give it a try.
I was thinking if its speed is comparable to c / c++ ?
Also, is there any modern engines made in ASM ?
Regards,
Ethan

[IanO]

BTW, talking about languages, I stumbled across this go language:

http://golang.org/

I have to say that it has some good ideas...it is not bad ! But I have not coded in this language, so my opinion is very very just a guess.

Interesting. Nearly all things made by google has been succesful, so maybe one will give it a try.

To specify, nearly all things made by Ken Thompson have been successful. After many decades, you'd think Ken would have many, many itches to scratch in C (in the application domain, where Go is targeted).

I was thinking if its speed is comparable to c / c++ ?
Also, is there any modern engines made in ASM ?
Regards,
Ethan

Speed is slower, because Go uses garbage collected dynamic memory. Go is C/C++ taken in the direction of Python but retaining static typing, to make it more suitable for large application projects. But it does have language features to code multiprocessing and concurrency more easily and reliably, using the CSP model.

[Rein Halbersma]

Also, and contrary to popular belief, there nothing C++ can do that C can't do.

Also, and contrary to popular belief, there nothing C can do that assembly can't do.

This is just a joke Lucas, thanks for your kind words on SF !

The Stockfish code is a lot nicer than most other engines. But it could be taken to a much higher level if more use was made of the STL. Just to give a simple example, taken from move.h:

Code: Select all

template<typename T>
inline T pick_best(T* curMove, T* lastMove)
{
    T bestMove, tmp;

    bestMove = *curMove;
    while (++curMove != lastMove)
    {
        if (bestMove < *curMove)
        {
            tmp = *curMove;
            *curMove = bestMove;
            bestMove = tmp;
        }
    }
    return bestMove;
}

This code is inefficient for 2 reasons. 1) It does too many swaps, and 2) it retuns a copy rather than a pointer to the best move. Much easier to use std::max_element to find the best move, and std::swap to place this at the front. Finally it is better to return a pointer to the best move, rather than a copy.

Code: Select all

#include <algorithm>

template<typename T>
inline T* pick_best(T* curMove, T* lastMove)
{
    T* bestMove = std::max_element(curMove, lastMove); // find the best move
    if (bestMove != curMove) 
        std::swap(*curMove, *bestMove); // swap best move to the front
    return bestMove; // return pointer to best move;
}

This code works as long as type T has an operator< and an operator= (which it does because these operators are also used in the current code).

There are many other places where explicit loops and comparisons could be eliminated by proper usage of the <algorithm> part of the STL.

[mcostalba]

This code works as long as type T has an operator< and an operator= (which it does because these operators are also used in the current code).

There are many other places where explicit loops and comparisons could be eliminated by proper usage of the <algorithm> part of the STL.

Hi Rein,

first point: thanks a lot for your suggestion. I really like this kind of improvments and I always glad when someone comes with a good idea.

second point: can we bet a beer my code is faster than yours ? I still think mine is faster (I have very deeply tried to tune it), anyhow I for sure will test your suggestion.

third point: in case you see some other possible improvment please be so kind to post.

Thanks
Marco


P.S: BTW a move is an integer so better return by value I guess....

[Desperado]

Hi Ethan,

i suggest you choose the language you are more experienced in,
so you can focus on writing the contents of chess programming.
That will be hard enough i think.

But if there is no preference at all, you may ask yourself which
kind of progammer you are ?

Are you thinking in procedural/functional terms, or have been objects
your general base for designing your programs in the past ?

Very important are your goals, what you want to do later with your engine.

As example:
my preferences is clearly procedural/functional thinking
about solving problems. Thats why i choosed C for myself.
But currenty i am writing a genetic algorithm tuning evaluation terms,
and guess what ? ... if that had been a goal from start point, it now
would be much easier creating a set of 100 players (objects) having
all relevant code in it. I mean each player would have its own set
of eval-terms,evaluation-methods...

So dont forget, the base concept of c++ and c is complety different.

(And _if_ there would be a speed difference when optimal coding,
it is cetainly insignificant argument to choose the language,
compared to the mentioned points.)

regards Michael

[Rein Halbersma]

This code works as long as type T has an operator< and an operator= (which it does because these operators are also used in the current code).

There are many other places where explicit loops and comparisons could be eliminated by proper usage of the <algorithm> part of the STL.

Hi Rein,

first point: thanks a lot for your suggestion. I really like this kind of improvments and I always glad when someone comes with a good idea.

second point: can we bet a beer my code is faster than yours ? I still think mine is faster (I have very deeply tried to tune it), anyhow I for sure will test your suggestion.

third point: in case you see some other possible improvment please be so kind to post.

Thanks
Marco


P.S: BTW a move is an integer so better return by value I guess....

Hi Marco,

2nd point: Most of the STL algorithms use iterators as the return type so it's more natural to do it that way. For ints there should not be any difference since you can always do something like

Code: Select all

Move bestMove = *pick_best(curMove, lastMove);

and the indirection will by optimized away (return-value-optimization).

Other examples to look at are the TT in Stockfish. I would suggest to use a std::vector for the memory management rather than explicit new/delete. Also the probe/store algorithms can be made more compact.

Rein

[Don]

BTW, talking about languages, I stumbled across this go language:

http://golang.org/

I have to say that it has some good ideas...it is not bad ! But I have not coded in this language, so my opinion is very very just a guess.

The performance is not there yet and may never be. It's an awesome language however.

I'm very much of thinking of digital mars D - I think it's superior to C and C++ is almost every way and it's going to soon be a part of GCC. I think that is also true of golang. D has the potential to be faster than C (even though it's a bit slower currently) because the author tried to avoid things that make it difficult for the compiler to generate optimal code.

[mcostalba]

Code: Select all

#include <algorithm>

template<typename T>
inline T* pick_best(T* curMove, T* lastMove)
{
    T* bestMove = std::max_element(curMove, lastMove); // find the best move
    if (bestMove != curMove) 
        std::swap(*curMove, *bestMove); // swap best move to the front
    return bestMove; // return pointer to best move;
}

This code works as long as type T has an operator< and an operator= (which it does because these operators are also used in the current code).

Perhaps I am missing something obvious, but this code does not work for me: I got different node count when I do

./stockfish bench

I am sure there is a clear reason for this, but now is really too late to even start thinking.....

[rbarreira]

BTW, talking about languages, I stumbled across this go language:

http://golang.org/

I have to say that it has some good ideas...it is not bad ! But I have not coded in this language, so my opinion is very very just a guess.

The performance is not there yet and may never be. It's an awesome language however.

I'm very much of thinking of digital mars D - I think it's superior to C and C++ is almost every way and it's going to soon be a part of GCC. I think that is also true of golang. D has the potential to be faster than C (even though it's a bit slower currently) because the author tried to avoid things that make it difficult for the compiler to generate optimal code.

I know someone who had a relatively big program in D and decided to start over in C++ due to compiler bugs, lack of a 64-bit compiler and incompatible libraries.

It's a promising language but not near maturity yet. Where did you read about GCC including a D compiler soon? AFAIK it had one but it was not maintained in a while.

[wgarvin]

There are many other places where explicit loops and comparisons could be eliminated by proper usage of the <algorithm> part of the STL.

Of course the downside of this approach is that you have to use the STL.

Random example #1: STL container types are heavily templated, causing lots of generated code bloat in a large program that uses vector<> or other containers over lots of different types. I've seen large codebases that contained instantiations of vector<> for hundreds of different types, adding up to several megabytes of generated code. On some platforms you just cannot afford this. Even on PCs with abundant RAM and virtual memory, more code still means more page faults, or at least more icache misses. To avoid this penalty, we use our own container class implementations that are compatible with <algorithm> etc. but were designed to keep generated code size to a minimum while still being reasonably efficient.

Random example #2: For a long time, the compiler for one of the current-gen consoles did not optimize well small inline functions with boolean return values (it generated 7 instructions instead of 2, or something). This is unfortunately a common pattern with STL predicates, iterator comparison operators, etc. So the recommendation on that platform is to not use iterators for performance-sensitive loops.

Personally, I don't like the STL container classes much. Iterators are overly complex and unsafe. Rules for iterator invalidation are inconsistent from container to container, the APIs are inconsistent, etc. <algorithm> does have a few useful tidbits in it. I probably use std::sort and std::lower_bound more often than anything else. The old C++ iostream stuff is a disaster and is best avoided.


...The rest of this post is my own opinionated stance about C++. Others will certainly have a different view! On this topic though, everyone who disagrees with me is WRONG!


C++ is full of dangerous features that are awfully easy to hurt your performance (or your sanity) with: exceptions, default constructors, member function pointers, and so on. The STL is like everything else in C++: it has some goodness if you use it properly (and carefully), but its awfully easy to shoot yourself in the foot with it.

One way of using C++ that is relatively safe is, to use it as "C with classes". Use inline methods to make code more readable. Turn off exceptions and RTTI. Do file I/O and string operations just like you would in C: sscanf, sprintf etc. still work just fine. (Or use std::string when you just don't care). When you need dynamic arrays, use vector<> unless you have something you know is better. Don't use any linked-list containers unless you are sure you know what you're doing. I think vector<> and map<> cover 95% of all reasonable container-class use cases for most programs.

Don't use virtual methods except where you need them. Don't use multiple inheritance except to mix in small classes with no virtual methods or alternatively, to mix in abstract base classes (what would be known as "interfaces" in a language like Java). Don't use virtual base classes. Don't use pointer-to-member types (they're useful for type deduction, and for implementing delegates, and... thats about it). Use operator overloading for math types only (e.g. vector/matrix). Make constructors explicit if they are costly and you don't want to call them by accident.

Use templates to make code safer and clearer, but DON'T use more than 1 level of templates unless you enjoy debugging pain. Container classes are a good use of templates. Computing integer square roots at compile time is a bad use of templates. Template metaprogramming is the land of undebuggability. Boost is a good example of the horrors that are possible with C++. It seems all nice when you're a user of it... until the first time you hit some difficult problem and have to debug the guts of boost in order to solve it. Save your time and sanity by just not using boost in the first place.