R. Tomasi wrote: ↑Thu Sep 02, 2021 5:06 pm
I second that. In my experience modern compilers are very very good at optimizing and the more you stick to recommended design patterns, the better it will understand your code and do it's job. Granted, on rare occasions you can do "ugly" code that performs better than "pretty" code, but usually that is then tied to one particular platform and one particular compiler.
Ok I just reviewed your engine (thanks for releasing the sources), and your sort method looks like this:
R. Tomasi wrote: ↑Thu Sep 02, 2021 5:06 pm
I second that. In my experience modern compilers are very very good at optimizing and the more you stick to recommended design patterns, the better it will understand your code and do it's job. Granted, on rare occasions you can do "ugly" code that performs better than "pretty" code, but usually that is then tied to one particular platform and one particular compiler.
Ok I just reviewed your engine (thanks for releasing the sources), and your sort method looks like this:
This exactly proves my point: Even in C++, the fastest possible code is not always pretty.
The "ugly" part is the SSE2/AVX2 specific code, the rest is pretty much straight-forward and readable code. So it does not prove anything about your point at all, it's just an example of what I said: you can have ugly code that performs better, but it's going to be for some special case.
R. Tomasi wrote: ↑Tue Sep 14, 2021 4:05 pm
The "ugly" part is the SSE2/AVX2 specific code, the rest is pretty much straight-forward and readable code. So it does not prove anything about your point at all, it's just an example of what I said: you can have ugly code that performs better, but it's going to be for some special case.
Well, that's circular reasoning.
And how on earth is this readable? With all due respect for what you did here (the sorting is pretty cool and something I'll try out myself), in my expert highly-sought-after opinion, this is about as far from readable as it gets. If this is readable, then I'd like for Mergi to explain why the two files below, which are largely identical, need to be ~1000 lines of verbose C++ code each. How does one even work with code like this?
R. Tomasi wrote: ↑Tue Sep 14, 2021 4:05 pm
The "ugly" part is the SSE2/AVX2 specific code, the rest is pretty much straight-forward and readable code. So it does not prove anything about your point at all, it's just an example of what I said: you can have ugly code that performs better, but it's going to be for some special case.
Well, that's circular reasoning.
And how on earth is this readable? With all due respect for what you did here (the sorting is pretty cool and something I'll try out myself), in my expert highly-sought-after opinion, this is about as far from readable as it gets. If this is readable, then I'd like for Mergi to explain why the two files below, which are largely identical, need to be ~1000 lines of verbose C++ code each. How does one even work with code like this?
With all due respect... you have spammed this board with such an amount of BS, that I consider any attempt to engage in fruitful conversation with you a waste of my time.
R. Tomasi wrote: ↑Tue Sep 14, 2021 4:29 pm
With all due respect... you have spammed this board with such an amount of BS, that I consider any attempt to engage in fruitful conversation with you a waste of my time.
Ok, fine. Mergi and I will discuss your code. Mergi?
[Moderation warning] This signature violated the rule against commercial exhortations.
R. Tomasi wrote: ↑Tue Sep 14, 2021 4:05 pm
The "ugly" part is the SSE2/AVX2 specific code, the rest is pretty much straight-forward and readable code. So it does not prove anything about your point at all, it's just an example of what I said: you can have ugly code that performs better, but it's going to be for some special case.
Well, that's circular reasoning.
And how on earth is this readable? With all due respect for what you did here (the sorting is pretty cool and something I'll try out myself), in my expert highly-sought-after opinion, this is about as far from readable as it gets. If this is readable, then I'd like for Mergi to explain why the two files below, which are largely identical, need to be ~1000 lines of verbose C++ code each. How does one even work with code like this?
With all due respect... you have spammed this board with such an amount of BS, that I consider any attempt to engage in fruitful conversation with you a waste of my time.
tbh he's not completely wrong, repeating code is not a good sign.
if you're interested in C++20 they added a <bit> header which provides those functions. (if compiled with -march=native and -O3 they compile to their respective assembly instruction) https://en.cppreference.com/w/cpp/header/bit
klx wrote: ↑Tue Sep 14, 2021 4:56 pm
Ok, fine. Mergi and I will discuss your code. Mergi?
Sir, imma be honest, i don't understand much of the source code. I'm not a big fan of such verbose coding style, and there's too much deep if branching for me to follow. When code is more than 2 ifs deep, my brain turns off. I like small, compact functions just like uncle Bob does (great series of lectures on youtube btw). But that doesn't really say anything about C++.
R. Tomasi wrote: ↑Tue Sep 14, 2021 4:05 pm
The "ugly" part is the SSE2/AVX2 specific code, the rest is pretty much straight-forward and readable code. So it does not prove anything about your point at all, it's just an example of what I said: you can have ugly code that performs better, but it's going to be for some special case.
Well, that's circular reasoning.
And how on earth is this readable? With all due respect for what you did here (the sorting is pretty cool and something I'll try out myself), in my expert highly-sought-after opinion, this is about as far from readable as it gets. If this is readable, then I'd like for Mergi to explain why the two files below, which are largely identical, need to be ~1000 lines of verbose C++ code each. How does one even work with code like this?
With all due respect... you have spammed this board with such an amount of BS, that I consider any attempt to engage in fruitful conversation with you a waste of my time.
tbh he's not completely wrong, repeating code is not a good sign.
if you're interested in C++20 they added a <bit> header which provides those functions. (if compiled with -march=native and -O3 they compile to their respective assembly instruction) https://en.cppreference.com/w/cpp/header/bit
I deliberately do not want any dependency on C++20 in that project. But the real reason these classes are so convoluted (and I totally agree, that they are) is that they are tailored specifically to support the uint_t template, which abtracts many things away. I certainly had my reasons to do it the way I did and it helps a lot in keeping the actual engine code - which isn't limited to chess - clean and readable. Winning any kind of beauty contest was not a design goal here.
klx wrote: ↑Tue Sep 14, 2021 4:56 pm
Ok, fine. Mergi and I will discuss your code. Mergi?
Sir, imma be honest, i don't understand much of the source code. I'm not a big fan of such verbose coding style, and there's too much deep if branching for me to follow. When code is more than 2 ifs deep, my brain turns off. I like small, compact functions just like uncle Bob does (great series of lectures on youtube btw). But that doesn't really say anything about C++.
Your candor is appreciated and welcome. Mind you, the branches are constexpr branches, so the actual bits generated by the compiler do not branch so much. Indeed one could have achieved the same results using lots of template magic, but I somehow doubt that would have made it in any way more readable.
Edit: In any case, I welcome the discussion anout my source code, however I suggest we move that to the thread about the Pygmalion sources, in order to not hijack OPs thread - which still is about C# vs C++. Not sure my source code really proves any point when it comes to that topic...
Seems like all other threads eventually have an off-topic discussion about C# vs C++ but the only thread where this discussion would be on-topic derails into something else.
(btw, I'm still interested in comparing apples with apples regarding the speed of C# vs C++ but I'll make a dedicated thread about that in due time.)
Minimal Chess (simple, open source, C#) - Youtube & Github Leorik (competitive, in active development, C#) - Github & Lichess
When code is more than 2 ifs deep, my brain turns off. 
I like small, compact functions just like uncle Bob does (great series of lectures on youtube btw). But that doesn't really say anything about C++.
