On Friday, 31 March 2017 at 14:16:15 UTC, Stefan Koch wrote:
> On Friday, 31 March 2017 at 14:05:00 UTC, Stefan Koch wrote:
>> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>>> [ ... ]
>>
>> Alright guys.
>>
>> I am just fixing the newCTFE LLVM backend such that I can have better guesses as to what performance a JIT could archive.
>>
>> Due to the ABI changes the llvm-backend a little optimization potential.
>>
>> It'll be a while until the llvm backend is on par again.
>> Because functions and such need to be dealt with quite differently.
>> Also the llvm backend recives less testing since I cannot run it at compile time(Yet :))
>>
>> Cheers,
>> Stefan
>> --
>> sorry for the short message I am busy fixing codegen bugs as always.
>
> oh, yeah ... If you want to checkout the llvm backend fethc the newCTFE_LLVMBackend branch from https://github.com/UplinkCoder/dmd.
>
> the posix.mak is hardcoded to use libLLVM-3.5.
> However you should be able to use any version newer then 3.3.


How far off until newCTFE is usable to compile the majority of templates out there? I have some new code that doesn't do anything real complex but seems quite slow for no apparent reason and would like to try the newCTFE if it has a good chance of working.

On Saturday, 1 April 2017 at 17:06:14 UTC, Inquie wrote:
>
> How far off until newCTFE is usable to compile the majority of templates out there? I have some new code that doesn't do anything real complex but seems quite slow for no apparent reason and would like to try the newCTFE if it has a good chance of working.

Quite far.
Templates are usually not slow because of CTFE.
But because of O(n^2) ((O(n!) actully in some cases) nature of recursive templates.

I am going to fix this after CTFE, (if the D Langauge Foundation or a third-party can provide sponsorship for that).

On Sat, Apr 01, 2017 at 05:06:14PM +0000, Inquie via Digitalmars-d wrote: [...]
> How far off until newCTFE is usable to compile the majority of templates out there?

CTFE and templates are two separate things. You may want to read this (draft) article to get a better understanding of how they fit together:

	https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time


T

-- 
Computers shouldn't beep through the keyhole.

On Sunday, 2 April 2017 at 04:34:34 UTC, H. S. Teoh wrote:
> On Sat, Apr 01, 2017 at 05:06:14PM +0000, Inquie via Digitalmars-d wrote: [...]
>> How far off until newCTFE is usable to compile the majority of templates out there?
>
> CTFE and templates are two separate things. You may want to read this (draft) article to get a better understanding of how they fit together:
>
> 	https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
>
>
> T

some drive-by review
---
struct Box!float
{
    int data;
}

Box!float floatBox;
---

Is not what you meant.

On Sunday, 2 April 2017 at 04:34:34 UTC, H. S. Teoh wrote:
> On Sat, Apr 01, 2017 at 05:06:14PM +0000, Inquie via Digitalmars-d wrote: [...]
>> How far off until newCTFE is usable to compile the majority of templates out there?
>
> CTFE and templates are two separate things. You may want to read this (draft) article to get a better understanding of how they fit together:
>
> 	https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
>
>
> T

Just read your draft article, very illuminating. Thank you. There was a section "Interleaved AST manipulation and CTFE" which you mention is "one of the keystones of meta-programming in D". I think there should be a separate article on this topic as a way of popularising D's idioms. When can we expect this? :-)

On Sunday, 2 April 2017 at 04:34:34 UTC, H. S. Teoh wrote:
> On Sat, Apr 01, 2017 at 05:06:14PM +0000, Inquie via Digitalmars-d wrote: [...]
>> How far off until newCTFE is usable to compile the majority of templates out there?
>
> CTFE and templates are two separate things. You may want to read this (draft) article to get a better understanding of how they fit together:
>
> 	https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
>
>
> T

CTFE and template expansion might be more tangled than you thought.

For example, you do have access to CTFE during template expansion: http://forum.dlang.org/thread/yaekhryalyxyooaiuakj@forum.dlang.org

On Wed, Apr 05, 2017 at 11:20:28AM +0000, Yuxuan Shui via Digitalmars-d wrote:
> On Sunday, 2 April 2017 at 04:34:34 UTC, H. S. Teoh wrote:
> > On Sat, Apr 01, 2017 at 05:06:14PM +0000, Inquie via Digitalmars-d wrote: [...]
> > > How far off until newCTFE is usable to compile the majority of templates out there?
> > 
> > CTFE and templates are two separate things. You may want to read this (draft) article to get a better understanding of how they fit together:
> > 
> > 	https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
> > 
> > 
> > T
> 
> CTFE and template expansion might be more tangled than you thought.
> 
> For example, you do have access to CTFE during template expansion: http://forum.dlang.org/thread/yaekhryalyxyooaiuakj@forum.dlang.org

Did you read the entire article?

There is an entire section dedicated to interleaving of CTFE and templates.  And no, you still cannot run CTFE on the same part of the AST that is being template-expanded. But you *can* run CTFE on a subtree that has already been fully expanded.

And no, the forum post you linked to has nothing to do with CTFE. The
so-called "static foreach" is unrolled at AST expansion time, and is not
run through CTFE at all (unless later on you call the expanded
function at "compile-time"). And is() expressions are also not CTFE,
they are also evaluated at AST expansion time.

Read the entire article first. ;-)


