Hi Guys.

I recently implemented __ctfeWriteln.
Based on that experience I have now implemented another pseudo function called __ctfeTicksMs.
That evaluates to a uint representing the number of milliseconds elapsed between the start of dmd and the time of semantic evaluation of this expression.

This does allow meaningful compiletime performance tests to be written.
spanning both CTFE and template-incitations timeings.

Please tell me what you think.

On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote:
> Based on that experience I have now implemented another pseudo function called __ctfeTicksMs.
> […]
> Please tell me what you think.

Please don't. This makes CTFE indeterministic.

To write performance tests, just measure compilation of a whole program (possibly with -o-). The variance due to the startup/shutdown overhead can trivially be controlled by just executing the CTFE code in question often enough.

 — David

On Sunday, 4 September 2016 at 00:08:14 UTC, David Nadlinger wrote:
>
> Please don't. This makes CTFE indeterministic.
>
Please elaborate on why this would have a negative impact ?
if someone chooses to use a symbol called __ctfeTicksMs they shoud know what they are doing.

> To write performance tests, just measure compilation of a whole program (possibly with -o-). The variance due to the startup/shutdown overhead can trivially be controlled by just executing the CTFE code in question often enough.

That will only allow you to tell how much overall ctfe-time you spent.
It will not allow you to pinpoint and optimize the offenders.

On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote:
> I recently implemented __ctfeWriteln.

Sounds like pragma msg.  How does it compare?
https://dlang.org/spec/pragma.html#msg

On Sunday, 4 September 2016 at 01:44:40 UTC, sarn wrote:
> On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote:
>> I recently implemented __ctfeWriteln.
>
> Sounds like pragma msg.  How does it compare?
> https://dlang.org/spec/pragma.html#msg

Pragma msg can only print compiletime constants.
While __ctfeWriteln can print state while doing CTFE.

Example
int fn(int n)
{
  import std.conv;
  __ctfeWriteln((n-10).to!string);
  return n;
}

static assert(fn(22));

will print 12;
whereas
int fn(int n)
{
  import std.conv;
  pragma(msg, n.to!string);
  return n;
}
will tell you that the symbol n is not avilable at compiletime

On Sunday, 4 September 2016 at 01:53:21 UTC, Stefan Koch wrote:
> Pragma msg can only print compiletime constants.
> While __ctfeWriteln can print state while doing CTFE.

Thanks, that makes a lot of sense.  Just to check, it prints to standard error, right?

Also, the issue of non-deterministic compilation reminds me of the debate about allowing logging statements in pure functions.  Maybe there's a similar answer (i.e., making it only work in some kind of debug mode).

On Sunday, 4 September 2016 at 02:03:49 UTC, sarn wrote:
> On Sunday, 4 September 2016 at 01:53:21 UTC, Stefan Koch wrote:
>> Pragma msg can only print compiletime constants.
>> While __ctfeWriteln can print state while doing CTFE.
>
> Thanks, that makes a lot of sense.  Just to check, it prints to standard error, right?
>
> Also, the issue of non-deterministic compilation reminds me of the debate about allowing logging statements in pure functions.
>  Maybe there's a similar answer (i.e., making it only work in some kind of debug mode).

This works already.
Anything placed in a debug {} block will be considered pure regardless.

On Sunday, 4 September 2016 at 02:06:55 UTC, Stefan Koch wrote:
> This works already.
> Anything placed in a debug {} block will be considered pure regardless.

Opps your comment was about the debate.
I would say that __ctfeWriteln and __ctfeTicksMs should not work outside of debug.

On 04/09/2016 2:08 PM, Stefan Koch wrote:
> On Sunday, 4 September 2016 at 02:06:55 UTC, Stefan Koch wrote:
>> This works already.
>> Anything placed in a debug {} block will be considered pure regardless.
>
> Opps your comment was about the debate.
> I would say that __ctfeWriteln and __ctfeTicksMs should not work outside
> of debug.

Can we have writeln and writefln call into it if __ctfe is true?
Just so that we have got some consistency between runtime and CTFE usage.

On Sunday, 4 September 2016 at 04:10:29 UTC, rikki cattermole wrote:
> On 04/09/2016 2:08 PM, Stefan Koch wrote:
>> On Sunday, 4 September 2016 at 02:06:55 UTC, Stefan Koch wrote:
>>> This works already.
>>> Anything placed in a debug {} block will be considered pure regardless.
>>
>> Opps your comment was about the debate.
>> I would say that __ctfeWriteln and __ctfeTicksMs should not work outside
>> of debug.
>
> Can we have writeln and writefln call into it if __ctfe is true?
> Just so that we have got some consistency between runtime and CTFE usage.

No!
writeln and __ctfeWriteln are to be regarded as completely different things.
__ctfeWriteln is a debugging tool only!
It should not be used in any production code.