freebsd 6x slower than Raspbian 10 buster on RPi 4b

[Mark Millard]

On 2021-Feb-10, at 06:05, Robert Crowston <crowston at protonmail.com> wrote:

> I am surprised gcc does not eliminate this side-effect free computation, it seems almost a missed-optimization bug to me. But the Clang people have put a lot of work into finding ways to elide unnecessary malloc() calls, so perhaps that is the fruit of their labour.

> By the use of variable length arrays and the style this code does not appear to be C++. I assume it is C. It is unwise to confuse these two different languages.

Yep. But the file was supplied as a .cpp file and g++ was listed as used.
I had commented on the variable length arrays via reporting what the
compilers say when more checks are enabled. Not knowing if it might
be the start of something bigger that would be more C++ specific, I
left it at that for the language issue.

> What is the actual use case here? This kind of contrived micro benchmark never tells you very much about realworld performance.

Other than the language issue I mostly provided notes relative to various
assumptions made in the code and in the compile options and choice of
what tool chains to explore, points that were probably contrary to a
variety of potential purposes that involve timing things.

This does not mean that I disagree about the limited uses to which the
type of benchmark exploration apply. But I'm fine with folks exploring
things that they are unfamiliar with. I primarily helped with the
exploration aspect some.

> The Linux people have full time staff working on the Raspbian. They have access to proprietary hardware information we do not. I would expect they will always edge ahead on this platform.
> 
> But you have too many variables in play to draw the conclusion freebsd is 6 times slower.

I never made such a claim in what I replied with. I gave specific
evidence of some specific issues that needed to be addressed to even
have a fairly well controlled testing activity (unless checking the
variations in optimizations of the specific code for just the g++
context was the goal).

I did get an off-list reply indicating that various adjustments had been
made that made the results more uniform across the contexts, so,  I
would presume, no more factor of 6. (It did not indicate specific figures
or show the updated code.) In some respects it is too bad that that note
was off list: no on-list updated conclusions presented by the originator.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net <http://dsl-only.net/> went
away in early 2018-Mar)