Re: question about linker

On 05/12/2024 15:46, David Brown wrote:

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?

Suppose your full clean build took, if not 0 seconds, but as close as made no difference. WHY would you waste time mucking with partial builds?

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.

It IS slower. And mine isn't the fastest either. On one test from 3-4 years ago spanning 30-40 language implementatations, there was about 3000:1 between fastest and slowest expressed as Kloc/sec. My two languages were 8 and 4 times slower than the fastest.
On another more substantial test, the difference was 80000:1 (the slow product then - not gcc - has since gotten much better).
gcc's -O0 and -O3 timings tended to somewhere be in the middle.
Such tests may expose weaknesses in these compilers that are worth looking at. It certainly did in mine.

  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.)

You keep saying I'm wrong; I don't often say that you're wrong, but here you are because you keep choosing to disregard certain facts.
One is that a make system DOES do multiple things, but one of those IS applying dependency info to decide which modules to incrementally compile, when is then linked with existing object files into a binary.
THIS is exactly what my whole-program compiler takes care of. It doesn't eliminate everything else a make system does, but I don't make use of those myself.
Another is that you refuse to acknowledge genuine use-cases for fast C compilers. A big one is when C is used an intermediate language for a compiler. Then it just wants as fast a translation into runnable code as possible. It doesn't need detailed analysis of the C code.
It would also be nice for that compiler to be simple enough to bundle as part of the app. That is not really practical to do with gcc if your intention is a reasonably small and tidy implementation, apart from edit-run cycles being dominated by the slowness of gcc in producing even indifferent code.
Such intermediate C may present challenges: it might be very busy. It might be generated as one C source file. That shouldn't matter.
But you seem to be blind to these possibilties, and stubbornly refuse to admit that a product like tcc may actually be a good fit here.
Some options for a backend for a new language might be to interpret the result, but even tcc's terrible mcode would run a magnitude faster at least.
   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.

What about someone whose workload is 10 times yours? Their builds will take 10 times as long on the same machine. They would be helped by faster compilers.
BTW nothings stops my compiler being run on multiple cores too. I assume that is a function of your 'make' program?
However the non-C one would need to build multiple executables, not object files. As a whole-program compiller can't easily be split into parallel tasks.
So I'm looking only at raw compilation speed on one core.
Car analogy: if you were developing a fast car, and wanted one that could do 200 miles in one hour, using 10 different cars each travelling at 20mph along a different segment of the route wouldn't be what most people had in mind.

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.

Ha!

  Few users are bothered about $0.10 worth of disk space.)

And again you fail to get point. Disk space could be free, but that doesn't mean a 1GB or 10GB executable is desirable. It would just be slow and cumbersome.
Car analogy #2: supposed a 40-tonne truck cost the same as 1-tonne car. Which do you think would be quicker to drive to the supermarket and back?