[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