M1 Apple Silicon for Chess?

[AlexChess]

If you know tutorials that esplain the procedures step by step (and all tools needed) and share them I would be very grateful.

That depends on the engine, programming language, and operating system. You can have makefiles, build scripts, or even MS Visual Studio projects (mostly for Windows-only engines). Sometimes, the Windows version is not even built under Windows, but cross-compiled e.g. from Linux. The specific instructions and requirements should be in the engine documentation.

Yes I know, I have Visual Studio Community 2019 + BuildTools for ARM64, CLang and GCC compilers, I know that I must use

make -j build ARCH=apple-silicon for macOS Big Sur M1 NATIVE ,

make -j build ARCH=armv8 for Ubuntu ARM64 and Raspberry PI4

and something like:

make -j build ARCH=arm64 -msbuild for Windows ARM64

but I need a detailed guide about how to modify the make file

My problem is that here no one seems interested on Silicon M1 or WinARM64, most users are even hostile calling me troll and I cannot find a Microsoft ARM64 developers forum that can help me, while Windows 11 ARM64 will be released on October 5

[Milos]

If you know tutorials that esplain the procedures step by step (and all tools needed) and share them I would be very grateful.

That depends on the engine, programming language, and operating system. You can have makefiles, build scripts, or even MS Visual Studio projects (mostly for Windows-only engines). Sometimes, the Windows version is not even built under Windows, but cross-compiled e.g. from Linux. The specific instructions and requirements should be in the engine documentation.

Yes I know, I have Visual Studio Community 2019 + BuildTools for ARM64, CLang and GCC compilers, I know that I must use

make -j build ARCH=apple-silicon for macOS Big Sur M1 NATIVE ,

make -j build ARCH=armv8 for Ubuntu ARM64 and Raspberry PI4

and something like:

make -j build ARCH=arm64 -msbuild for Windows ARM64

but I need a detailed guide about how to modify the make file

My problem is that here no one seems interested on Silicon M1 or WinARM64, most users are even hostile calling me troll and I cannot find a Microsoft ARM64 developers forum that can help me, while Windows 11 ARM64 will be released on October 5

That's nothing strange. First compiling questions are way beyond what most ppl here know, specially when they are beyond basic ./configure; make, or cmake; make.
Building parameters and smooth building process for not only difficult OS (like macOS) but also completely new target CPU like M1 ARM64 (that is a totally different flavor from standard ARM) is way beyond what anyone knowledgeable enough would like to invest their time in. You seems to forget that your are in such a small user niche that basically comprises of 3-4 ppl max. It might be disappointing for you, but Macs and even more so ARM based Macs are a terrible platform for enthusiast chess.

[AlexChess]

If you know tutorials that esplain the procedures step by step (and all tools needed) and share them I would be very grateful.

That depends on the engine, programming language, and operating system. You can have makefiles, build scripts, or even MS Visual Studio projects (mostly for Windows-only engines). Sometimes, the Windows version is not even built under Windows, but cross-compiled e.g. from Linux. The specific instructions and requirements should be in the engine documentation.

Yes I know, I have Visual Studio Community 2019 + BuildTools for ARM64, CLang and GCC compilers, I know that I must use

make -j build ARCH=apple-silicon for macOS Big Sur M1 NATIVE ,

make -j build ARCH=armv8 for Ubuntu ARM64 and Raspberry PI4

and something like:

make -j build ARCH=arm64 -msbuild for Windows ARM64

but I need a detailed guide about how to modify the make file

My problem is that here no one seems interested on Silicon M1 or WinARM64, most users are even hostile calling me troll and I cannot find a Microsoft ARM64 developers forum that can help me, while Windows 11 ARM64 will be released on October 5

That's nothing strange. First compiling questions are way beyond what most ppl here know, specially when they are beyond basic ./configure; make, or cmake; make.
Building parameters and smooth building process for not only difficult OS (like macOS) but also completely new target CPU like M1 ARM64 (that is a totally different flavor from standard ARM) is way beyond what anyone knowledgeable enough would like to invest their time in. You seems to forget that your are in such a small user niche that basically comprises of 3-4 ppl max. It might be disappointing for you, but Macs and even more so ARM based Macs are a terrible platform for enthusiast chess.

Yes I know, M1 is still limited. I hope that, with October macOS Monterey release, Silicon M2 will increase the potential related to chess and devices like Surface Pro X will spread Windows 11 ARM. https://www.forbes.com/sites/ewanspence ... mark-leak/

