[sdiy] GCC vs Clang for Audio DSP
Eric Brombaugh
ebrombaugh at gmail.com
Wed May 4 22:05:16 CEST 2022
Ben,
Good points - setting compile flags is a mysterious business and minor
changes can have huge effects. In this test I used the exact same flags
for GCC and the free Clang, so if Clang has any additional optimizations
that are not in common with GCC they're not reflected in the current
results. The trial version of ARM Clang has very different command line
usage so that one did not use a common set of build scripts and options.
Nonetheless it still shows similar performance to the free version. That
said, if anyone can show me how to improve the results I'd love to do so
and re-run the analysis.
WRT compile errors & warnings, yes I've heard that Clang is much more
helpful in that regard. I haven't really looked at that in this
experiment because I did all the initial bring-up on GCC so by the time
I got to compiling with Clang there weren't any errors left. That said I
have noticed a very substantial improvement in the quality of errors and
warnings that I get from GCC over the last few years - it's been very
helpful for my work and if Clang is even better then that would be an
important advantage.
Eric
On 5/4/22 12:50, Ben Stuyts wrote:
> Hi Eric,
>
> Very interesting, and not what I expected. I generally see smaller code with clang compared to gcc. Mostly using Cortex-M0..M3 class cpu’s with -Os. Only critical files are compiled for speed. It could be that CrossWorks is not setting all the cmd line options in an optimal way.
>
> Have you looked at the difference in error messages? I generally think those from clang are better / easier to understand than those from gcc.
>
> Ben
>
>
>> On 4 May 2022, at 21:20, Eric Brombaugh via Synth-diy <synth-diy at synth-diy.org> wrote:
>>
>> In a previous thread we had some exchanges about the performance of various compilers used in embedded ARM applications. I've been using GCC for this over the course of the last decade and had seen some remarkable improvements in its performance so I was somewhat surprised that it was viewed as being substantially underperforming in comparison to the proprietary toolchains based on LLVM/clang.
>>
>> I decided to try for myself and put together a quick DSP benchmark that's representative of the sort of stuff that I often do in my embedded work. I took some time to create build scripts for clang and test out both the free and proprietary versions to compare them against GCC for both execution speed and binary size. the results are interesting so I summarized them with tables and charts over here:
>>
>> https://github.com/emeb/f303k8_nucleo
>>
>> The quick summary is that based on this one example it appears that recent builds of GCC are not grossly out of line with the performance of Clang in both the free and proprietary flavors. For all levels of optimization greater than -O0 GCC performs roughly as well if not better than either version of Clang. This test also shows very little difference between the free and proprietary versions of Clang.
>>
>> I would like to emphasize that this is one particular use-case and by no means representative of the performance you'd see in all applications of these compilers. It does however provide an alternative viewpoint backed by hard evidence to the notion that GCC is generally sub-standard and not for professional use.
>>
>> If you have questions about the methodology I used here, the entire source and build scripts are available at that github repo for your inspection. I will admit that I'm not a clang power-user so there may be some optimizations that I've overlooked and I'd appreciate any suggestions on how to make this analysis more complete.
>> _______________________________________________
>> Synth-diy mailing list
>> Synth-diy at synth-diy.org
>> http://synth-diy.org/mailman/listinfo/synth-diy
>> Selling or trading? Use marketplace at synth-diy.org
>
More information about the Synth-diy
mailing list