connor_mcmonigle wrote: ↑Sat Dec 04, 2021 10:11 am
Also, while constexpr and consteval are certainly powerful features, any self respecting C compiler will perform constant propagation which covers the majority of the cases where such features might be practically useful in a chess engine.
Is an array a constant? In C the thing instantly decays to a pointer where even perfect C compilers wouldnt know what is constant and what is variable.
Im not even bringing up templates because no one writes 1024 functions by hand just because one type changed.. and that costs runtime performance.
Macros exist. They are shit but they exist.
Same goes for you. Go and write a letter to the standard comittee how your 5 line project compiles down to the same assembly and how you think they invented all the features for no reason. These things are there to help the compiler out: WHEN ITS NOT SO CLEAR.
Like it is for any codebase that has a few thousand lines of code. That includes most chess engines also.
Thats why I am suprised that a C translation of Stockfish would be faster. Which it isnt because as you can lookup in the commit history - they stripped out a lot of old code and replaced it with faster C equivalents of that.
And count how many of these features have performance implications that are missing in C. Your argument bares no basis. Im an done arguing with the riff-raff here.
connor_mcmonigle wrote: ↑Sat Dec 04, 2021 10:11 am
Also, while constexpr and consteval are certainly powerful features, any self respecting C compiler will perform constant propagation which covers the majority of the cases where such features might be practically useful in a chess engine.
Is an array a constant? In C the thing instantly decays to a pointer where even perfect C compilers wouldnt know what is constant and what is variable.
AndrewGrant wrote: ↑Sat Dec 04, 2021 11:43 pm
Done arguing? You've not even started yet. You just hand-wave everything that is pointed out.
Your 5 lines of code do not prove that C++ compilers produce slower code - or even the same code.
In fact it is so ridiculous to think that - that I am done discussing.
Be happy how your 10 minute thinking shows how an entire industry relies on keywords and features that you think are useless. Its wrong. But if you think you are right maybe you are happy.
Go and read the documentation and then come back. Before that your half knowledge is just annoying.
And again you fail to acknowledge that you were wrong about references being "faster" than pointers.
There are certainly cases where constexpr/consteval and templates are useful and more capable than constant propagation, but what you've failed to demonstrate is the practical relevance of those cases to programming a chess engine. As has been demonstrated to you, modern C compilers are very capable when it comes to constant propagation and are even able to perform complex reductions on arrays at compile time. What more complicated compile time operations does C++ enable which would be practically relevant to chess engine development?
connor_mcmonigle wrote: ↑Sun Dec 05, 2021 12:18 am
And again you fail to acknowledge that you were wrong about references being "faster" than pointers.
There are certainly cases where constexpr/consteval and templates are useful and more capable than constant propagation, but what you've failed to demonstrate is the practical relevance of those cases to programming a chess engine. As has been demonstrated to you, modern C compilers are very capable when it comes to constant propagation and are even able to perform complex reductions on arrays at compile time. What more complicated compile time operations does C++ enable which would be practically relevant to chess engine development?
Runtime [[likely]] for example. Will tell the compiler where to put the first jmpneq for better performance. Does not exist in C.
Not more is needed since that will bring a lot of performance.
Its also the very easy stuff since a lot of you make engines with pawns[color] which is infinitely slower than a constexpr version which is described in my signature. Color is the thing that is switching between black and white all the time if you didnt know that by now. If you use an integer that is 0..1 the compiler wont do constant folding on a non constant.
You will have a table lookup and with C and the compiler cant inline more for you.
You will have a constant in C++ and color compiles away with templates into a nothingness and the C++ compiler can do constant folding for each color.
dangi12012 wrote: ↑Sun Dec 05, 2021 12:33 amRuntime [[likely]] for example.
That's available as builtin with GCC and Clang - and it has to be used with much care because in basically everything other than total corner cases, it actually costs performance. Sure, it's not there with MSVC, but its C support is anaemic anyway so that you can't even use "restrict" on pointers.
dangi12012 wrote: ↑Sun Dec 05, 2021 12:33 amRuntime [[likely]] for example.
That's available as builtin with GCC and Clang - and it has to be used with much care because in basically everything other than total corner cases, it actually costs performance. Sure, it's not there with MSVC, but its C support is anaemic anyway so that you can't even use "restrict" on pointers.
Oh you mean its a non portable compiler extension and not a part of the language? Thank you for proving my point.
Its part of C++. Its not part of C.
There are about 20 competent people on this forum I can respect.
The rest is worse than 16 year old ticktockers that want to tell me how programming works.
To even start arguing how every keyword in C++ is so useless for chess and for best performance to use C code is just laughable.
dangi12012 wrote: ↑Sun Dec 05, 2021 12:33 amRuntime [[likely]] for example.
That's available as builtin with GCC and Clang - and it has to be used with much care because in basically everything other than total corner cases, it actually costs performance. Sure, it's not there with MSVC, but its C support is anaemic anyway so that you can't even use "restrict" on pointers.
Oh you mean its a non portable compiler extension and not a part of the language? Thank you for proving my point.
Its part of C++. Its not part of C.
There are about 20 competent people on this forum I can respect.
The rest is worse than 16 year old ticktockers that want to tell me how programming works.
To even start arguing how every keyword in C++ is so useless for chess and for best performance to use C code is just laughable.
Sounds like you might love the fact that C has "restrict" while C++ doesn't then.
dangi12012 wrote:No one wants to touch anything you have posted. That proves you now have negative reputations since everyone knows already you are a forum troll.
Maybe you copied your stockfish commits from someone else too?
I will look into that.
dangi12012 wrote: ↑Sun Dec 05, 2021 12:58 amThank you for proving my point.
It seems you didn't understand the point that this is only useful for total corner cases, basically error conditions that are not expected to happen at all. We're still taking about chess programming. Like, engines.
dangi12012 wrote: ↑Sat Dec 04, 2021 11:38 pm
Same goes for you. Go and write a letter to the standard comittee how your 5 line project compiles down to the same assembly and how you think they invented all the features for no reason.
Maybe you should do that? I think the C++ additions are very good for code readability and maintainability. Do you not see that?
dangi12012 wrote:No one wants to touch anything you have posted. That proves you now have negative reputations since everyone knows already you are a forum troll.
Maybe you copied your stockfish commits from someone else too?
I will look into that.