T

-- 
Guns don't kill people. Bullets do.

On Sunday, 2 April 2017 at 04:34:34 UTC, H. S. Teoh wrote:
> On Sat, Apr 01, 2017 at 05:06:14PM +0000, Inquie via Digitalmars-d wrote: [...]
>> How far off until newCTFE is usable to compile the majority of templates out there?
>
> CTFE and templates are two separate things. You may want to read this (draft) article to get a better understanding of how they fit together:
>
> 	https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
>
>
> T

Very nice and informative article! Thanks!

Still I miss some comments about mixins and template mixins.

On Wednesday, 5 April 2017 at 16:06:39 UTC, H. S. Teoh wrote:
> On Wed, Apr 05, 2017 at 11:20:28AM +0000, Yuxuan Shui via Digitalmars-d wrote:
>> [...]
>
> Did you read the entire article?
>
> There is an entire section dedicated to interleaving of CTFE and templates.  And no, you still cannot run CTFE on the same part of the AST that is being template-expanded. But you *can* run CTFE on a subtree that has already been fully expanded.
>
> And no, the forum post you linked to has nothing to do with CTFE. The
> so-called "static foreach" is unrolled at AST expansion time, and is not
> run through CTFE at all (unless later on you call the expanded
> function at "compile-time"). And is() expressions are also not CTFE,
> they are also evaluated at AST expansion time.
>
> Read the entire article first. ;-)
>
>
> T

I was talking about the use of R.front, R.drop in the template.

On Wed, Apr 05, 2017 at 08:08:32PM +0000, Yuxuan Shui via Digitalmars-d wrote:
> On Wednesday, 5 April 2017 at 16:06:39 UTC, H. S. Teoh wrote:
> > On Wed, Apr 05, 2017 at 11:20:28AM +0000, Yuxuan Shui via Digitalmars-d wrote:
> > > [...]
> > 
> > Did you read the entire article?
> > 
> > There is an entire section dedicated to interleaving of CTFE and templates.  And no, you still cannot run CTFE on the same part of the AST that is being template-expanded. But you *can* run CTFE on a subtree that has already been fully expanded.
> > 
> > And no, the forum post you linked to has nothing to do with CTFE. The so-called "static foreach" is unrolled at AST expansion time, and is not run through CTFE at all (unless later on you call the expanded function at "compile-time"). And is() expressions are also not CTFE, they are also evaluated at AST expansion time.
> > 
> > Read the entire article first. ;-)
> > 
> > 
> > T
> 
> I was talking about the use of R.front, R.drop in the template.

Yes, that's the interleaving I was talking about. In your code example, R is an alias to something outside the template itself, so as long as whatever it aliases can be "finalized" in its AST, it can be handed to the CTFE engine for evaluation.  This is really just a more fancy instance of the more common `enum X = f(Y);` idiom, but it's really the same thing.  The compiler tries to use CTFE every time it sees a value that's needed at "compile-time"; `enum` is the usual way to trigger this, but a template expansion that depends on the value, as you have here, is also where the same thing happens.

What you *cannot* have, though, is if R is in the process of being AST-expanded.  E.g., if .front itself requires expandRange() in its definition, then it won't work, because then the compiler can't finalize the AST of .front and CTFE won't be able to run it.


T

-- 
Nobody is perfect.  I am Nobody. -- pepoluan, GKC forum