search

official-stockfish / Stockfish

A free and strong UCI chess engine
https://stockfishchess.org/
GNU General Public License v3.0
11.33k stars 2.25k forks source link

It's time to stop supporting 32 bit SF #3435

Closed NightlyKing closed 3 years ago

NightlyKing commented 3 years ago

I would say it is time to strip the 32 bit support with next release. The reasons are pretty obvious:

BM123499 commented 3 years ago

With a quick search, I found out 3 main difference in 32 bit to 64 bit:

My opinion is to leave 32bit as it is. Not optimizing nor removing it. Just leave it be. It has what? 10 lines of code optimized for 32bits? (not considering Makefile)

ddobbelaere commented 3 years ago

Please don't just stop supporting 32 bit for the sake it. Give it maybe lower priority in optimizations if desired (e.g. if this leads to cleaner code like in magics code), but don't just drop it!

You would be amazed how many (mostly embedded) systems are 32 bit, e.g. Raspberry Pi (first gen and current low power Zero W), Microblaze on FPGA can be set to 32 bit if desired (e.g. to save resources).

You are citing Ubuntu, but fail to mention that its ancestor Debian from which it is derived supports x86 32 bit in its latest release (buster, supported till 2024), and there are no signs that they will drop it in next stable release (bullseye, supported till 2026). Also the Linux kernel will continue to support x86/Microblaze32/Armv7... in decades to come, 32 bit isn't going away anytime soon, see https://lwn.net/Articles/838807/:

...and 32-bit Linux kernels will only be needed for supporting existing users. New board designs are likely to appear for five to ten years after the last Armv7 chip has been created, but after that it can take another decade before the remaining users finally stop upgrading their kernels or replace their hardware

Sopel97 commented 3 years ago

Let's be real, how many actual users are limited to 32 bit systems? And how many of them care about their engine being absolute strongest?

We could use some surveys from time to time...

NightlyKing commented 3 years ago

I don't know if we'll reach enough people if we do it in the google forum. Maybe Lichess could help us out to conduct a poll? It certainly could give us insight in the current situation.

GediminasMasaitis commented 3 years ago

This would simplify #3429 a lot

ddobbelaere commented 3 years ago

Why would we need a poll?? Seriously...

If only one single person wants to run latest SF on his Raspberry Pi Zero at some point, he can't do so because we've dropped support... for a few lines of code. Personally I think this is ridiculous.

NightlyKing commented 3 years ago

Everything has an end of life and so does 32 bit. NNUE is way past of what 32 bit systems can actually handle. Removing 32 bit support is better for almost all people. This could be confirmed/debunked by a poll. Those who get hit by it can still use SF13 and have more than "good enough" results.

BM123499 commented 3 years ago

@NightlyKing could you list which benefits that removing 32 bit support will bring?

ddobbelaere commented 3 years ago

Removing 32 bit support is better for almost all people.

How so? Should we expect a large elo gain? I don't think so :P

No user will benefit from this, on the contrary.

NightlyKing commented 3 years ago

As I said, it prevents future problems (like the one we have in the current PR #3429) and it is a free simplification. There is no reason to keep it. 32 bit is practically dead,

ddobbelaere commented 3 years ago

There is no reason to keep it. 32 bit is practically dead,

Feel free to ignore all my points raised.

NightlyKing commented 3 years ago

Removing 32 bit support is better for almost all people.

How so? Should we expect a large elo gain? I don't think so :P

No user will benefit from this, on the contrary.

So removing code that does change SF and has quite a chance of regressing is ok but removing a part of code that covers less than .1% of users and can't cost elo is suddenly a bad deal?

NightlyKing commented 3 years ago

There is no reason to keep it. 32 bit is practically dead,

Feel free to ignore all my points raised.

I didn't. If you truly believe people who still didn't get rid of their 32 bit hardware care a lot about performance then I can't help you. Do you really think it would make a huge deal for them if they had to stick with SF13? Sopel and me proposed to make a poll to see if my assumption is even correct but I guess I'm not the only one ignoring arguments :)

ddobbelaere commented 3 years ago

