Programming language choice, why C\C++ ?

[D Sceviour]

For instance, if your move generator returns a std::list<Move>, I expect your engine will be very slow.

I create the move list memory on the stack for each search ply. Would allocating a global move list memory be any faster?

[mar]

I am still wondering why people stick to C or C++.

Because it's very difficult to convince C++ programmers to switch (and actually there's no reason to).
Would you switch from D to Rust? I guess not.

If you don't care about portability - good for you, but some people do.

[AlvaroBegue]

For instance, if your move generator returns a std::list<Move>, I expect your engine will be very slow.

I create the move list memory on the stack for each search ply. Would allocating a global move list memory be any faster?

It depends on what you mean by "list". If it really is std::list, it's probably going to be bad, whether it's a single global list or many local ones. Using arrays or std::vector will be much faster.

The traditional technique to handle moves is to have a single global array and start using the part that your ancestors are not using. But having local arrays of size 256 on the stack is fast enough that I don't bother. I doubt it will make much of a difference.

[abulmo2]

Because it's very difficult to convince C++ programmers to switch (and actually there's no reason to).

Yet, there are many reasons to quit C++
https://www.youtube.com/watch?v=48kP_Ssg2eY

Would you switch from D to Rust? I guess not.

From C++ to Rust ? yes, I will

[mar]

Kid stuff
Speaking outside of super-tiny projects like chess engines, GC is for idiots.

[jdart]

The JVM based languages such as Java, Go are not faster. They have the overhead of runtime bounds checking and GC. They are fast enough for many purposes, but top-performing chess programs tend to have very high performance requirements.

As for portability maybe you are not aware of this but many of us aren't on Windows. I have a couple of Windows boxes, but 5 Linux machines. And then there is Mac. And Android (non-x86).

--Jon

[Ras]

Short answer: C is the best portable macro assembler ever.

You are right that algorithmic optimisations are supreme; but these are implemented in C/C++ engines as well.

For me, portability was the key issue to get an engine over from a PC to a microcontroller that has 192 kb (KILO!) RAM and 1 MB ROM. Even C++ would have failed here; while you can use C++ embedded, this comes with severe restrictions which authors of existing PC engines simply have no reason to accept.

A fun aspect here is that chess originally was an important prestige project in the early AI hype. LISP was specifically advertised to solve AI problems, back then. Well, we have chess engines that play better than any human, but they are not in LISP. Mostly because it turned out that AI is not necessary for chess, computing does the job.

The funny thing here is that it's rudimentary toy engines which are implemented in LISP. Seems that even LISP hackers failed to actually deliver a competetive chess engine in their language of choice.

[Dann Corbit]

Bottom line:

1. Every language that compiles to native machine code will be nice and fast (like C and Fortran).

2. Every language that compiles to a virtual machine (like Java and dotnet) will be a little less fast.

3. C and C++ are both very popular, so lots of people can help you and there are lots of tools.

4. Assembly is fastest of all in the hands of a true expert. In anyone else's hands, it's a hot mess.

Now, if you are very familiar with some particular language and you want to write a chess program in that language, go ahead and do it.

As for which one is truly best, it's like asking which operating system is best. You will get a bunch of disciple manifestos about why choice 'X' is the best possible and all other choices are not so good as 'X'.

[abulmo2]

The JVM based languages such as Java, Go are not faster.

gcj and gcc-go are part of the gnu compiler collection and produce native code, with the same optimizations of gcc/g++, one of the best c/c++ compiler.

They have the overhead of runtime bounds checking and GC.

runtime bound checkings can be disabled. GC is not a problem. Memory allocation is the problem. Whatever you use malloc/free or a GC, the speed is usually the same. And the best is of course to avoid to allocate/free memory as much as possible.

They are fast enough for many purposes, but top-performing chess programs tend to have very high performance requirements.

My guess is that you can make a very strong and fast engine in any of the language I quoted.

As for portability maybe you are not aware of this but many of us aren't on Windows. I have a couple of Windows boxes, but 5 Linux machines. And then there is Mac. And Android (non-x86).

You can count me as one of them. My argument is that portability as nothing to do with using C or C++:
1) Other languages are portable too.
2) Some strong engines developed in C or C++ run only under windows: Houdini, fizbo, Fritz, etc.
3) In C or C++, a chess engine has some parts tied to the OS (time-management, non blocking input and multithreading), so writing a portable code in C or C++ usually needs wrapper around some OS-dedicated library functions. Otherwise said, C or C++ chess engines are not primarily portable and need some adjustments to be.




--Jon[/quote]

[AlvaroBegue]

3) In C or C++, a chess engine has some parts tied to the OS (time-management, non blocking input and multithreading), so writing a portable code in C or C++ usually needs wrapper around some OS-dedicated library functions. Otherwise said, C or C++ chess engines are not primarily portable and need some adjustments to be.

You can write a portable engine in modern C++. Since C++11, you have high-resolution time functions and multi-threading support. Non-blocking input might not be really necessary if you have a dedicated thread to read input.