On Thu, 29 May 2014 12:53:54 -0400, Dylan Knutson <[email protected]>
wrote:
I'm not well acquainted with how the compiler works internally, or how
CTFE is implemented. But it seems like a full-blown D interpreter with
eval functionality is needed. Lots of scripting language interpreters
exist out there, and they all get relatively decent performance and
memory footprints (or at least much better than what DMD can get when
performing CTFE).
Is there anything so radically different in D than these other
languages, that prevents the implementation of a run-of-the-mill VM to
eval D code? It just seems strange to me that it's such a problem when
this is basically solved by all scripting languages. And I'm really not
trying to downplay the difficulty in implementing CTFE in D, but rather
just figure out why it's so hard to implement in comparison.
The compilation speed of D is touted continually as a very important
"feature".
Realistically, as long as you have the memory to sustain it, you will
NEVER beat the current implementation because it never deallocates
anything. By definition, deallocating some things will add more length to
the compile time.
I think as long as the slowdown doesn't result in an order of magnitude
difference, we should be fine. Nobody will complain about 5 second compile
times vs. 4 second ones (well, mostly nobody). People will definitely
notice and complain about 15 second compile times vs 4 second ones.
It remains to be seen how any of this would perform. It is an idea to
think about, and I didn't realize someone already had considered it. The
thing I like about it, is that the environment is a restrictive one where
we can try ref counting + GC out, without adversely affecting actual
running D code. Once the compiler is finished, there are no traces of the
CTFE interpreted heap. See the recent threads about the issues with adding
ref counting to the language.
And when I say "we", I mean people other than me who can write compiler
code :) So there is that... (ducks)
-Steve
