Re: question about linker

On 05/12/2024 18:42, Bart wrote:

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?
 

As Tim said elsewhere, if things were different they wouldn't be the same.
But I would still use "make" regardless of the speed of compilation. And I'd still set up my makefiles to compile files as needed, and not when not needed.  And I'd still have makefiles that were safe for parallel compilation (though it's possible that I'd be lazy and type "make" instead of "make -j 20").
How do I know I would do that?  Because that is what I have done in the past.  It's what I have been doing since I first started programming professionally.  It's what I do for assembly projects (though it's a long time since I have done a pure assembly project).  It's what I've done with small C projects that did not take more than a second or so for a full clean build.
I think you have some bizarre idea that it is difficult to have a build tool that handles dependency-based compilation or parallel builds.  It is not.  It is a natural feature for pretty much any build tool. Optimising the build to get an absolute minimum of unnecessary compilations can be an effort, but a basic arrangement of re-compile if the C file changes or any header changes is peanuts.
And I think you also misunderstand a major point of a build tool.  It describes how the project is build - you use the build tool and its configuration to ensure that you can build the end product correctly, in a repeatable manner.  Details vary according to need, but it might hold the source files, library information, compiler details, flags, pre-compilation requirements, post-compilation scripts, configure information, installation information, test cases, documentation builds, etc.  For my work, I usually have very specific choices of the toolchain to use - that is detailed in the makefile, along with all the flags. After a build, I might take the executable and manipulate it (like adding checksums), rename it, pack it up or make it ready for a download tool.  I might have build goals like "make download", "make test", "make debug", "make release".  Putting all this kind of thing in a build tool is massively better than just documenting it somehow.
So I'd use that "make" for all of that, totally regardless of how fast the compiler is.
And I think you forget that for a great many people, the build tool is just their IDE.  The use MSVC, or Eclipse, or whatever, and do their project setup with checkboxes and other options.  Building is done by choosing "build" from the menu or using a shortcut key, and dependency handling is automatic.  I prefer to keep my builds independent of any IDE, but that's my choice.  For people using IDE's for project management, it is almost impossible to avoid dependency-based builds - you have to go out of your way to get full clean re-builds.
(And the things I talk about with "make" can be done with cmake, ant, bake, or whatever build system you choose to use.)

 

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.

For a file that can be compiled by your tools, and also by gcc, then a your tool will compile it faster - I don't think anyone doubts that. But you put a great deal of effort into trying to show that /using/ gcc is slower for project builds - I have demonstrated that this is simply not the case.  If gcc was as fast as your compiler, it would not appreciably change the typical build time for my development, and it would not change the way I work or the makefiles I use in any way.
Please try to understand that.

  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.

You /are/ wrong here - see my explanation above.

 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.

I have yet to see one of significance.

A big one is when C is used an intermediate language for a compiler.

Why would that be relevant?  If you compile language X by first transpiling to C, then compiling C, then the time to compile language X is the sum of these.  A fast or slow C compiler is no more and no less relevant here than if you were just compiling C.

Then it just wants as fast a translation into runnable code as possible. It doesn't need detailed analysis of the C code.

Of course it needs a detailed analysis of the C code if the result is intended to be efficient - that's part of the optimisation.  And static error checking is close to free when you have optimisation enabled anyway.
I can accept that you might not necessarily be as concerned about efficient resulting code.  But I don't see any reason why you'd be more concerned about the speed of the C compiler here than you would when developing in C.

 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.

That depends on the application.  You are unlikely to have interest in C as a scripting language for an application unless it was already a C-related application or a really big and powerful system where fast plugins are relevant.  In those circumstances, you'd probably use the library versions of clang/llvm - making your big application bigger. (Or if the application was for a sensible OS, it would share an installation of the compiler with the rest of the system.)  Applications that bundle languages for scripting mostly use something like Lua if they are small, Python or TCL if they are bigger.

 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.
 

The discussion here, as I understand it, is primarily about C programmers developing programs in C.  That is my focus.

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.
 

As I have repeated countless times, of course big builds go faster with faster compilers.  That is not the point.  The point is that development of C projects is rarely hampered by the speed of real C compilers.
My typical builds are 2-3 seconds.  If the project was ten times the size, typical builds would probably be around 5 seconds.  I don't give a *beep* how long a full clean build would take, because I don't typically do full clean builds.
If the project was a hundred times bigger, we would have a large department working on it at a time and would use distributed builds with a common big fast build server, and again the typical build times would be short.
Other aspects of development - such as regression testing or simulations, or running extensive cross-module static checking, or building LTO links - can take a long time.  Sometimes they can take /very/ long time.  Sometimes you can alleviate that by spending enough money on hardware, sometimes even then it is still slow.
But if your normal builds - the compilation parts - of C code are slow enough to be a hinder to your development, you are probably doing something wrong.  And the solution is to look at what you are doing, and figure out how to fix it.  Changing to crappy tools is not the answer.

BTW nothings stops my compiler being run on multiple cores too. I assume that is a function of your 'make' program?

It is a function of using any kind of build system worth its salt.  And I would be surprised if your compiler couldn't be invoked multiple times simultaneously.

 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.
 

And that is why you end up with meaningless results.  You are comparing one car going at 200 mph with 1000 buses going at 20 mph when trying to evacuate a city in the path of a tornado.  (Sorry, the car analogy is really breaking down here.)

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.
 

Get yourself a computer from this century.

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?
 

In this analogy, gcc is the 40 tonne truck for the heavy work.  The car to the supermarket is Python - that's good for the quick and simple work.
There is no place where the home-made go-kart is useful, except perhaps for a fun and dangerous ride.