Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Mon, 24 Jun 2024 20:41:31 +0300
Organization: A noiseless patient Spider
Lines: 162
Message-ID: <20240624204131.000029bd@yahoo.com>
References: <v494f9$von8$1@dont-email.me>
	<v49seg$14cva$1@raubtier-asyl.eternal-september.org>
	<v49t6f$14i1o$1@dont-email.me>
	<v4bcbj$1gqlo$1@raubtier-asyl.eternal-september.org>
	<v4bh56$1hibd$1@dont-email.me>
	<v4c0mg$1kjmk$1@dont-email.me>
	<v4c8s4$1lki1$4@dont-email.me>
	<20240613002933.000075c5@yahoo.com>
	<v4emki$28d1b$1@dont-email.me>
	<20240613174354.00005498@yahoo.com>
	<v4okn9$flpo$2@dont-email.me>
	<v4p37r$k32n$1@dont-email.me>
	<v4pei3$m5th$2@dont-email.me>
	<v4plsk$nn9o$2@dont-email.me>
	<v4pnq6$o4fs$1@dont-email.me>
	<v4q245$si2n$1@dont-email.me>
	<v4q2rl$sqk3$1@dont-email.me>
	<v52308$2nli8$3@dont-email.me>
	<v53i4s$33k73$2@dont-email.me>
	<v53lf7$34huc$1@dont-email.me>
	<v53vh6$368vf$1@dont-email.me>
	<v54se1$3bqsk$1@dont-email.me>
	<20240624160941.0000646a@yahoo.com>
	<v5bu5r$va3a$1@dont-email.me>
	<20240624181006.00003b94@yahoo.com>
	<v5c86d$11ac7$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 24 Jun 2024 19:41:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a033234f5eaff00d281aad432da64e4a";
	logging-data="1097294"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+knWSgvXATddFMD/RI3J8y5YadfyAa4Sw="
Cancel-Lock: sha1:AOFnGPR9F8ibXAL7sqUigr5IIlw=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 7105

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
========== REMAINDER OF ARTICLE TRUNCATED ==========