Re: Baby X is bor nagain

On 24/06/2024 16:10, Michael S wrote:

On Mon, 24 Jun 2024 15:00:26 +0100
bart <bc@freeuk.com> wrote:

 

Your processor has a CPU-mark double that of mine, which has only two
cores, and is using one.
>
Building a 34-module project with .text size of 300KB, with either
gcc 10 or 14, using -O0, takes about 8 seconds, or 37KB/second.
>

 But my project has much more than 34 modules. 164 modules compiled
during build + several dozens in libraries.

Does that matter? My example is a smaller project, but I'm comparing the rate of compilation not total time.
If you want a bigger example, yesterday I posted one involving 140 .c files, total EXE size is 5MB (don't know .text as this is ELF format).
-O2 took just over twice as long as -O0.
But I guess every single example I come up with is 'exceptional'. Maybe what's exceptional is that I measuring the runtime of the compiler, and not all sorts of other junk.
You might claim that that other junk is necessary for the the build; I'd dispute that.

Your figures show about 50KB/second.

 text KB/second is hardly a good measure, esp. considering that we are
talking about different architectures. Mine is Altera Nios2 - 32-bit
RISC processor very similar to MIPS. The code density for this
architecture is significantly lower than on ARMv7 or x386 and even
somewhat lower than x86-64 and ARM64. The exact ratio depends on the
project, but 15-20% would be typical.
Also, part of text are libraries that we not compiled during this build.
But I would think that your .text size also includes libraries.

So, what is the total size of the code that is produced by the compilation? What is the data size?

I really don't believe it. And you should understand that it doesn't
add up.
>

 I am not lying.

I'm not saying that. I'm disputing that -O2 adds only 10% compared to -O0 when running only gcc.
  I am pretty sure that DavidB also tells truth.

I recommend to try to compile your C compiler with gcc.

My C compiler is not written in C. I can transpile to C, but then it would be a single large C file, which puts pressure on the optimiser:
   C:\cx>mc -c cc              # transpile to C
   Compiling cc.m to cc.c
   C:\cx>tm gcc cc.c           # -O0 build
   TM: 1.92
   C:\cx>tm gcc cc.c -O2
   TM: 9.22
It takes 380% longer compared with -O0. However the advantage is that I now have a whole-program optimised application. But this is not something I need to do routinely (maybe on production versions or running benchmarks).
Most of the time I don't need the optimised code (which is only about 40% faster) and can build like this:
   C:\cx>tm mm cc
   Compiling cc.m to cc.exe
   TM: 0.06
(If mm.exe is similarly boosted by via gcc, otherwise it takes 0.08s.)
So optimisation for this product take 150 times, or 15,000%, longer.
DB was however saying that he normally has optimisation turned on. Well I'm not surprised if turning it off makes only 11% difference! But he is not interested in super-fast builds such as those I work on.
Note that that 0.06 figure is for rebuilding my C compiler from scratch (200KB .text size, 300KB EXE size.), and 1/3 of it is Windows process overheads. Accurately measuring build-times when timings are near zero is difficult.