Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Mon, 24 Jun 2024 17:51:25 +0100
Organization: A noiseless patient Spider
Lines: 94
Message-ID: <v5c86d$11ac7$1@dont-email.me>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 24 Jun 2024 18:51:26 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b9ae78d5a8a2c8822d3975b378ef6e69";
	logging-data="1091975"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+KwnvWyZfaEqAjrttPiqXA"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:hDUk6G2oeUqfnk+eJ7p3aHIzBcM=
In-Reply-To: <20240624181006.00003b94@yahoo.com>
Content-Language: en-GB
Bytes: 5220

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.