Re: Baby X is bor nagain

On 21/06/2024 14:34, David Brown wrote:

On 21/06/2024 12:42, bart wrote:

On 21/06/2024 10:46, David Brown wrote:

On 20/06/2024 22:21, Vir Campestris wrote:

On 17/06/2024 20:29, David Brown wrote:

I do my C development with optimisations enabled, which means that the C compiler will obey all the rules and requirements of C. Optimisations don't change the meaning of correct code - they only have an effect on the results of your code if you have written incorrect code.  I don't know about you, but my aim in development is to write /correct/ code. If disabling optimisations helped in some way, it would be due to bugs and luck.

>
To me disabling optimisations does one slightly useful thing (compiles a little quicker) and one really useful one. It makes the interactive debugger work. Optimised code confuses the debugger, especially when it does things like reorder code, unroll loops, or merge equivalent functions.
>
Of course I then test with the optimised version.
>
Andy

>
>
I understand your viewpoint and motivation.  But my own experience is mostly different.
>
First, to get it out of the way, there's the speed of compilation. While heavy optimisation (-O3) can take noticeably longer, I never see -O0 as being in any noticeable way faster for compilation than -O1 or even -O2.

>
Absolute time or relative?

 Both.
 

For me, optimised options with gcc always take longer:

 Of course.  But I said it was not noticeable - it does not make enough difference in speed for it to be worth choosing.
 

>
  C:\c>tm gcc bignum.c -shared -s -obignum.dll        # from cold
  TM: 3.85

 Cold build times are irrelevant to development - when you are working on a project, all the source files and all your compiler files are in the PC's cache.
 

>
  C:\c>tm gcc bignum.c -shared -s -obignum.dll
  TM: 0.31
>
  C:\c>tm gcc bignum.c -shared -s -obignum.dll -O2
  TM: 0.83
>
  C:\c>tm gcc bignum.c -shared -s -obignum.dll -O3
  TM: 0.93
>
  C:\c>dir bignum.dll
  21/06/2024  11:14            35,840 bignum.dll

 Any build time under a second is as good as instant.
 I tested on a real project, not a single file.  It has 158 C files and about 220 header files.  And I ran it on my old PC, without any "tricks" that you dislike so much, doing full clean re-builds.  The files are actually all compiled twice, building two variants of the binary.
 With -O2, it took 34.3 seconds to build.  With -O1, it took 33.4 seconds.  With -O0, it took 30.8 seconds.
 So that is a 15% difference for full builds.  In practice, of course, full rebuilds are rarely needed, and most builds after changes to the source are within a second or so.

Then there's something very peculiar about your codebase.
Either there's disproportionate percentage of declarations compared to executable code (like my tests with headers).
Or a big chunk of the source either contains lots of redundant code, or generates such code, or maybe conditional code, that is eliminated before it gets to the optimising stages.
My own test show a different pattern. First for Lua sources (32 .c files):
   C:\luac>tm gcc @luafiles
   TM: 7.71
   C:\luac>tm gcc @luafiles -O3
   TM: 16.97
This project uses lots of macros. Then Malcolm's resource compiler (43 .c files):
   C:\bbx\src>tm gcc @gfiles
   TM: 10.66
   C:\bbx\src>tm gcc @gfiles -O3
   TM: 28.87
That is itself unusual in that 80% of the line count is data.
This is one of the sub-programs of LibJPEG (54 .c files):
   C:\jj>tm gcc @cjpeg
   TM: 7.69
   C:\jj>tm gcc @cjpeg -O3
   TM: 18.01
Pico C (22 files):
   C:\pico>tm gcc @pico
   TM: 3.25
   C:\pico>tm gcc @pico -O3
   TM: 5.62
Tiny C (one file):
   C:\tcs>tm gcc tcc.c
   TM: 3.03
   C:\tcs>tm gcc tcc.c -O3
   TM: 13.06
The difference looks more than 15% to me. More like 70% to 170%, not including that last one, which is 330%, as you don't like programs in one file.
Yet, that particular app *is* one file. If working with that, you don't have a choice.