On Friday, 5 June 2020 at 20:10:30 UTC, Andrei Alexandrescu wrote:
> It would be great if someone took a look at that.

Yeah, this is why when reducing bugs I often prefer to use `printf` or even `assert(0)` or `asm { int 3; }` since it does result in a lot less code generated.

BUT, in the context of a regular program, I caution against making too big a deal of this. Yes, there's more code than there needs to be *for this simple case*, but much of it exists to support real world code that is more complicated out of necessity.

People don't actually write "hello world" programs. It'd be amusing to have the compiler recognize the input pattern and output some hand-tuned perfectly assembly for it.... but it'd also be useless. Once you start writing slices instead of literals, or enums and structs instead of basic types, much of that code is useful anyway.

Not all of it, again, I know some of writeln's branches are horrible, and I personally think the wrapping through C's lib with additional thread safety on top of it is silly. But those decisions are all made for debatably good reasons and at the end of the day, is it worth worrying about 0.04s and 200 bytes on a hello world build?

On Fri, Jun 05, 2020 at 08:41:53PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
> On Friday, 5 June 2020 at 20:10:30 UTC, Andrei Alexandrescu wrote:
> > It would be great if someone took a look at that.
> 
> Yeah, this is why when reducing bugs I often prefer to use `printf` or even `assert(0)` or `asm { int 3; }` since it does result in a lot less code generated.

I guess YMMV and all that, but I find all the "unnecessary complications" of writefln eminently useful when debugging, esp. with the %(...%) format specs that can print ranges and can be nested. Very useful for one-line, throwaway debug dumps of range contents that doesn't require writing an entire function and range-interpretation framework just to get some miserable debug output, like you need to in C. With write(f)ln's "complications", you can just write a 1-line debug dump that you throw away after the next code-compile-debug cycle without thinking twice.


> BUT, in the context of a regular program, I caution against making too big a deal of this. Yes, there's more code than there needs to be *for this simple case*, but much of it exists to support real world code that is more complicated out of necessity.

Yes, we're blowing so much steam over a measly hello world program when larger, much more important issues lie unsolved.  Typical bikeshed vs. nuclear reactor situation. :-D


> People don't actually write "hello world" programs. It'd be amusing to have the compiler recognize the input pattern and output some hand-tuned perfectly assembly for it.... but it'd also be useless.
[...]

Even more amusing would be for the compiler to recognize the pattern, and launch a browser to some tutorial page on dlang.org explaining next steps to go after your hello world program runs. :-P

But yeah, also equally useless.


T

-- 
The peace of mind---from knowing that viruses which exploit Microsoft system vulnerabilities cannot touch Linux---is priceless. -- Frustrated system administrator.

On Friday, 5 June 2020 at 21:07:26 UTC, H. S. Teoh wrote:
> I guess YMMV and all that, but I find all the "unnecessary complications" of writefln eminently useful when debugging,

oh i agree, I like it when going through that process. writefln is p nice.

just at the *end* of the process, when it comes down to reducing the bug to the smallest thing so we can inspect the disassembly and report it upstream, then I avoid it.

On Fri, Jun 05, 2020 at 09:18:20PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
> On Friday, 5 June 2020 at 21:07:26 UTC, H. S. Teoh wrote:
> > I guess YMMV and all that, but I find all the "unnecessary complications" of writefln eminently useful when debugging,
> 
> oh i agree, I like it when going through that process. writefln is p nice.
> 
> just at the *end* of the process, when it comes down to reducing the bug to the smallest thing so we can inspect the disassembly and report it upstream, then I avoid it.

Well, if you're after the disassembly, assert(0) seems to be the ticket.
:-)


T

-- 
One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article "Giving it all away"

On 6/5/2020 1:41 PM, Adam D. Ruppe wrote:
> But those decisions are all made for debatably good reasons and at the end of the day, is it worth worrying about 0.04s and 200 bytes on a hello world build?

writeln() is a fundamental piece of Phobos, and should be done right.

Back in the olden days, Borland's C compiler didn't produce very good code. But Borland managed to still get good results by doing the basics right - they went all out on hand-optimizing the C standard library.

In particular, they implemented printf entirely in hand-optimized assembler. Since printf is used everywhere in C code, this paid of handsomely for Borland. AFAIK, they're the only C vendor that did this.

On Tuesday, 2 June 2020 at 06:47:54 UTC, Walter Bright wrote:
> Many people are trying to figure out what templates are blowing up their compile. This should help:
>
> https://github.com/dlang/dmd/pull/11208

Looks super useful.

I tried it on the test suite of openmethods and I see lots of duplicate entries, e.g.:

