Re: Baby X is bor nagain

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? For me, optimised options with gcc always take longer:
  C:\c>tm gcc bignum.c -shared -s -obignum.dll        # from cold
  TM: 3.85
  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
Optimising takes nearly 3 times as long. But this is a single small module of 1600 lines.
Where optimisation makes no difference is when compiling lots of declarations:
   C:\c>type w.c
   #include <windows.h>
   int main(void) { MessageBox(0,"World", "Hello", 0); }
   C:\c>tm gcc -s w.c
   TM: 1.39
   C:\c>tm gcc -s w.c -O3
   TM: 1.41
It is these big headers belonging to large libraries that can affect build-times, even compiling only one module. (I can't compare with tcc here since it uses its own smaller windows.h; I'd have to compare with libraries like gtk2.h, which is 0.35M lines of unique declarations in hundreds of headers.)
With my own usage where gcc is used to build one large file, then the difference is stark, and very noticeable:
   C:\qx52>tm gcc -s qc.c -oqc.exe -O0
   TM: 2.17
   C:\qx52>tm gcc -s qc.c -oqc.exe -O1
   TM: 5.31
   C:\qx52>tm gcc -s qc.c -oqc.exe -O2
   TM: 10.98
   C:\qx52>tm gcc -s qc.c -oqc.exe -O3
   TM: 13.60
   C:\qx52>tm mm qc -opt                (my normal compiler)
   Compiling qc.m to qc.exe
   TM: 0.09
Compared with using my usual compiler, if I wanted to benefit from gcc's optimisation, then building it takes 150 times longer.
And this is, by your own standards which are constantly beating me about the head with, for a toy application. Although it is still 0.5MB:
   C:\qx52>mm qc -opt -v -rip
   Compiling qc.m to qc.exe
   Code size:     220,587 bytes
   Idata size:    327,184
   Code+Idata:    547,771
   Zdata size:  5,343,544
   EXE size:      553,472
(gcc -O3 produces a 765KB file, -O0 a 698KB one, and even -Os a 572KB one, but that took it 8 seconds. My code could be reduced further in size, but it's a low priority.
Note: my EXE is for low-loading images. A high-loading one (option -himem) is 4KB bigger, but needs also extra flags to force the OS to load it high. All gcc results are for high-loading.)