Add support for LDC(LLVM D-Compiler)

[cyrusmsk]

Hi @viscropst! Do you know how to add in Alpine similar flags for GDC and LDC as it used for example in C/C++ compilation? -static -flto -march=native -mtune=native -fomit-frame-pointer -fno-signed-zeros -fno-trapping-math -fassociative-math Because I found how to make a static build, but LTO is not working for me in Alpine.

Also '-mcpu=native' should have good boost in performance for LDC

[niklas-heer]

@viscropst I appreciate your effort in adding to this project. But it seems that it doesn't quite work yet. The pipeline says cc is missing. Do you maybe know why?

https://github.com/niklas-heer/speed-comparison/actions/runs/3344388742/jobs/5538680781#step:6:1132

[cyrusmsk]

Because LDC need cc, as it relies on clang backend. It is possible to fix this just with right flags. I wonder about flag btw - @niklas-heer do you currently have any rules on the flags? because I can see that different languages using different ones

[niklas-heer]

Because LDC need cc, as it relies on clang backend. It is possible to fix this just with right flags.

Ah, okay, makes sense. I guess that is it part of gcc? (if I look at this issue)

I wonder about flag btw - @niklas-heer do you currently have any rules on the flags? because I can see that different languages using different ones

Nope, there are no rules for flags. Would you suggest adding rules?

[cyrusmsk]

In case you want that the result will be compatible - there should be some rules on flags and approaches. Fast-math or some other oprimizations could affect. Even more some languages could find the whole answer in compile-time and just print the answer in 1 second, which will be obviously not clean game :)

[viscropst]

@viscropst I appreciate your effort in adding to this project. But it seems that it doesn't quite work yet. The pipeline says cc is missing. Do you maybe know why?

https://github.com/niklas-heer/speed-comparison/actions/runs/3344388742/jobs/5538680781#step:6:1132

@niklas-heer For this error in alpine, It's can solved by apk add --no-cache gcc,because of ldc's default config make cc as default c compiler,and the bfd as the default linker and the runtime depends on libgcc, so we can't use the ll.lld and clang to link and compile without gcc.

Hi @viscropst! Do you know how to add in Alpine similar flags for GDC and LDC as it used for example in C/C++ compilation? -static -flto -march=native -mtune=native -fomit-frame-pointer -fno-signed-zeros -fno-trapping-math -fassociative-math Because I found how to make a static build, but LTO is not working for me in Alpine.

Also '-mcpu=native' should have good boost in performance for LDC

@cyrusmsk For flags on ldc,I tried with -static(needs to add llvm-libunwind-static package), -lto=thin(needs to add llvm12 package for LLVMgold.so), -mcpu=native(it's shows different from result 3.14159266358932359 when used with -ffast-math),-ffast-math,-frame-pointer=none,and others only uses with -Xcc flag pass to gcc.

[cyrusmsk]

Interesing results. But for C - it is also wrong result for me :) that's why it is so fast :) 3.1415926635978728 - this is what I have for C

And it seems that there is some problem with accuracy computations

[cyrusmsk]

@viscropst I propose to use as fast as possible version currently :) with native and fast-math as long it is not restricted

[viscropst]

@cyrusmsk Okay,I've done them to my LDC's flags.

[niklas-heer]

@viscropst thank you for your contribution! 👍 @cyrusmsk I appreciate your input, thank you :)

[niklas-heer]

In case you want that the result will be compatible - there should be some rules on flags and approaches. Fast-math or some other oprimizations could affect. Even more some languages could find the whole answer in compile-time and just print the answer in 1 second, which will be obviously not clean game :)

Interesting suggestion. I agree with you the second part "finding the answer during compile time" that would be a deal-breaker for me. The fast-math I still find okay because it is an optimization a language offers.

[niklas-heer]

How would you check and ensure this? I don't have the extra time to look up all the compiler flags for each language whenever a new PR is opened.

[cyrusmsk]

@niklas-heer Maybe it is not necessary.. because sometimes benchmark's rules decide to have "exactly same realization and flags" for comparison. The other possible strategy - choose whatever you want and let's see that you can do with the problem. But the Accuracy still seems supsicious for me. For different digit at the same position with the "rea" pi - doesn't affect much on Accuracy value. And btw could you please change DO +BENCH --name="d" --lang="D (LDC)" --version="ldc2 --version" --cmd="./leibniz" to DO +BENCH --name="d-ldc" --lang="D (LDC)" --version="ldc2 --version" --cmd="./leibniz" because it is overwritine GDC results in other case. Or I can prepare PR for this small typo - please let me know if it is fine for you.

[viscropst]

@cyrusmsk Thanks. I'll make a PR to fix this typo.

[niklas-heer]

@niklas-heer Maybe it is not necessary.. because sometimes benchmark's rules decide to have "exactly same realization and flags" for comparison. The other possible strategy - choose whatever you want and let's see that you can do with the problem.

Interesting idea, I feel that compiler flags are not yet a big problem, and they have lead to interesting contributions. I think for now I will just let it play out. I'm just too curious of what people will come up with. 😅

And btw could you please change DO +BENCH --name="d" --lang="D (LDC)" --version="ldc2 --version" --cmd="./leibniz" to DO +BENCH --name="d-ldc" --lang="D (LDC)" --version="ldc2 --version" --cmd="./leibniz" because it is overwritine GDC results in other case. Or I can prepare PR for this small typo - please let me know if it is fine for you.

Good catch! As set in #92 the name argument is super important to be unique. Otherwise, it will overwrite stuff, as you also pointed out. 👍