Re: Baby X is bor nagain

On Mon, 24 Jun 2024 17:51:25 +0100
bart <bc@freeuk.com> wrote:

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.
>

Here is compile time only, serial. It is only few seconds faster than
non-parallel make:
-O0 0m21.761s
-Os 0m24.227s
-O1 0m23.384s
-O2 0m24.601s
-O3 0m25.256s
O2/O0= 1.13

It could be probably up to 1.5x faster if I call compiler with more
than one source file at time, but then it would be too different from
our normal workflow.

Here are 3 biggest modules (Option/time(second)/text sise):
module 0:

module A
-O0 0.250 58444
-Os 0.530 29760
-O1 0.390 37368
-O2 0.530 34128
-O3 0.671 50104

module B
-O0 0.250 32680
-Os 0.343 25840
-O1 0.296 26452
-O2 0.343 26992
-O3 0.343 27672

Module C
-O0 0.296 37648
-Os 0.437 25976
-O1 0.390 28168
-O2 0.468 27784
-O3 0.515 32556

The biggest module (module A), absolutely not co-incidentally was not
written by us. It is purchased from Jean Labrosse, who is smart guy and
good businessman, but his ideas of software engineering are best
described as eccentric.
Other big modules are dispatchers: they receive messages from command
line/telnet (Module 2) and HTTP (module 3) and either handle simple
cases by themselves or in more typical and more complex cases call
outside modules to do the job. So while they are big, they consist of
big number of independent pieces. As you see, this sort of bigness does
not produce particularly big -O2/-O0 ratios.

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?

I don't know. Probably 70-80% of total text

What is the data size?
>

Initialized data and read-only data? Not big. 23 KB. bss is
significantly bigger (2.8 MB), but I don't see how size of bss is
possibly relevant.

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:
 

One big file is not quite obviously special case.

   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.