On Tue, Dec 18, 2012 at 09:30:40AM -0800, Walter Bright wrote: > On 12/18/2012 8:57 AM, Dmitry Olshansky wrote: [...] > >Another point is that pointer chasing data-structures is not a recipe > >for fast repeated execution. > > > >To provide an analogy: executing calculation recursively on AST tree > >of expression is bound to be slower then running the same calculation > >straight on sanely encoded flat reverse-polish notation. > > > >A hit below belt: also peek at your own DMDScript - why bother with > >plain IR (_bytecode_!) for JavaScript if it could just fine be > >interpreted as is on AST-s? > > Give me some credit for learning something over the last 12 years! > I'm not at all convinced I'd use the same design if I were doing it > now. > > If I was doing it, and speed was paramount, I'd probably fix it to > generate native code instead of bytecode and so execute code > directly. Even simple JITs dramatically speeded up the early Java > VMs. [...]
Is it too late to change CTFE to work via native code? Besides the effort required to rework the existing code (and perhaps the cross-compiling issue, though I don't see it as a major issue), I see a lot of advantages to doing that. For one thing, it will solve the current complaints about CTFE speed and memory usage (a native code implementation would allow using a GC to keep memory footprint down, or perhaps just a sandbox that can be ditched after evaluation and its memory reclaimed). T -- Obviously, some things aren't very obvious.