If you truly believe people who still didn't get rid of their 32 bit hardware care a lot about performance then I can't help you.

Hobbyists might want to run latest SF on their brand new Raspberry Pi Zero board. If you don't understand that I can't help you either.

Sopel97 commented 3 years ago

They are free to modify the code as needed

NightlyKing commented 3 years ago

Stuff tends to get obsolete. 32 bit is and their Pi Zero is as well. If they need it they can modify the code as needed. I don't see why SF devs should still cater to the needs of a super small minority. Anybody who bought a Pi Zero knew that at one day it would be practically useless (which has already happened). Same happened to old cars that needed gas with lead. They had to find a way around it and nobody complained because it was a step forward.

GediminasMasaitis commented 3 years ago

Is there any code that would break 32 bit if removed or will it just have a regression? If not, is the regression significant? Any way to estimate?

Regarding magics I can say for sure that it wouldn't be breaking.

BM123499 commented 3 years ago

They are free to modify the code as needed

This is not an answer, if we were doing it, we wouldn't add any other architecture in Makefile. To be honest, I would agree about removing 32bit support if it were complex or it had a lot of lines supporting it. But, suddenly, removing 10 simple lines of codes just to remove a support, it seems too much for me. If it has a refactoring on magic, or it's added a new way to calculate magic that 32bits would really harm the code, I would agree on removing it. While it doesn't happen, I see no benefits in removing it.

ScallyBag commented 3 years ago

Hi,

Please don’t get rid of 32bit Stockfish. We use it as our main tutor engine in Picochess on a Raspberry Pi 3b, 3b+ & 4. 64bit OS is still in beta on the RPi so we don’t use that yet.

Thanks,

Al.

NightlyKing commented 3 years ago

Hi,

Please don’t get rid of 32bit Stockfish. We use it as our main tutor engine in Picochess on a Raspberry Pi 3b, 3b+ & 4. 64bit OS is still in beta on the RPi so we don’t use that yet.

Thanks,

Al.

It wouldn't remove it from past versions, only in the coming releases. SF13 is more than enough for a tutor.

NightlyKing commented 3 years ago

There are more people who would benefit from a fortress detection switch than people that benefit from 32 bit support and yet we don't have a fortress detection UCI option but 32 bit support. To me this seems very inconsistent. If we don't even support such useful features and have people maintain forks for such useful things then why would we treat 32 bit support in any other way?

vdbergh commented 3 years ago

@NightlyKing Crusading is never a good way to do software development.

The fact is that the little bit of 32 bit code in SF is completely harmless. If it conflicts with a more recent development then one can decide on a case by case basis what should be done.

BM123499 commented 3 years ago

There are more people who would benefit from a fortress detection switch than people that benefit from 32 bit support and yet we don't have a fortress detection UCI option but 32 bit support. To me this seems very inconsistent. If we don't even support such useful features and have people maintain forks for such useful things then why would we treat 32 bit support in any other way?

One thing is adding features, another is removing for no benefit reason. If you can always suggest new features and they might be added. And more, you are saying that's "more than enough". What is "more than enough"? SF11 is more than enough to defeat non-master human, should we stop developing SF? You're imposing a personal perspective to remove an harmless bunch of lines that improves older architectures. If they are obsolete, it will be removed eventually with a new magic bitboard system, or something similar, why do we have to do it now?

NightlyKing commented 3 years ago

@NightlyKing Crusading is never a good way to do software development.

The fact is that the little bit of 32 bit code in SF is completely harmless. If it conflicts with a more recent development then one can decide on a case by case basis what should be done.

I don't see how I'm a crusader? I feel like my suggestions are ignored. What is wrong with a poll to see which of the different arches are actually used?

What is "more than enough"? SF11 is more than enough to defeat non-master human, should we stop developing SF? You're imposing a personal perspective to remove an harmless bunch of lines that improves older architectures.

This is exactly why it should be removed. At best it does nothing to hinder the development and at worst it causes bugs (like large pages on windows) and stalls out PRs (like the current one). By removing it we eliminate a potential source of bugs in the future. This is good for devs and makes a step towards the future while those stuck in the old days still have the previous release.

