Stockfish 32-bit and hardware instructions on MSVC++

Discussion of anything and everything relating to chess playing software and machines.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
vittyvirus
Posts: 646
Joined: Wed Jun 18, 2014 12:30 pm
Full name: Fahad Syed

Re: Stockfish 32-bit and hardware instructions on MSVC++

Post by vittyvirus » Wed Dec 31, 2014 1:19 pm

Vinvin wrote:
vittyvirus wrote: 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.

User avatar
vittyvirus
Posts: 646
Joined: Wed Jun 18, 2014 12:30 pm
Full name: Fahad Syed

Re: Stockfish 32-bit and hardware instructions on MSVC++

Post by vittyvirus » Wed Dec 31, 2014 1:21 pm

lucasart wrote: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. :lol: :lol:

Sven
Posts: 3868
Joined: Thu May 15, 2008 7:57 pm
Location: Berlin, Germany
Full name: Sven Schüle
Contact:

Re: Stockfish 32-bit and hardware instructions on MSVC++

Post by Sven » Wed Dec 31, 2014 2:50 pm

lucasart wrote: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.

User avatar
velmarin
Posts: 1600
Joined: Mon Feb 21, 2011 8:48 am

Re: Stockfish 32-bit and hardware instructions on MSVC++

Post by velmarin » Wed Dec 31, 2014 3:05 pm

lucasart wrote: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.
:evil: :evil: :evil: :evil: :evil:

User avatar
vittyvirus
Posts: 646
Joined: Wed Jun 18, 2014 12:30 pm
Full name: Fahad Syed

Re: Stockfish 32-bit and hardware instructions on MSVC++

Post by vittyvirus » Wed Dec 31, 2014 5:09 pm

velmarin wrote:
lucasart wrote: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.
:evil: :evil: :evil: :evil: :evil:
I don't know why, sometimes I don't understand you and your message.

User avatar
cdani
Posts: 2166
Joined: Sat Jan 18, 2014 9:24 am
Location: Andorra
Contact:

Re: Stockfish 32-bit and hardware instructions on MSVC++

Post by cdani » Wed Dec 31, 2014 6:37 pm

vittyvirus wrote:
velmarin wrote:
lucasart wrote: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.
:evil: :evil: :evil: :evil: :evil:
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.

User avatar
vittyvirus
Posts: 646
Joined: Wed Jun 18, 2014 12:30 pm
Full name: Fahad Syed

Re: Stockfish 32-bit and hardware instructions on MSVC++

Post by vittyvirus » Wed Dec 31, 2014 6:52 pm

velmarin wrote:
lucasart wrote: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.
:evil: :evil: :evil: :evil: :evil:
Please change your avatar. Very annoying, doesn't suit a nicw guy like you.

User avatar
lucasart
Posts: 3110
Joined: Mon May 31, 2010 11:29 am
Full name: lucasart
Contact:

Re: Stockfish 32-bit and hardware instructions on MSVC++

Post by lucasart » Thu Jan 01, 2015 12:09 am

Sven Schüle wrote:
lucasart wrote: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.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.

mar
Posts: 2122
Joined: Fri Nov 26, 2010 1:00 pm
Location: Czech Republic
Full name: Martin Sedlak

Re: Stockfish 32-bit and hardware instructions on MSVC++

Post by mar » Thu Jan 01, 2015 12:39 am

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 :)

User avatar
lucasart
Posts: 3110
Joined: Mon May 31, 2010 11:29 am
Full name: lucasart
Contact:

Re: Stockfish 32-bit and hardware instructions on MSVC++

Post by lucasart » Thu Jan 01, 2015 2:20 am

mar wrote: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.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.

Post Reply