On Friday, 11 February 2022 at 22:08:57 UTC, H. S. Teoh wrote:
> On Fri, Feb 11, 2022 at 08:23:10PM +0000, rempas via Digitalmars-d wrote:
>> > [...]
> [...]
>> [...]
> [...]
>
> It's not that it's *hard*.  It's pretty straightforward, and everybody knows what it means.
>
> The problem is the mostly-unfounded *interpretations* that people put on it.
>
> In the bad ole days, LoC used to be a metric used by employers to measure their programmers' productivity. (I *hope* they don't do that anymore, but you never know...)  Which is completely ridiculous because the amount of code you write has very little correlation with the amount of effort you put into it. It's trivial to write 1000 lines of sloppy boilerplate code that accomplishes little; it's a lot harder to write condense that into 50 lines of code that does the same thing 10x faster and with 10% of the memory requirements.

That's why I told earlier that OpenHUB is old trash. Their estimation [for DMD](https://www.openhub.net/p/dmd/estimated_cost), based on model from **the late 70's**

On 2/11/2022 11:44 PM, rempas wrote:
> THANK YOU!!! Every compiler needs that even if they can output binary formats directly (TCC I'm talking to you!) because it is easier to see the assembly rather than imagine the instructions in your head as humans are know to make mistakes. Thank you for adding this Walter!

You're quite welcome!

On 2/12/2022 12:08 AM, rempas wrote:
>> The only thing it has really failed at is the x87, which everyone wants to leave behind anyway.
> Why, what was bad about it? Can I get a little of background on this one?

It doesn't assign variables to x87 registers. The reason it doesn't is because the x87 is a stack machine, meaning the registers all shift position.

There is a way to fix that by using FXCH instructions, but I never got around to doing that.

On Saturday, 12 February 2022 at 09:00:18 UTC, Walter Bright wrote:
>
> It doesn't assign variables to x87 registers. The reason it doesn't is because the x87 is a stack machine, meaning the registers all shift position.
>
> There is a way to fix that by using FXCH instructions, but I never got around to doing that.

Thanks for the info! Yeah, agree with you! It seems why should all forget about x87 then.

On Thursday, 10 February 2022 at 22:52:45 UTC, Walter Bright wrote:
> On 2/10/2022 2:06 PM, Dave P. wrote:
>> Undefined symbols for architecture arm64:
>>    "__D7example9some_funcFiZi", referenced from:
>>        __D7example3fooFiZi in example.o
>>        __D7example3barFiZi in example.o
>>        __D7example3bazFiZi in example.o
>>        __D7example3quxFiZi in example.o
>>        __Dmain in example.o
>> ld: symbol(s) not found for architecture arm64
>
> Things I have never been able to explain, even to long time professional programmers:
>
> 1. what "undefined symbol" means
>
> 2. what "multiply defined symbol" means
>
> 3. how linkers resolve symbols
>
> Our own runtime library illustrates this bafflement. In druntime, there are these "hooks" where one can replace the default function that deals with assertion errors.
>
> Such hooks are entirely unnecessary.
>
> To override a symbol in a library, just write your own function with the same name and link it in before the library.
>
> I have never been able to explain these to people. I wonder if it is because it is so simple, people think "that can't be right". With the hook thing, they'll ask me to re-explain it several times, then they'll say "are you sure?" and they still don't believe it.

I absolutely don’t want my executable defined by the order things happen to appear on the linker command line. I don’t want that incidentally and I don’t want to do it deliberately. The boat sailed on this long ago, I just want everything to be in the executable please with errors on duplicates, unless it’s dead code.

Same goes for import paths btw. I don’t want imports selected based on the order of import paths, I want hard errors on any duplication of fully-qualified modules.

D has amazing compile-time features for deciding what to compile or not, what to call and not. I want to use those, not rely on the details of how I cobble together my build (or how some automated tool does it for me).

On Saturday, 12 February 2022 at 08:12:03 UTC, rempas wrote:
>
> Funny enough there are people that don't care about compilation speed and are willing to have their project compile even twice as fast for 5% runtime performance. The same people of course don't have any problem using Python in other cases...

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

Luckily, we still have one of them.

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?

On Saturday, 12 February 2022 at 11:04:48 UTC, forkit wrote:
> ...
>
> I see the performance of (other) compilers these days, and I wonder.. what ever happened to that bread of compiler writers... from long ago...
>

They went on to create Eiffel, Delphi, .NET, Java, V8, GraalVM (nee Maxime), OCaml, Go and Dart.

On Sat, Feb 12, 2022 at 07:51:38AM +0000, forkit via Digitalmars-d wrote: [...]
> That's the primary reason I became interested in D - the speed of compilation, using dmd.
[...]
> I don't care how great a programming language is, slow compilation is a real turn off!
> 
> Hooray for dmd!!

I use dmd for the code-compile-test cycle because of the fast turnaround. For small programs dmd is so fast it's almost like programming in a scripting language(!). For larger programs it's less so, but still impressively fast for compile times.

Runtime performance of executables compiled by dmd, however, is a disappointment.  I consistently get 20%-40% runtime performance improvement by compiling with ldc/gdc, esp. for CPU-intensive programs.

So my usual workflow is dmd for code-compile-test, ldc -O2 for release builds.


T

-- 
Amateurs built the Ark; professionals built the Titanic.

On Saturday, 12 February 2022 at 07:13:15 UTC, Walter Bright wrote:
> On 2/11/2022 6:52 AM, max haughton wrote:
>> The object emission code in the backend is quite inefficient,
>
> It's faster than any other compiler.
>
>> it needs to be rewritten (it's horrible old code anyway)
>
> I suppose that depends on what you're used to. The basic design is pretty simple - there's a code gen function for each expression node type. The optimizer uses standard data flow analysis math. There's a separate pass for register allocation, and one for scheduling.
>
> The design was originally written for the 8086. It survived extension to 32 bits, then 64 bits, then SIMD.
>
> The complexity comes from the complexity of the x86 instruction set and the choice of instructions is very dependent on the shape of the expression trees.
>
> The only thing it has really failed at is the x87, which everyone wants to leave behind anyway.

I'm specifically talking about the file that handles elf files, it's very messy and uses some absolutely enormous structs which are naturally very slow by virtue of their size.