And when is the "right time" to remove 32 bit support? Once windows stopped supporting it? Once all linux distros stopped supporting it? All I'm saying is that it is de facto obsolete which is why it makes sense to me to remove it unless it can be shown that there is a significant amount of people depending on it.

GediminasMasaitis commented 3 years ago

Once all linux distros stopped supporting it?

Oh that will NEVER happen. I remember watching a talk by Linus, he said that they had to ask some one specific dude to stop using some obscure architecture from 40 years ago just so they can stop supporting it in the kernel, because they go by a very strict policy of not removing support if anyone uses it.

Different caliber of project here though.

BM123499 commented 3 years ago

Well. I have no idea who are using 32bit SF. But about 32bit, in Stockfish website, we have displayed:

NightlyKing commented 3 years ago

Once all linux distros stopped supporting it?

Oh that will NEVER happen. I remember watching a talk by Linus, he said that they had to ask some one specific dude to stop using some obscure architecture from 40 years ago just so they can stop supporting it in the kernel, because they go by a very strict policy of not removing support if anyone uses it.

Different caliber of project here though.

Well, maybe ... maybe not. Eventually there will be no single person left using 32 bit. And Linus has some strange views too like AVX-512 being the devils work, while SF is the best proof that it can actually be amazing ... But that's neither here nor there. SF isn't Linux and my question when the right time is remains valid. In the end our maintainer will have to make a decision and it certainly isn't harmful to discuss it. You see, this is why I opened an issue and not a PR!

MichaelB7 commented 3 years ago

@NightlyKing - you have made 12 comments on your own request . We hear you. Your argument is not persuasive a this time. If and when the RPI gets official 64 bit support and two years has passed, it may be more persuasive. We literally have scores of RPI users using it with DGT boards. The 32 bit SF user community is much larger than you think.

NightlyKing commented 3 years ago

Wow, such a damaging thing for DGT users to be relegated to stick with SF13 for a while until they get 64 bit support.

Please give me a link to the rules, apparently I didn't know one is only allowed to comment 11 times... Maybe I'm wrong about how many people actually use 32 bit - but maybe you're the one. I ask once more, what's wrong with a poll and gathering stats about it? Do you fear that it'll confirm my suspicion that 32 bit is too irrelevant to show up in the results? If it is used by more than 1 percent of all types of SF users I will gladly shut up about it until RPI is 64 bit by default.

GediminasMasaitis commented 3 years ago

What do you mean exactly by "strip the 32 bit support"? Should we not care that it doesn't work on 32 completely, or that we shouldn't care about regressions on 32 if we remove 32 bit code?

MichaelB7 commented 3 years ago

Wow, such a damaging thing for DGT users to be relegated to stick with SF13 for a while until they get 64 bit support.

Please give me a link to the rules, apparently I didn't know one is only allowed to comment 11 times... Maybe I'm wrong about how many people actually use 32 bit - but maybe you're the one. I ask once more, what's wrong with a poll and gathering stats about it? Do you fear that it'll confirm my suspicion that 32 bit is too irrelevant to show up in the results? If it is used by more than 1 percent of all types of SF users I will gladly shut up about it until RPI is 64 bit by default.

There is nothing wrong with your suggestion or the number of comments at all, but you appear to have an obsessive desire to respond to every comment that is not supporting your idea. To me , it seems that you are taking these comments personally. We are not attacking you, we (a few of us) are simply not in a agreement with your suggestion. That is how life is, people can have disagreements and things may not always go your way. I have been in the same position many times. I just move forward. The maintainers have not spoken yet and who knows, they may support your suggestion And if they do, I am certainly not going to take it personally. I will just move on.

vondele commented 3 years ago

In my opinion, we should definitely not optimize for 32, but the code should work correctly on 32 bits systems. Specific optimization for 32 bit can be removed IMO (subject to the usual fishtest testing). My Raspberry by runs a 32 bit kernel.

NightlyKing commented 3 years ago

I think not further optimizing it as it is done in PR #3429 is a good start. Let's wait a bit longer until RPI comes with 64 bits by default.