Potential of a compiler that creates the executable at once

[rempas]

On Saturday, 12 February 2022 at 11:04:48 UTC, forkit wrote:
>
> Yeah .. users... erh...
>
> .. but compiler writers are a different breed all together.
>
> (well, they used to be anyway)
>
> It used to be, that the golden rule of compiler writers was 
> "performance is (almost) everything".
>
> i.e.
>
> - Compile time performance -> how long it takes to generate 
> code.
>
> - Runtime performance -> how fast that code runs.
>
> (Almost) nothing else used to matter (to compiler writers)
>
> Why almost? Cause in the end, you need accurate results more 
> than you need speed.
>
> (ref: Expert C Programming -  P van der Linden 1994)
>
> I see the performance of (other) compilers these days, and I 
> wonder.. what ever happened to that bread of compiler 
> writers... from long ago...

Makes total sense to me. It's the same way people choose Python 
(or C++ or Rust or JS or whatever) over C because runtime 
performance is not the only thing that matters. Development speed 
matters too. Super fast compilation times will allow the dream of 
Gentoo, *BSD to become true and everyone will be able to compile 
everything from source with all the advantages this offers.

Another thing to mention is that I was also obsessed with the 
compiler that generates that code that "runs faster" in the past 
but then I realized something. Runtime performance is a really 
really really complicated topic! First of all, runtime 
performance may not (and probably will not) be very critical 
every time to begin with. But development time will always show!

A compile that generates my code fast and allows me to 
save-and-run as much as I can, a compiler that manages the memory 
for me because I will make mistakes as I'm human, a compile that 
does immutability be default (because again humans make mistakes) 
a compiler that will allow me to express myself the way I want 
and focus all my time to actually solve the program rather than 
find a way to bypass the languages limitations etc. THIS IS what 
matters the most!

Even when the runtime performance will be important, the 
optimizations that they compiler will do will mostly not offer 
you more than 20% runtime performance so what you should do is 
either use faster algorithms and/or change the design of your 
program (and maybe remove some unnecessary features). I finally 
understand that now! I don't chase pure raw compiler optimization 
runtime performance but good/smart program designs! Of course, I 
want my compiler to not generate unnecessary instructions but 
again, MY design is what will make the program faster.

Unfortunately, we live in a generation where people are OBSESSED 
with numbers! Ignoring their meaning and what's behind them! I 
don't want to see big words too! I have learned and I'm still 
learning day by day and I'm (hopefully) getting better!

> Luckily, we still have one of them.

We have a couple of people that think this way. Which one do you 
refer to?