Deutsch   English   Français   Italiano  
<via21q$ib2v$2@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!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: else ladders practice
Date: Thu, 28 Nov 2024 15:25:48 +0000
Organization: A noiseless patient Spider
Lines: 70
Message-ID: <via21q$ib2v$2@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <vg37nr$3bo0c$1@dont-email.me> <vg3b98$3cc8q$1@dont-email.me>
 <vg5351$3pada$1@dont-email.me> <vg62vg$3uv02$1@dont-email.me>
 <vgd3ro$2pvl4$1@paganini.bofh.team> <vgdc4q$1ikja$1@dont-email.me>
 <vgdt36$2r682$2@paganini.bofh.team> <vge8un$1o57r$3@dont-email.me>
 <vgpi5h$6s5t$1@paganini.bofh.team> <vgtsli$1690f$1@dont-email.me>
 <vhgr1v$2ovnd$1@paganini.bofh.team> <vhic66$1thk0$1@dont-email.me>
 <vhins8$1vuvp$1@dont-email.me> <vhj7nc$2svjh$1@paganini.bofh.team>
 <vhje8l$2412p$1@dont-email.me> <86y117qhc8.fsf@linuxsc.com>
 <vi2m3o$2vspa$1@dont-email.me> <86cyiiqit8.fsf@linuxsc.com>
 <vi4iji$3f7a3$1@dont-email.me> <86mshkos1a.fsf@linuxsc.com>
 <20241128143715.00003565@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 28 Nov 2024 16:25:47 +0100 (CET)
Injection-Info: dont-email.me; posting-host="033a1fb1a70fe4f5596322438ef79f57";
	logging-data="601183"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+/b4rnInbcDp5ZokEuObbi"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:rxXe1UH2YqPWfSEtg7KvOFMYGNA=
In-Reply-To: <20241128143715.00003565@yahoo.com>
Content-Language: en-GB
Bytes: 4359

On 28/11/2024 12:37, Michael S wrote:
> On Wed, 27 Nov 2024 21:18:09 -0800
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> 

>>>    c:\cx>tm gcc sql.c            #250Kloc file
>>>    TM:  7.38
>>
>> Your example illustrates my point.  Even 250 thousand lines of
>> source takes only a few seconds to compile.  Only people nutty
>> enough to have single source files over 25,000 lines or so --
>> over 400 pages at 60 lines/page! -- are so obsessed about
>> compilation speed.

> My impression was that Bart is talking about machine-generated code.
> For machine generated code 250Kloc is not too much.

This file mostly comprises sqlite3.c which is a machine-generated 
amalgamation of some 100 actual C files.

You wouldn't normally do development with that version, but in my 
scenario, where I was trying to find out why the version built with my 
compiler was buggy, I might try adding debug info to it then building 
with a working compiler (eg. gcc) to compare with.

But, yes, when I used to do more transpilation to C, then the generated 
code would be a single C source file. That one could also require 
frequent recompiles as C, if there were bugs in the process.

Then the differences in compile-time of the C are clear; here, 
generating qc.c from the original sources took 0.09 seconds:

c:\qx>tm gcc qc.c            GCC -O0
TM: 2.28

c:\qx>tm tc qc               TCC from a script as it's messy
c:\qx>tcc qc.c c:\windows\system32\user32.dll -luser32 
c:\windows\system32\kernel32.dll -fdollars-in-identifiers
TM: 0.23

c:\qx>tm cc qc               Using my C compiler
Compiling qc.c to qc.exe
TM: 0.11

c:\qx>tm mm qc               Compile original source to EXE
Compiling qc.m to qc.exe
TM: 0.09

c:\qx>tm gcc -O2 qc.c        GCC -O2
TM: 11.02

Usually tcc is faster than my product, but something about the generated 
C (maybe long, messy identifiers) is slowing it down. But it is still 10 
times faster than gcc-O0.

The last timing is gcc generating optimised code; usually the only 
reason why gcc would be used. Then it takes 120 times longer to create 
the executable than my normal native build process.

Tim isn't asking the right questions (or any questions!). WHY does gcc 
take so long to generate indifferent code when the task can clearly be 
done at least a magnitude faster?

Whatever it is it's doing, why isn't there an option to skip that for a 
streamlined build? (Maybe you accidentally deleted the EXE and need to 
recreate it; it doesn't need the same analysis.)

I've several times suggested that gcc should have an -O-1 option that 
runs a secretly bundled version of Tiny C.