Stockfish 32-bit and hardware instructions on MSVC++

[vittyvirus]

I haven't done the slightest of editing:
BEFORE:...

End of your message is missing because too long

Yes, I'm not on my laptop right now. Would look to that later.

[vittyvirus]

Even if there is a small speed gain on MSVC 32-bit compiles, why should we patch SF for that ? Why should we uglify the source code with all this Microsoft shit ?

We don't care about gaining a tiny bit of performance on MSVC, especially for x86-32 (which died 10 years ago, in case you haven't heard of x86-64). All the production compiles are done with GCC (Linux, WIndows, Android) or Clang (MacOSX).

Truly you shouldn't.

[Sven]

Even if there is a small speed gain on MSVC 32-bit compiles, why should we patch SF for that ? Why should we uglify the source code with all this Microsoft shit ?

We don't care about gaining a tiny bit of performance on MSVC, especially for x86-32 (which died 10 years ago, in case you haven't heard of x86-64). All the production compiles are done with GCC (Linux, WIndows, Android) or Clang (MacOSX), because they're the fastest compilers.

Your "all this M*** sh*it" statement is fully inconsistent with the current contents of the Stockfish source code which (obviously by intent) has a lot of support for various platforms, including 32 bit, including "modern" and "not modern" systems, including even Windows 95 (platform.h, dwWin9xKludge)! I highly doubt that you are in the position to throw away that nice multi-platform support. (Ok, Win95 can certainly be debated but this is not the key point.) Even if the strategy to require all patches to be compatible with the "production" compile platforms is certainly very good this should not mean that all other compile platforms are "sh*t" and their support should be dropped. Otherwise you exclude a lot of people from the Stockfish world and from the set of possible contributors.

I suggest to accept multi-platform support as a normal thing of modern software development. And yes, M*** sh*t is certainly "sh*t" but please don't glorify GCC, it's some kind of "sh*t" as well ... difference being that it's open source, ok, but the world should be accepted as it is and at least the M*** sh*t has an IDE that is available for free and is widely used. Show me the corresponding IDE for GCC ... Note: I am a 99% command line guy but nevertheless I use VisualStudio!

As to readability of source code and use of #ifdef, I think Stockfish has a very good solution for it by isolating this kind of multi-platform code at very few places. The suggestion of Syed is just an improvement of one of these places where there is already some #ifdef present, so it would do zero harm to the code quality.

EDIT: That 32 bit platforms have "died 10 years ago" is really not true, not for chess programming and not for software development in general. For chess programming, 64 bit development environments have been available for many years but that does not mean that everyone has switched to 64 bit immediately. Look how many chess programmers are still working in the 32 bit world, and think about possible reasons. E.g. all those users of the "M*** sh*t" did not have 64 bit support with the free version until only very recently!
For SW development in general this is even more true, at least in large companies and/or large long-term projects since there you have huge costs for changes in the development environment (open source is being used less in such projects which would be worth another separate discussion of course) and often these changes are postponed until becoming really unavoidable.

[velmarin]

Even if there is a small speed gain on MSVC 32-bit compiles, why should we patch SF for that ? Why should we uglify the source code with all this Microsoft shit ?

We don't care about gaining a tiny bit of performance on MSVC, especially for x86-32 (which died 10 years ago, in case you haven't heard of x86-64). All the production compiles are done with GCC (Linux, WIndows, Android) or Clang (MacOSX), because they're the fastest compilers.

Jiji, you seem the owner,
We are all Stockfish, I also participated.
dirty mouth closed.

[vittyvirus]

Even if there is a small speed gain on MSVC 32-bit compiles, why should we patch SF for that ? Why should we uglify the source code with all this Microsoft shit ?

We don't care about gaining a tiny bit of performance on MSVC, especially for x86-32 (which died 10 years ago, in case you haven't heard of x86-64). All the production compiles are done with GCC (Linux, WIndows, Android) or Clang (MacOSX), because they're the fastest compilers.

Jiji, you seem the owner,
We are all Stockfish, I also participated.
dirty mouth closed.

I don't know why, sometimes I don't understand you and your message.

[cdani]

Even if there is a small speed gain on MSVC 32-bit compiles, why should we patch SF for that ? Why should we uglify the source code with all this Microsoft shit ?

We don't care about gaining a tiny bit of performance on MSVC, especially for x86-32 (which died 10 years ago, in case you haven't heard of x86-64). All the production compiles are done with GCC (Linux, WIndows, Android) or Clang (MacOSX), because they're the fastest compilers.

Jiji, you seem the owner,
We are all Stockfish, I also participated.
dirty mouth closed.

I don't know why, sometimes I don't understand you and your message.

He is spanish, and translates what he wants to say I think with google.

[vittyvirus]

Even if there is a small speed gain on MSVC 32-bit compiles, why should we patch SF for that ? Why should we uglify the source code with all this Microsoft shit ?

We don't care about gaining a tiny bit of performance on MSVC, especially for x86-32 (which died 10 years ago, in case you haven't heard of x86-64). All the production compiles are done with GCC (Linux, WIndows, Android) or Clang (MacOSX), because they're the fastest compilers.

Jiji, you seem the owner,
We are all Stockfish, I also participated.
dirty mouth closed.

Please change your avatar. Very annoying, doesn't suit a nicw guy like you.

[lucasart]

