c vs c++

[kongsian]

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.

Go has no intrinsics, so bit scanning and counting will be slow.

Kong Sian

[jshriver]

This topic comes up in many forums and discussions over the decades.

Usually boils down to this:

1. Bulk will say C
2. Some will say C++ and say that properly written C++ can outperform poorly written C code as the complete basis for saying C++ is better


...
3. Few will argue it doesnt matter and the compiler is more important.
4. 1 guy on the internet claims we should all write in pure assembler.
5. 1 other guy will dog the #4 guy claiming we should all write in pure 1's and 0's using a very strong magnet manually manipulating sectors on a disk.

[jshriver]

the only problem is that the intricacies of C++ have now become so complex that, in fact, very few C++ programmers know what they are doing...

Hehe back in the 90's I completely bi-passed C++ after a painful experience and mental bending. Tried Java when it came out and was ok, but really not my thing, went back to C and been there ever since.

For me it's Perl for data processing, and C for the rest.

Well php for web

[Ron Murawski]

Where did you read about GCC including a D compiler soon? AFAIK it had one but it was not maintained in a while.

The GDC front end for GCC is being maintained once again
https://bitbucket.org/goshawk/gdc/wiki/Home
https://bitbucket.org/goshawk/gdc/downloads (download)

Ron

[michiguel]

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.

We discussed it about a year ago. Sounds interesting, but it does not have assert() for philosophical reasons. That is a huge turn off for me. However, I guess one could make his own version of it.

The concurrency features sound appealing.

Miguel

[Rein Halbersma]

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;
}

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.....

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 *curMove; // return the front move;
}

My bad: the return statement should yield the move at the front of course. Note that I also changed the return type to T rather than T*, so it now has the same signature as the current pick_best in Stockfish.

[tpetzke]

>I was thinking which language is fastest at chess programming, c or c++ ?

I'm definitely faster in writing and maintaining chess program in c++ compared with c, as the object oriented software engineering methods just lead to objects and classes at the end and it's more natural to implement them just like that. I'm convinced that using OOP gives me a better structured program, fewer bugs and so a stronger engine even if it slows down the engine a bit.

My engine spends 0,17% of its time creating objects and 0,10% deleting them. I can live with that.

Thomas...

[mcostalba]

My bad: the return statement should yield the move at the front of course. Note that I also changed the return type to T rather than T*, so it now has the same signature as the current pick_best in Stockfish.

I still get different results, although not so different

BTW after a very quick test I see the following is faster (but still slower than mine, although not posible to speed compare correctly until functionality is different).

Code: Select all

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

Tested with g++ 4.4.0

[Rein Halbersma]

My bad: the return statement should yield the move at the front of course. Note that I also changed the return type to T rather than T*, so it now has the same signature as the current pick_best in Stockfish.

I still get different results, although not so different

That is because your current algorithm is not stable and mine is Take e.g. a list of for move structs with the following labels and scores that are generated in this order

{ {a, 1}, {b, 2}, {c, 2}, {d, 3} }

Your current algorithm does a number of swaps and returns {d, 3}. After the algorithm the list looks like this:

{ {a, 1}, {a, 1}, {c, 2}, {b, 2} }

Using the std::max_element and std::swap you also get {d, 3}, but the list looks like this:

{ {d, 3}, {b, 2}, {c, 2}, {a, 1} }

So you will search moves with the same score such as b and c in a different order than you generate them, whereas with my suggestion the order is stable.

BTW after a very quick test I see the following is faster (but still slower than mine, although not posible to speed compare correctly until functionality is different).

Code: Select all

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

Tested with g++ 4.4.0

Makes sense to eliminate the branch and always do the swap.

[Rein Halbersma]

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.

Just to name one Great Thing about D: compile-time function evaluation. This single feature makes life so much easier when creating tables, doing template programming and much more. It's a shame the build tools are not as mature as for C++, but I'd be sorely tempted to use it otherwise.