On Sunday, 4 September 2016 at 00:08:14 UTC, David Nadlinger wrote:
> Please don't. This makes CTFE indeterministic.

Well we already have __TIMESTAMP__, though I think it doesn't change during compilation.

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

Nice, is it only for your interpreter or can we move https://trello.com/c/6nU0lbl2/24-ctfewrite to done? I think __ctfeWrite would be a better primitive. And we could actually consider to specialize std.stdio.write* for CTFE.

On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote:
> 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.

For bigger CTFE programs it might be helpful.
Milliseconds are a fairly low resolution, would think with hnsec or so makes a better unit. Using core.time.TickDuration for that would make sense.

On Tuesday, September 06, 2016 10:46:11 Martin Nowak via Digitalmars-d wrote:
> On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote:
> > 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.
>
> For bigger CTFE programs it might be helpful.
> Milliseconds are a fairly low resolution, would think with hnsec
> or so makes a better unit. Using core.time.TickDuration for that
> would make sense.

If you're doing to do that use core.time.Duration. TickDuration is slated to be deprecated once the functionality in Phobos that uses it has been deprecated. Duration replaces its functionality as a duration, and MonoTime replaces its functionality as a timestamp of the monotonic clock.

- Jonathan M Davis

On Tuesday, 6 September 2016 at 10:42:00 UTC, Martin Nowak wrote:
> On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote:
>> I recently implemented __ctfeWriteln.
>
> Nice, is it only for your interpreter or can we move https://trello.com/c/6nU0lbl2/24-ctfewrite to done? I think __ctfeWrite would be a better primitive. And we could actually consider to specialize std.stdio.write* for CTFE.

It's only for the current engine and only for Strings!
See: https://github.com/dlang/druntime/pull/1643
and https://github.com/dlang/dmd/pull/6101

On Tue, Sep 6, 2016 at 7:42 PM, Stefan Koch via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Tuesday, 6 September 2016 at 10:42:00 UTC, Martin Nowak wrote:
>
>> On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote:
>>
>>> I recently implemented __ctfeWriteln.
>>>
>>
>> Nice, is it only for your interpreter or can we move https://trello.com/c/6nU0lbl2/24-ctfewrite to done? I think __ctfeWrite would be a better primitive. And we could actually consider to specialize std.stdio.write* for CTFE.
>>
>
> It's only for the current engine and only for Strings!
> See: https://github.com/dlang/druntime/pull/1643
> and https://github.com/dlang/dmd/pull/6101
>



Seriously Stefan, you make my day!

My libraries will be so much easier to write!

On Wednesday, 7 September 2016 at 06:49:09 UTC, Rory McGuire wrote:
>
> Seriously Stefan, you make my day!
>
> My libraries will be so much easier to write!

I am glad the time was not wasted.
Let's hope it gets merged :)

On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote:
>
> ... I have now implemented another pseudo function called __ctfeTicksMs.
> [Snip]
>
> This does allow meaningful compiletime performance tests to be written.
> spanning both CTFE and template-incitations timeings.
>
> Please tell me what you think.

I think automated ctfe profiling would be much better and the byte-code interpreter seems like a great platform to build this onto.

For example, using a command line switch to enable profiling which outputs something similar to gprof's flat profile.

Skimming the byte-code work it seems like it is too early to add this yet.

My thoughts on __ctfeTicksMs:
- it isn't very meaningful for users without intimate compiler knowledge
- it requires writing boilerplate code over and over for profiling
- doesn't seem like it would work well for functions that get executed multiple times

While it might be a useful compiler developer hack, I do not think it should become a user primitive.

On Thursday, 8 September 2016 at 16:52:47 UTC, safety0ff wrote:
> On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote:
>>
>> ... I have now implemented another pseudo function called __ctfeTicksMs.
>> [Snip]
>>
>> This does allow meaningful compiletime performance tests to be written.
>> spanning both CTFE and template-incitations timeings.
>>
>> Please tell me what you think.
>
> I think automated ctfe profiling would be much better and the byte-code interpreter seems like a great platform to build this onto.
>
> For example, using a command line switch to enable profiling which outputs something similar to gprof's flat profile.

I thought of the same thing a while back.
However I have had the time to decipher the gprof data-format yet.
Is there another profile-format for decent visualization tools exist ?

On Thursday, 8 September 2016 at 17:03:30 UTC, Stefan Koch wrote:
>
> I thought of the same thing a while back.
> However I have had the time to decipher the gprof data-format yet.
> Is there another profile-format for decent visualization tools exist ?

I was just using that as an example of what we might want to output as text.
e.g. https://sourceware.org/binutils/docs/gprof/Flat-Profile.html

I wasn't saying that we should mimic gmon.out file format, I don't think that buys us much.