Re: OT: Programming Languages

On Sat, 2 Nov 2024 18:01:40 +0000, Martin Brown
<'''newspam'''@nonad.co.uk> wrote:

On 01/11/2024 23:54, john larkin wrote:

On Fri, 1 Nov 2024 16:03:00 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:
 

On 11/1/2024 3:50 PM, Nick Hayward wrote:

What about C++?

>
C++ is an order of magnitude more complex than C.  Even a
casual C programmer can imagine what his code will look
like after compilation.  I.e., can imagine exactly what the
CPU will be doing (ignoring the fact that the compiler will
often out-think the coder in terms of time/space efficiency).

 
We want to time the execution of a control algorithm. One way to time
it is to run it in a loop maybe 100K times and measure that with a
stopwatch. But a very smart compiler might run it once, notice that
nothing has changed, and skip the reruns.

>
Most compilers these days are smart enough to move loop invariants
outside of a loop and then dispose of the loop. You must have side
effects in any code that you want to benchmark. Optimisers can be
*really* smart about rearranging code for maximum performance by
avoiding pipeline stalls. Only the very best humans can match them now.
>
Every now and then you stumble upon a construct that on certain
platforms is unreasonably fast (2x or 4x). Increasingly because it has
vectorised a loop on the fly when all go faster stripes are enabled.
>
Precision timers and benchmarking tools are available on most platforms
no need to use a stop watch unless you enjoy watching paint dry.

I can really trust a stopwatch or an oscilloscope. 5 seconds spent
measuring a loop time won't ruin my day.

>

It's best to bang a port pin and measure it with an oscilloscope.
 
We've had FPGA compilers do that sort of thing, optimize out
intentional delays. One fix is to XOR signals with a level from a pin
that *we* know is always low.

>
If the compiler can see that is true you could still get caught out.

The compiler can't know if I have grounded a pin.