Yes, I'm not on my laptop right now. Would look to that later.Vinvin wrote:End of your message is missing because too longvittyvirus wrote: I haven't done the slightest of editing:
BEFORE:...
Stockfish 32-bit and hardware instructions on MSVC++
Moderators: hgm, Rebel, chrisw
-
- Posts: 646
- Joined: Wed Jun 18, 2014 2:30 pm
- Full name: Fahad Syed
Re: Stockfish 32-bit and hardware instructions on MSVC++
-
- Posts: 646
- Joined: Wed Jun 18, 2014 2:30 pm
- Full name: Fahad Syed
Re: Stockfish 32-bit and hardware instructions on MSVC++
Truly you shouldn't.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).
-
- Posts: 4052
- Joined: Thu May 15, 2008 9:57 pm
- Location: Berlin, Germany
- Full name: Sven Schüle
Re: Stockfish 32-bit and hardware instructions on MSVC++
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.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.
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.
-
- Posts: 1600
- Joined: Mon Feb 21, 2011 9:48 am
Re: Stockfish 32-bit and hardware instructions on MSVC++
Jiji, you seem the owner,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.
We are all Stockfish, I also participated.
dirty mouth closed.
-
- Posts: 646
- Joined: Wed Jun 18, 2014 2:30 pm
- Full name: Fahad Syed
Re: Stockfish 32-bit and hardware instructions on MSVC++
I don't know why, sometimes I don't understand you and your message.velmarin wrote:Jiji, you seem the owner,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.
We are all Stockfish, I also participated.
dirty mouth closed.
-
- Posts: 2204
- Joined: Sat Jan 18, 2014 10:24 am
- Location: Andorra
Re: Stockfish 32-bit and hardware instructions on MSVC++
He is spanish, and translates what he wants to say I think with google.vittyvirus wrote:I don't know why, sometimes I don't understand you and your message.velmarin wrote:Jiji, you seem the owner,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.
We are all Stockfish, I also participated.
dirty mouth closed.
Daniel José - http://www.andscacs.com
-
- Posts: 646
- Joined: Wed Jun 18, 2014 2:30 pm
- Full name: Fahad Syed
Re: Stockfish 32-bit and hardware instructions on MSVC++
Please change your avatar. Very annoying, doesn't suit a nicw guy like you.velmarin wrote:Jiji, you seem the owner,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.
We are all Stockfish, I also participated.
dirty mouth closed.
-
- Posts: 3232
- Joined: Mon May 31, 2010 1:29 pm
- Full name: lucasart
Re: Stockfish 32-bit and hardware instructions on MSVC++
No need to get emotional, or to try generalizing the debate with off-topic discussions, it has no effect on conveying your argument.Sven Schüle wrote: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.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.
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.
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.
-
- Posts: 2568
- Joined: Fri Nov 26, 2010 2:00 pm
- Location: Czech Republic
- Full name: Martin Sedlak
Re: Stockfish 32-bit and hardware instructions on MSVC++
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
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
-
- Posts: 3232
- Joined: Mon May 31, 2010 1:29 pm
- Full name: lucasart
Re: Stockfish 32-bit and hardware instructions on MSVC++
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).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
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.I don't see how it's more relevant than x86.
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).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.
I don't know about rare cases, but I've never heard of an MSVC compile that beats GCC for SF.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).
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.