[...]
       2        1   setName(NewValue...)
       5        5   UnpackDeepImpl(U...)
     121       40   Parameters(func...) if (func.length == 1 && isCallable!func)
       8        8   UnpackDeepImpl(U...)
       2        2   argumentMixtureAt(int i)
       3        3   UnpackDeepImpl(U...)
       4        4   UnpackDeepImpl(U...)
       5        5   UnpackDeepImpl(U...)
[...]

On Saturday, 6 June 2020 at 12:54:11 UTC, Jean-Louis Leroy wrote:
> On Tuesday, 2 June 2020 at 06:47:54 UTC, Walter Bright wrote:
>> Many people are trying to figure out what templates are blowing up their compile. This should help:
>>
>> https://github.com/dlang/dmd/pull/11208
>
> Looks super useful.
>
> I tried it on the test suite of openmethods and I see lots of duplicate entries, e.g.:
>
> [...]
>        2        1   setName(NewValue...)
>        5        5   UnpackDeepImpl(U...)
>      121       40   Parameters(func...) if (func.length == 1 && isCallable!func)
>        8        8   UnpackDeepImpl(U...)
>        2        2   argumentMixtureAt(int i)
>        3        3   UnpackDeepImpl(U...)
>        4        4   UnpackDeepImpl(U...)
>        5        5   UnpackDeepImpl(U...)
> [...]

Duplicate entries mean different Template Declarations with the same name.
Usually those happen when templates are nested.

Consider:
template X(uint I1)
{
    template Y()
    {
       alias Y = I1;
    }
    alias X = Y!();
}

In this case the inner declaration is not dependent on any parameter that was passed to it.
But it is dependent on the context in which it is instantiated.
Every Instance of X will create a new separate context, In which a unique declaration of Y is formed.

On Saturday, 6 June 2020 at 13:23:38 UTC, Stefan Koch wrote:
> On Saturday, 6 June 2020 at 12:54:11 UTC, Jean-Louis Leroy wrote:
>> On Tuesday, 2 June 2020 at 06:47:54 UTC, Walter Bright wrote:
>>> Many people are trying to figure out what templates are blowing up their compile. This should help:
>>>
>>> https://github.com/dlang/dmd/pull/11208
>>
>> Looks super useful.
>>
>> I tried it on the test suite of openmethods and I see lots of duplicate entries, e.g.:
>>
>> [...]
>>        2        1   setName(NewValue...)
>>        5        5   UnpackDeepImpl(U...)
>>      121       40   Parameters(func...) if (func.length == 1 && isCallable!func)
>>        8        8   UnpackDeepImpl(U...)
>>        2        2   argumentMixtureAt(int i)
>>        3        3   UnpackDeepImpl(U...)
>>        4        4   UnpackDeepImpl(U...)
>>        5        5   UnpackDeepImpl(U...)
>> [...]
>
> Duplicate entries mean different Template Declarations with the same name.
> Usually those happen when templates are nested.
>
> Consider:
> template X(uint I1)
> {
>     template Y()
>     {
>        alias Y = I1;
>     }
>     alias X = Y!();
> }
>
> In this case the inner declaration is not dependent on any parameter that was passed to it.
> But it is dependent on the context in which it is instantiated.
> Every Instance of X will create a new separate context, In which a unique declaration of Y is formed.

I suspected something like this.

I am trying to aggregate the template stats across several translation units (in fact the test suite of openmethods), to measure whether an implementation is better or worse than another of the same thing. In your example, what happens if I make a copy of X, name it Z, but leave the body unchanged? I won't be able to distinguish the X.Ys from the Z.Ys. Even within the same template, imagine I put different definitions of Y inside a `static if else`. I could not tell how many times each was used. So maybe template stats should display the fully qualified name (including the module) along with the line and column numbers.

Maybe I'm missing something, I will try to find time to experiment more during the week-end.

On Saturday, 6 June 2020 at 13:59:38 UTC, Jean-Louis Leroy wrote:
> On Saturday, 6 June 2020 at 13:23:38 UTC, Stefan Koch wrote:
>> [...]
>
> I suspected something like this.
>
> I am trying to aggregate the template stats across several translation units (in fact the test suite of openmethods), to measure whether an implementation is better or worse than another of the same thing. In your example, what happens if I make a copy of X, name it Z, but leave the body unchanged? I won't be able to distinguish the X.Ys from the Z.Ys. Even within the same template, imagine I put different definitions of Y inside a `static if else`. I could not tell how many times each was used. So maybe template stats should display the fully qualified name (including the module) along with the line and column numbers.
>
> Maybe I'm missing something, I will try to find time to experiment more during the week-end.

Adding the location is a good idea.
I am going to open a PR.
Fully qualified names however can absolutely gigantic for pathological cases, and I'd like to avoid that.