crystal-lang / crystal

The Crystal Programming Language
https://crystal-lang.org
Apache License 2.0
19.2k stars 1.61k forks source link

Add Makefile support `--mcpu=native` as override FLAGS to permit build crystal compiler can enable this option optional for a better performance. #14744

Closed zw963 closed 1 week ago

zw963 commented 1 week ago

As discuss in this forum link.

Add --mcpu-=native give me a really better performance on my local AMD 7840hs laptop.

Following is the explanation for --mcpu or --‑mtune in the arm community


GNU and LLVM compilers support passing the special parameter value “native” to these flags. The “native” value tells the compiler to detect the architecture and/or microarchitecture of the machine on which the compiler is executing and use that (micro)architecture as the parameter to -march, -mtune, or -mcpu as appropriate. Assuming architecture detection works for your platform, passing “native” is usually the best choice if you’re not cross-compiling and all you care about is performance.[3] With the GNU compiler, all three flags can accept “native” as a parameter so -march=native, -mtune=native, and -mcpu=native are all valid. LLVM compilers only support “native” for the -mcpu and -mtune flags. You cannot use -march=native with LLVM-based compilers. If you’re not cross-compiling, always use -mcpu=native to maximize optimization and compatibility across compilers.

On Arm, if you want to optimize for both a particular architecture and microarchitecture then you use the -mcpu flag. This is different from x86, where -mcpu is a deprecated synonym for ‑mtune. The -mcpu flag accepts the same parameter values as the -mtune flag. For example, -mcpu=thunderx2t99 is correct but ‑mcpu=armv8.1-a is not. Figure 4 shows the execution and optimization spaces of a binary compiled with -mcpu=thunderx2t99. In this case, the binary could execute on anything implementing the v8.1 architecture or better, but it has been optimized for execution on the ThunderX2.


I am not an expert in this area, in fact, I am quite lacking knowledge about this area. but I think adding --mcpu=native when compiling the Crystal compiler on the local machine, and the compiler only be used on the local machine too, it should be a good idea, and i have been built a Crystal compiler on my Arch linux locally with --mcpu=native enabled, and then built a lucky project use this new compiler, and deploy it into production, it has been working well so far.

So, i propose to add support for this in the Makefile use a optional flag, if this is acceptable, i will create a PR for this.

Sure, as I said, because not familiar with this tune, there may be some things that were lack considered.

Thanks.

crysbot commented 1 week ago

This issue has been mentioned on Crystal Forum. There might be relevant details there:

https://forum.crystal-lang.org/t/there-is-a-way-to-optimize-this-program/6947/13

Blacksmoke16 commented 1 week ago

Would it actually be common enough of an option to really make it that much easier vs just doing like FLAGS=--mcpu=native make?

zw963 commented 1 week ago

Would it actually be common enough of an option to really make it that much easier vs just doing like FLAGS=--mcpu=native make?

Oh, no, really?

I don't know we can use FLAGS like this, i thought we have to add a flag to make this option work, e.g. native=1.

zw963 commented 1 week ago

FLAGS=--mcpu=native make

Cool, it works, i forget i can pass flags use env, feel free to close this issue if people thought this option is not important.