[Ras]

but I need a detailed guide about how to modify the make file

You could check out Acepoint's website to see some examples:
https://acepoint.de/five-updates/#more-596
https://acepoint.de/sweet-stuff-updated ... /#more-632
https://acepoint.de/five-updates-for-the-m1/#more-662
https://acepoint.de/seven-at-one-stroke/#more-685

My problem is that here no one seems interested on Silicon M1

I didn't find any easy way to cross-compile for Macs. Apple's idea is that you use Xcode and most importantly (for Apple's profit line), that you have to actually buy a Mac. Obviously, that's a complete non-starter. I just won't shell out several hundred bucks to compile a non-commercial engine for a platform that I don't even use, and I think I'm not alone with this stance. On the other hand, I don't want to distribute code compiled by someone else where I have no way to know what is actually in there.

I do provide a build script for Mac, and since that is just using Clang without target, it will cause Clang to compile code for the host computer. Means, if you run that on an M1 with Clang installed, I'd expect it to generate an M1 binary.

or WinARM64

Windows on ARM is a market flop. All devices have been garbage, there is no reason to buy them, and WinARM is going the way all the other non-x86 Windows versions went. That's for technical reasons, because the x86 emulation sucks. It will never be close to Apple's Rosetta2 because that required Apple to add some hardware features not found in standard ARM chips, but Microsoft went the cheap route and picked such standard ARM chips. It's also for commercial reasons because Apple controls the hardware of their ecosystem while Microsoft does not.

[AlexChess]

but I need a detailed guide about how to modify the make file

You could check out Acepoint's website to see some examples:
https://acepoint.de/five-updates/#more-596
https://acepoint.de/sweet-stuff-updated ... /#more-632
https://acepoint.de/five-updates-for-the-m1/#more-662
https://acepoint.de/seven-at-one-stroke/#more-685

My problem is that here no one seems interested on Silicon M1

I didn't find any easy way to cross-compile for Macs. Apple's idea is that you use Xcode and most importantly (for Apple's profit line), that you have to actually buy a Mac. Obviously, that's a complete non-starter. I just won't shell out several hundred bucks to compile a non-commercial engine for a platform that I don't even use, and I think I'm not alone with this stance. On the other hand, I don't want to distribute code compiled by someone else where I have no way to know what is actually in there.

I do provide a build script for Mac, and since that is just using Clang without target, it will cause Clang to compile code for the host computer. Means, if you run that on an M1 with Clang installed, I'd expect it to generate an M1 binary.

or WinARM64

Windows on ARM is a market flop. All devices have been garbage, there is no reason to buy them, and WinARM is going the way all the other non-x86 Windows versions went. That's for technical reasons, because the x86 emulation sucks. It will never be close to Apple's Rosetta2 because that required Apple to add some hardware features not found in standard ARM chips, but Microsoft went the cheap route and picked such standard ARM chips. It's also for commercial reasons because Apple controls the hardware of their ecosystem while Microsoft does not.

Thank you for your interesting analysis... Yes, until now Surface ARM64 is a flop and could repeat the Windows RT debacle. But if Apple will let to natively install Windows 11 ARM64 on Silicon Macs, it could become a completely different history...

PS: Acepoint is my only reference here for native Silicon M1, and I'm really grateful to him, but it doesn't support Windows ARM64 on Parallels and some x64 engines aren't availableS also on Mac (while some others for x64 AVX & BM2 compiled by him run only on Mac) . It's my only reason for using Windows 11 emulated and not only Mac that is 2-3 times faster while running chess engines.

[Ras]

But if Apple will let to natively install Windows 11 ARM64 on Silicon Macs, it could be a completely different history...

Actually not. There's no way that Windows users would accept e.g. paying three times the market rate for flash storage like in the M1. Apple selects its customers and only picks those who don't mind overpaying. Windows machines are a lot more price sensitive because there is competition.

And then you would still have the problem that with WinARM on M1, the emulation would be the one of Microsoft Windows, not Apple's Rosetta2. Means, legacy applications would still run badly, which is why people wouldn't do that, which is why that platform would not become widespread, which is why devs wouldn't care to target it with native versions (checken and egg problem).

Btw., do you actually have a WinARM device? It seems that there is a way to even cross-compile using Clang-MingW: https://github.com/mstorsjo/llvm-mingw

[AlexChess]

But if Apple will let to natively install Windows 11 ARM64 on Silicon Macs, it could be a completely different history...

Actually not. There's no way that Windows users would accept e.g. paying three times the market rate for flash storage like in the M1. Apple selects its customers and only picks those who don't mind overpaying. Windows machines are a lot more price sensitive because there is competition.

And then you would still have the problem that with WinARM on M1, the emulation would be the one of Microsoft Windows, not Apple's Rosetta2. Means, legacy applications would still run badly, which is why people wouldn't do that, which is why that platform would not become widespread, which is why devs wouldn't care to target it with native versions (checken and egg problem).

Btw., do you actually have a WinARM device? It seems that there is a way to even cross-compile using Clang-MingW: https://github.com/mstorsjo/llvm-mingw

Yes, the Windows 11 ARM64 preview installer for Parallel Desktop M1 is the real one without modifications and it is fully compatible with a true Surface Pro X device. It is also very stable and quite fast, This link seems really interesting: "A single toolchain targeting all four architectures (i686, x86_64, armv7 and arm64) instead of separate compiler binaries for each architecture" I try to understand how to use it.

Thank you,
Best regards, Alex

Note: Before other users say that we are off-topic here: Parallels is only another way to fully exploit the potential of M1 Apple Silicon for Chess

[Ras]

This link seems really interesting: "A single toolchain targeting all four architectures (i686, x86_64, armv7 and arm64) instead of separate compiler binaries for each architecture" I try to understand how to use it.

I've made an experimental compile using that toolchain (UCI version only): https://www.ct800.net/download/ct800-v1.43a.zip. Functionally, it's identical to my regular v1.43, just renamed to v1.43a to avoid file name confusion. The relevant build scripts are make_ct800_win_clang.bat (on Windows) or make_ct800_win_clang.sh (on Linux). You can compare that to my normal GCC based build scripts make_ct800_win.bat resp. make_ct800_win.sh, which of course target only x86-Windows.

In the output directory, you'll find four Windows executables: x86 and ARM, plus 32 bit and 64 bit each. I have only an old netbook with 32 bit Windows for testing. The Clang generated x32 executable works, albeit slightly slower than my normal GCC based build.

I think the x86-64 emulation may not work with ARM-Windows (try to run the x64 executable), but the x86-32 emulation should. That would allow to see how efficient the emulation really is, compared to the native version. Do the ARM versions work, both 32 and 64 bit? What's the performance of your benchmarks, like NPS in the initial position after maybe 20 seconds? That would be for x32, a32, a64 (and x64 if that emulation should work).

[AlexChess]

Wow!
Thank you very much RAS! You are really kind and your CT800 project Is very interesting, too! Once at home I will test your binarIes and report if they work and how fast

[AlexChess]

This link seems really interesting: "A single toolchain targeting all four architectures (i686, x86_64, armv7 and arm64) instead of separate compiler binaries for each architecture" I try to understand how to use it.

I've made an experimental compile using that toolchain (UCI version only): https://www.ct800.net/download/ct800-v1.43a.zip. Functionally, it's identical to my regular v1.43, just renamed to v1.43a to avoid file name confusion. The relevant build scripts are make_ct800_win_clang.bat (on Windows) or make_ct800_win_clang.sh (on Linux). You can compare that to my normal GCC based build scripts make_ct800_win.bat resp. make_ct800_win.sh, which of course target only x86-Windows.

In the output directory, you'll find four Windows executables: x86 and ARM, plus 32 bit and 64 bit each. I have only an old netbook with 32 bit Windows for testing. The Clang generated x32 executable works, albeit slightly slower than my normal GCC based build.

I think the x86-64 emulation may not work with ARM-Windows (try to run the x64 executable), but the x86-32 emulation should. That would allow to see how efficient the emulation really is, compared to the native version. Do the ARM versions work, both 32 and 64 bit? What's the performance of your benchmarks, like NPS in the initial position after maybe 20 seconds? That would be for x32, a32, a64 (and x64 if that emulation should work).

Dear Ras, I would like to have 1/100 of your technical skills

Both versions work out-of-the-box. As expected the ARM64 binary it's almost 2 times faster than the Intel x64 version (this was the reason for asking to some skilled members here an help for WinARM64 builds, but they simply called me troll or MORON, pushing me out of their topics and threatening to block me and report my invasive posts... )





Thank you again for your support, friendship and tolerance, now I know that I can continue to search a tutorial to compile all the open source engines by myself!

Best regards, Alex