c vs c++

[SuneF]

For chess, Java is a poor choice if you want performance. It does not have the low level support you need. It's also a memory pig but there may be ways to work around that. For many types of applications it is not much slower than C or C++ but for the low level bit-twiddling attention to detail and memory management you need for a really high performance chess program, it's a terrible choice.

If you want a pretty good chess program (but not great program) that is portable, then it's probably a reasonable choice.

I honestly don't think C is that portable. It you stick with some specific dialect of C such as ansii C it is portable, but in a real world program you cannot do that. You still have to deal with platform differences in the real world.

My code is peppered with #ifdef's to deal with difference between compilers and platforms and it's annoying.

My experience is that Java really is much more portable. I do not know if this applies to the hand-held devices which use subsets or variations of java.

Right Don, exactly.

Just one note.
What I was trying to convey was that if you want to learn a new language and chess is just a means to that end, then I'd not recommend C or C++. Granted these languages excel in small performance demanding codes but are, IMHO, not good for much else. You might as well be writing in Fortran.

[Don]

For chess, Java is a poor choice if you want performance. It does not have the low level support you need. It's also a memory pig but there may be ways to work around that. For many types of applications it is not much slower than C or C++ but for the low level bit-twiddling attention to detail and memory management you need for a really high performance chess program, it's a terrible choice.

If you want a pretty good chess program (but not great program) that is portable, then it's probably a reasonable choice.

I honestly don't think C is that portable. It you stick with some specific dialect of C such as ansii C it is portable, but in a real world program you cannot do that. You still have to deal with platform differences in the real world.

My code is peppered with #ifdef's to deal with difference between compilers and platforms and it's annoying.

My experience is that Java really is much more portable. I do not know if this applies to the hand-held devices which use subsets or variations of java.

Right Don, exactly.

Just one note.
What I was trying to convey was that if you want to learn a new language and chess is just a means to that end, then I'd not recommend C or C++. Granted these languages excel in small performance demanding codes but are, IMHO, not good for much else. You might as well be writing in Fortran.

I agree with that. It takes a huge amount of ambition to learn C AND write a chess program. Writing a chess program is skill not many people possess, but an enthusiastic individual with some programming talent (and/or dogged perseverance) can learn to do it.

[tpetzke]

Hi,

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

The original question was somehow not what language gives you the fastest executable anyway ... Is it not more what language gets you to a chess program fastest and I just don't believe the correct answer to that is C.

Thomas...

[Don]

Hi,

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

The original question was somehow not what language gives you the fastest executable anyway ... Is it not more what language gets you to a chess program fastest and I just don't believe the correct answer to that is C.

Thomas...

The correct answer to that is Ruby. Ruby will also probably give you the slowest program

[rbarreira]

Hi,

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

The original question was somehow not what language gives you the fastest executable anyway ... Is it not more what language gets you to a chess program fastest and I just don't believe the correct answer to that is C.

Thomas...

Why would the thread author talk about converting Stockfish to C if the purpose was what you're assuming...

It was pretty clear that this is about performance.

For chess, Java is a poor choice if you want performance. It does not have the low level support you need. It's also a memory pig but there may be ways to work around that. For many types of applications it is not much slower than C or C++ but for the low level bit-twiddling attention to detail and memory management you need for a really high performance chess program, it's a terrible choice.

If you want a pretty good chess program (but not great program) that is portable, then it's probably a reasonable choice.

I honestly don't think C is that portable. It you stick with some specific dialect of C such as ansii C it is portable, but in a real world program you cannot do that. You still have to deal with platform differences in the real world.

My code is peppered with #ifdef's to deal with difference between compilers and platforms and it's annoying.

My experience is that Java really is much more portable. I do not know if this applies to the hand-held devices which use subsets or variations of java.

Right Don, exactly.

Just one note.
What I was trying to convey was that if you want to learn a new language and chess is just a means to that end, then I'd not recommend C or C++. Granted these languages excel in small performance demanding codes but are, IMHO, not good for much else. You might as well be writing in Fortran.

I agree with that. It takes a huge amount of ambition to learn C AND write a chess program. Writing a chess program is skill not many people possess, but an enthusiastic individual with some programming talent (and/or dogged perseverance) can learn to do it.

That's obvious... you start with a Hello World when learning a new language, not a complex program with hundreds or thousand of lines.

As for the other thing he said:

these languages excel in small performance demanding codes but are, IMHO, not good for much else

This I don't think many would agree, since there are tons of big programs made in C/C++... such as the Linux kernel, GUIs, games, development environments, compilers and tons of other popular programs.

[ethanara]

I was talking 100% about exe performance
I did read in a java book that in some tasks java would be faster than c++
If you will i give you example and execution time.
Do you guys think java would be faster than c c++ in a chess engine?
Or would it be faster to make a multi-language like c java chess engine?
Bye
Ethan Ara

[Evert]

I did read in a java book that in some tasks java would be faster than c++

Only in specific circumstances.

Do you guys think java would be faster than c c++ in a chess engine?

Hell no.

Or would it be faster to make a multi-language like c java chess engine?

If you do the time-critical tasks in C rather than Java, very probably. On the other hand, I'd just do the whole thing in C...

The question is though whether speed of the compiler/language is going to be the bottleneck for your chess program. Chances are that if this is your first attempt, it will not be. In which case, don't worry about it.
It is more important to use efficient algorithms.

[michiguel]

For chess, Java is a poor choice if you want performance. It does not have the low level support you need. It's also a memory pig but there may be ways to work around that. For many types of applications it is not much slower than C or C++ but for the low level bit-twiddling attention to detail and memory management you need for a really high performance chess program, it's a terrible choice.

