Re: else ladders practice

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