Re: question about linker

On 05/12/2024 04:11, Waldek Hebisch wrote:

David Brown <david.brown@hesbynett.no> wrote:

On 04/12/2024 16:09, Bart wrote:

On 04/12/2024 09:02, David Brown wrote:

On 03/12/2024 19:42, Bart wrote:

>

Yesterday you tried to give the misleading impression that compiling a
substantial 200Kloc project only took 1-3 seconds with gcc.
>

>
No, I did not.  I said my builds of that project typically take 1-3
seconds.  I believe I was quite clear on the matter.

 Without word "make" it was not clear if you mean full build (say
after checkout from repository).  Frequently people talk about re-making
when they mean running make after a small edit and reserve build
for full build.  So it was not clear if you claim to have a compile
farm with few hundred cores (so you can compile all files in parallel).

I talk about "building" a project when I build the project - produce the relevant output files (typically executables of some sort, appropriately post-processed).
If I wanted to say a "full clean build", I'd say that.  If I wanted to include the time taken to check out the code from a repository, or to download and install the toolchain, or install the OS on the host PC, I'd say that.
When I am working with code, I edit some files.  Then I build the project.  Sometimes I simply want to do the build - to check for static errors, to see the size of code and data (as my targets are usually resource limited), etc.  Sometimes I want to download it to the target and test it or debug it.
/Why/ would anyone want to do a full clean build of their project? There are a number of good reasons - such as checking that everything works on a different host computer, or after updating tools, or because you have a somewhat limited build setup that can't handle changing header usage automatically.  Fair enough - but that's not a typical build, at least not for me.
(The fact that I use "make" - far and away the most common build tool - is irrelevant.  Much the same would apply with any other build tool.)
Bart is not interested in how much time it takes for people to build their projects.  He is interested in "proving" that his tools are superior because he can run gcc much more slowly than his tools.  He wants to be able to justify his primitive builds by showing that his tools are so fast that he doesn't need build tools or project management.  (He is wrong on all that, of course - build tools and project management is not just about choosing when you need to compile a file.)  Thus he also insists on single-threaded builds - compiling one file at a time, so that he can come up with huge times for running gcc on lots of files.  This is, of course, madness - multi-core machines have been the norm for a couple of decades.  My cheap work PC has 14 cores and 20 threads - I'd be insane to compile one file at a time instead of 20 files at a time.

 

If I do a full, clean re-compile of the code, it takes about 12 seconds
or so.  But only a fool would do that for their normal builds.  Are you
such a fool?  I haven't suggested you are - it's up to you to say if
that's how you normally build projects.
>
If I do a full, clean re-compile /sequentially/, rather than with
parallel jobs, it would be perhaps 160 seconds.  But only a fool would
do that.

 Well, when I download a project from internt the first (ant frequently
the only compilation is a full build). 

That is not development, which is the topic here.

And if build fails, IME
to is much harder to find problem from log of parallel build.
So I frequently run full builds sequentially.  Of course, I find
something to do when computer is busy (300sec of computer time
spent on full build is not worth extra 30 seconds to find trouble
in parallel log (and for bigger things _both_ times grow so
conclusion is the same)).
 

That does not sound to me like a particularly efficient way of doing things.  However, it is presumably not something you are doing countless times while working.  And even then, the build time is only a small proportion of the time you spend finding the project, reading its documentation, and other related tasks.  It's a one-off cost.

I gave some timings that showed gcc-O0 taking 50 times longer than tcc,
and 150 times longer with -O2.
>
That is the real picture. Maybe your machine is faster than mine, but I
doubt it is 100 times faster. (If you don't like my benchmark, then
provide another in portable C.)
>
All this just so you can crap all over the benefits of small, faster,
simpler tools.

>
Your small, fast, simple tools are - as I have said countless times -
utterly useless to me.  Perhaps you find them useful, but I have never
known any other C programmer who would choose such tools for anything
but very niche use-cases.
>
The real picture is that real developers can use real tools in ways that
they find convenient.  If you can't do that, it's your fault.  (I don't
even believe it is true that you can't do it - you actively /choose/ not
to.)
>
And since compile speed is a non-issue for C compilers under most
circumstances, compiler size is /definitely/ a non-issue, and
"simplicity" in this case is just another word for "lacking useful
features", there are no benefits to your tools.

 I somewhat disagree.  You probaly represent opinion of majority of
developers.  But that leads to uncontrolled runaway complexity and
bloat. 

You misunderstand.
The speed of C compilation is a non-issue for almost all C programmers. A reason for that is that it /is/ an issue to some - in particular, to compiler developers.  The gcc developers care about the speed of gcc - and because of that, I don't have to care.  (To be accurate, they care mostly about the speed of C++ compilation, because that is often a lot more relevant to developers.  C often just gets the benefits as a side-effect.)

You clearly see need to have fast and resonably small code
on your targets.  But there are also machines like Raspberry Pi,
where normal tools, including compilers can be quite helpful.
But such machines may have rather tight "disc" space and CPU
use corresponds to power consumption which preferably should be
low.  So there is some interest and benefits from smaller, more
efficient tools.

Raspberry Pi's have no problem at all running native gcc.
It is certainly true that not all programs need to be small and fast. In fact, the great majority of programs do not need to be small and fast.  Thus for the great majority of programs, C is the wrong language to use.  You want something with a better balance of developer efficiency, features and run-time safety.
There can, of course, be circumstances where C is the right language even though code efficiency is irrelevant - but for most code for which C is the best choice, efficiency of the results is important.

 OTOH, people do not want to drop all features.  And concerning
gcc, AFAIK is is actually a compromise for good reason.  Some
other projects are slow and bloated apparenty for no good
reason.  Some time ago I found a text about Netscape mail
index file.  The author (IIRC Jame Zawinsky) explained how
it fastures ensured small size and fast loading.  But in
later developement it was replaced by some generic DB-like
solution leadind to huge slowdown and much higher space
use (apparently new developers were not willing to spent
a litte time to learn how old code worked).  And similar
examples are quite common.
 And concerning compiler size, I do not know if GCC/clang
developers care.  But cleary Debian developers care,
they use shared libraries, split debug info to separate
packages and similar to reduce size.
 

The more a program is used, the more important its efficiency is.  Yes, gcc and clang/llvm developers care about speed.  (They don't care much about disk space.  Few users are bothered about $0.10 worth of disk space.)