Even if there is a small speed gain on MSVC 32-bit compiles, why should we patch SF for that ? Why should we uglify the source code with all this Microsoft shit ?

We don't care about gaining a tiny bit of performance on MSVC, especially for x86-32 (which died 10 years ago, in case you haven't heard of x86-64). All the production compiles are done with GCC (Linux, WIndows, Android) or Clang (MacOSX), because they're the fastest compilers.

Your "all this M*** sh*it" statement is fully inconsistent with the current contents of the Stockfish source code which (obviously by intent) has a lot of support for various platforms, including 32 bit, including "modern" and "not modern" systems, including even Windows 95 (platform.h, dwWin9xKludge)! I highly doubt that you are in the position to throw away that nice multi-platform support. (Ok, Win95 can certainly be debated but this is not the key point.) Even if the strategy to require all patches to be compatible with the "production" compile platforms is certainly very good this should not mean that all other compile platforms are "sh*t" and their support should be dropped. Otherwise you exclude a lot of people from the Stockfish world and from the set of possible contributors.

I suggest to accept multi-platform support as a normal thing of modern software development. And yes, M*** sh*t is certainly "sh*t" but please don't glorify GCC, it's some kind of "sh*t" as well ... difference being that it's open source, ok, but the world should be accepted as it is and at least the M*** sh*t has an IDE that is available for free and is widely used. Show me the corresponding IDE for GCC ... Note: I am a 99% command line guy but nevertheless I use VisualStudio!

As to readability of source code and use of #ifdef, I think Stockfish has a very good solution for it by isolating this kind of multi-platform code at very few places. The suggestion of Syed is just an improvement of one of these places where there is already some #ifdef present, so it would do zero harm to the code quality.

EDIT: That 32 bit platforms have "died 10 years ago" is really not true, not for chess programming and not for software development in general. For chess programming, 64 bit development environments have been available for many years but that does not mean that everyone has switched to 64 bit immediately. Look how many chess programmers are still working in the 32 bit world, and think about possible reasons. E.g. all those users of the "M*** sh*t" did not have 64 bit support with the free version until only very recently!
For SW development in general this is even more true, at least in large companies and/or large long-term projects since there you have huge costs for changes in the development environment (open source is being used less in such projects which would be worth another separate discussion of course) and often these changes are postponed until becoming really unavoidable.

No need to get emotional, or to try generalizing the debate with off-topic discussions, it has no effect on conveying your argument.

Let me repeat myself in a way more clear to you:

FACT: we do not support hardware BSF/BSR on Win32 with MSVC: https://github.com/official-stockfish/S ... c/Makefile The targets for which we support it are x86-64, x86-64-modern, armv7.

FACT: we do not intend to, as pointed out by Joona here: https://github.com/official-stockfish/S ... issues/178

REASON: We try to support as many compilers as we can, but we do not intend to uglify the code to optimize for each and every compiler/platform under the sun (which involves piles of #ifdef and makefile cruft). x86-32 is NOT relevant today, especially with MSVC. If anything, we would be looking to optimize the x86-32 case for GCC, because the fastest binaries are produced by GCC, not MSVC. This has been done for ARMv7 (32-bit), because ARMv7 is relevant today.

[mar]

Calm down guys, I agree that 32-bit is no longer relevant for bitboard engines, as for ARMv7,
there are 64-bit ARM processors (v8-A if I'm not mistaken) out there already so I don't see how it's more relevant than x86.
OTOH I really don't understand why Microsoft doesn't support _BitScanForward64 in 32-bit mode because it really is just a couple of lines of code.
msc certainly has gone a long way from being shit (VC6) and in some rare cases it can outperform all other compilers (depends on what you do of course).
It also compiles very fast compared to gcc.
Bultins are compiler-specific and the only difference is they are called differently (I don't see how __builtin_ctz is nicer than _BitScanForward ).
As for SF supporting BSF on x86: I really don't care

[lucasart]

Calm down guys, I agree that 32-bit is no longer relevant for bitboard engines, as for ARMv7, there are 64-bit ARM processors (v8-A if I'm not mistaken) out there already

Yes, we should add an ARMv8 target in the makefile, that makes use of BSFQ/BSRQ (or whatever is equivalent there). Unfortunately, we have to resort to assembly, because GCC has no intrinsic for BSFQ/BSRQ that translates into efficient code (yes, I tried __builtin_ffsll(), looked at the assembly generated, and did some speed measures, it's crap).

I don't see how it's more relevant than x86.

ARMv7 is more relevant than x86, because the majority of phones and tablets still use it. OTOH, almost all PCs and Mac now are x86-64. I'm not talking about people who don't know what they're doing, and are running a 32-bit Windows with a 32-bit Microsoft compiler on a 64-bit machine.

OTOH I really don't understand why Microsoft doesn't support _BitScanForward64 in 32-bit mode because it really is just a couple of lines of code.

Indeed, a compiler intrinsic should always compile, and the compiler should decide how, based on the target platform (there should always be a default code when no efficient hardware instruction available). That's how it works on GCC and Clang, so it's clearly a Microsoft issue (hence Microsoft shit comment).

msc certainly has gone a long way from being shit (VC6) and in some rare cases it can outperform all other compilers (depends on what you do of course).

I don't know about rare cases, but I've never heard of an MSVC compile that beats GCC for SF.