Battle-plan for CTFE

[maik klein via Digitalmars-d-announce]

On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote:
> Hi Guys,
>
> I have been looking into the DMD now to see what I can do about 
> CTFE.
> Unfortunately It is a pretty big mess to untangle.
> Code responsible for CTFE is in at least 3 files.
> [dinterpret.d, ctfeexpr.d, constfold.d]
> I was shocked to discover that the PowExpression actually 
> depends on phobos! (depending on the exact codePath it may or 
> may not compile...)
> which let to me prematurely stating that it worked at ctfe 
> [http://forum.dlang.org/thread/ukcoibejffinknrbzktv@forum.dlang.org]
>
> My Plan is as follows.
>
> Add a new file for my ctfe-interpreter and update it gradually 
> to take more and more of the cases the code in the files 
> mentioned above was used for.
>
> Do Dataflow analysis on the code that is to be ctfe'd so we can 
> tell beforehand if we need to store state in the ctfe stack or 
> not.
>
> Or baring proper data-flow analysis: RefCouting the variables 
> on the ctfe-stack could also be a solution.
>
> I will post more details as soon as I dive deeper into the code.

What is the current problem with ctfe?

Before I switched from C++ to D a few months ago I was heavily 
using boost hana in C++. I tried to emulate hana in D which 
worked quite well but the compile time performance was absolutely 
horrific

https://maikklein.github.io/2016/03/01/metaprogramming-typeobject/

After that I tried a few other things and I compared the compile 
times with

https://github.com/boostorg/hana/tree/master/benchmark

which I could never beat. The fastest thing, if I remember 
correctly, was string mixins but they used up too much memory.

But I have to say that I don't know much about the D internals 
and therefore don't know how I would optimize ct code execution.