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/ukcoibejffinknrbz...@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.

Reply via email to