CTFE Overhaul (Was: RFC: Thrift project proposal (draft))

[Jonathan M Davis]

On 2011-03-27 08:41, Robert Jacques wrote:
> On Sun, 27 Mar 2011 06:06:48 -0400, Jacob Carlborg <doob at me.com> wrote:
> > On 2011-03-26 21:16, Don wrote:
> >> dsimcha wrote:
> >>> On 3/26/2011 12:16 PM, Don wrote:
> >>>> I'm giving CTFE a *major* overhaul right now. I don't know if I'll be
> >>>> finished in time for the next compiler release, but definitely by the
> >>>> release after that. Most importantly, bug 1330, which is the root
> >>>> cause
> >>>> of almost all of the problems, will be fixed. I hope to move CTFE out
> >>>> the "experimental feature" category.
> >>> 
> >>> This is great news, I'm looking forward to it. Thanks for the hard
> >>> work. Out of curiosity, can you give a brief overview of what new
> >>> things CTFE will be usable for?
> >> 
> >> The basic problem with the current implementation of CTFE is that it
> >> uses copy-on-write. This means that references (including dynamic
> >> arrays) don't work properly -- they just copy a snapshot of the thing
> >> they are referencing. This is bug 1330. It also means it burns up memory
> >> like you wouldn't believe.
> >> 
> >> I'm changing CTFE to use in-place modification. This fixes all those
> >> issues. But this is obviously a fairly intense change, and will take
> >> quite a lot of time to iron out all the corner cases. So that's all I'm
> >> planning on doing right now.
> >> 
> >> But once that's done, it will be straightforward to implement other
> >> reference types, such as classes and pointers (pointer arithmetic will
> >> be restricted to pointers which point to array members). Once classes
> >> are implemented, it's straightforward to do exceptions. So, pretty much
> >> everything.
> >> 
> >> I've been planning on doing this for over a year, but while Walter was
> >> working on 64-bit, I felt that I was the only one working on the
> >> showstopper wrong-code bugs and regressions, so I put this
> >> important-but-not-urgent stuff aside.
> > 
> > Will the time it takes to compile heavy uses of CTFE be affected by this
> > (positive or negative)?
> 
> Any string heavy CTFE should see a major improvement in performance.

Yeah. Considering how memory-heavy CTFE tends to be, I'd expect that such a 
massive drop in memory consumption would almost always result in a performance 
improvement. However, we could end up being surprised with how it actually 
performs, since how the performance characteristics of an application change 
as you change it can sometimes be very surprising. I would generally expect it 
to improve performance though, not harm it. And it should definitely make some 
CTFE which currently fails due to a lack of memory actually work.

- Jonathan M Davis