Compilation strategy

[H. S. Teoh]

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.