If you want a pretty good chess program (but not great program) that is portable, then it's probably a reasonable choice.

I honestly don't think C is that portable. It you stick with some specific dialect of C such as ansii C it is portable, but in a real world program you cannot do that. You still have to deal with platform differences in the real world.

My code is peppered with #ifdef's to deal with difference between compilers and platforms and it's annoying.

My experience is that Java really is much more portable. I do not know if this applies to the hand-held devices which use subsets or variations of java.

Right Don, exactly.

Just one note.
What I was trying to convey was that if you want to learn a new language and chess is just a means to that end, then I'd not recommend C or C++. Granted these languages excel in small performance demanding codes but are, IMHO, not good for much else. You might as well be writing in Fortran.

I agree with that. It takes a huge amount of ambition to learn C AND write a chess program. Writing a chess program is skill not many people possess, but an enthusiastic individual with some programming talent (and/or dogged perseverance) can learn to do it.

I wrote an engine just to learn C.
Uri Blass learned C, just to write an engine.

It is doable. A chess engine is a very algorithmic type of project, and the simplicity of C suits it well.

I never had problems with portability issues. Gaviota is multithreaded and compiles in Windows, Linux, Android etc. w/o problems. I have wrappers for a handful of posix functions and their equivalents in windows and all of them are in one (not very big) file.
https://github.com/michiguel/Gaviota-Ta ... /sysport.c

I think that the important thing, if portability is an issue, is not to use features that are too specific and not needed. If you _really_ need something too specific, like something in assembler, then I guess no language will support that type of portability anyway.

Miguel

[Don]

For chess, Java is a poor choice if you want performance. It does not have the low level support you need. It's also a memory pig but there may be ways to work around that. For many types of applications it is not much slower than C or C++ but for the low level bit-twiddling attention to detail and memory management you need for a really high performance chess program, it's a terrible choice.

If you want a pretty good chess program (but not great program) that is portable, then it's probably a reasonable choice.

I honestly don't think C is that portable. It you stick with some specific dialect of C such as ansii C it is portable, but in a real world program you cannot do that. You still have to deal with platform differences in the real world.

My code is peppered with #ifdef's to deal with difference between compilers and platforms and it's annoying.

My experience is that Java really is much more portable. I do not know if this applies to the hand-held devices which use subsets or variations of java.

Right Don, exactly.

Just one note.
What I was trying to convey was that if you want to learn a new language and chess is just a means to that end, then I'd not recommend C or C++. Granted these languages excel in small performance demanding codes but are, IMHO, not good for much else. You might as well be writing in Fortran.

I agree with that. It takes a huge amount of ambition to learn C AND write a chess program. Writing a chess program is skill not many people possess, but an enthusiastic individual with some programming talent (and/or dogged perseverance) can learn to do it.

I wrote an engine just to learn C.
Uri Blass learned C, just to write an engine.

It is doable. A chess engine is a very algorithmic type of project, and the simplicity of C suits it well.

I never had problems with portability issues. Gaviota is multithreaded and compiles in Windows, Linux, Android etc. w/o problems. I have wrappers for a handful of posix functions and their equivalents in windows and all of them are in one (not very big) file.
https://github.com/michiguel/Gaviota-Ta ... /sysport.c

Organizing the non-portable parts of the code does not make the code portable. You still have to have version of the same routines for various compilers and platforms. However the way you organized it definitively is neater and makes life simpler.

C IS in fact relatively portable, just not nearly as much as java. You can write a great deal of the code and it will run the same.

However, can you write a portable C routine that attaches to a process and allows you to write to it's input and read it's output? No. Way too many differences. But you CAN do this is java and many other high level languages.

I think that the important thing, if portability is an issue, is not to use features that are too specific and not needed. If you _really_ need something too specific, like something in assembler, then I guess no language will support that type of portability anyway.

Yes, this is good advice. I hate it when people use some platform specific library gratuitously just because they like it or to save a small amount of effort (by ignoring windows for instance if it's an Linux application.)

Miguel

[bob]

Are you sure about that? It's a templated inline function in a header file...

I am using mingw gcc, I will check better though.

Anyhow this is a fast speed test on my slow 32bit Core Duo T5250

./stockfish bench > /dev/null


SF dev version: 6836674 nodes searched, 408232 nodes/sec

Rein version: 6696967 nodes searched, 403504 nodes/sec

If your version is faster, maybe it doesn't really matter much why. std::max_element might be handy when trying to do some high-level algorithmic thing, but for what you're doing who cares if its 1 line of code or your hand-rolled 3 lines of code? Rather than trust that every compiler's implementation of std::max_element is efficient for your use case, you should just keep your code the way it is.

But if you're interested in figuring it out... maybe you could put those two snippets in their own source file, and generate an assembly listing and post it here? Maybe there will be something obvious about the code generated.

That looks like noise to me. Could be explained by:

(1) program gets loaded into a different set of physical pages each time it is run. Some "sets" of pages spread the load evenly over cache, which is normally good, but not always. Some "sets" of pages spread the load unevenly, but by luck spread the critical parts evenly to minimize cache thrashing. And of course some "sets" of pages have excessive aliasing so that parts of cache are unused, effectively reducing the size of cache for that run.

(2) changing something in a binary shifts memory addresses around. I have had cases in Crafty where I added code and sped it up. And where I deleted code and slowed it down. Never by huge amounts, but by measurable amounts.

Measuring NPS to such a small resolution (<1% if I calculated correctly) is always problematic... It doesn't take much to perturb results on X86 and see speed changes that are pure random effects.