Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: antispam@fricas.org (Waldek Hebisch)
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Sun, 1 Dec 2024 13:04:30 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vihmss$29jun$2@paganini.bofh.team>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>   <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> <via21q$ib2v$2@dont-email.me>
Injection-Date: Sun, 1 Dec 2024 13:04:30 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="2412503"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 3629
Lines: 52

Bart <bc@freeuk.com> wrote:
> 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.

Even in context of developing a compiler I would not run blindly
many compiliations of large file.  At first stage I would debug
compiled program, to find out what is wrong with it.  That normally
involves several runs of the same executable.  Possible trick is
to compile each file separately and link files in various
combionations, some compiled by gcc, some by my compiler.
Normally that would locate error to a single file.

After that I would try to minimize the testcase, removing code which
do not contribute to the bug.  That involves severla compilations
of files with quickly decreasing sizes.

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

The simple answer is: users tolerate long compile time.  If users
abandoned 'gcc' to some other compiler due to long compile time,
then 'gcc' developers would notice.  But the opposite has happened:
'llvm' was significantly smaller and faster but produced slower code.
'llvm' developers improved optimizations in the process making
their compiler bigger and slower.

You need to improve your propaganda for faster C compilers...

-- 
                              Waldek Hebisch