On Tue, 08 Nov 2011 09:08:49 +0100, Don <nos...@nospam.com> wrote:

On 07.11.2011 21:36, Martin Nowak wrote:
On Mon, 07 Nov 2011 20:42:17 +0100, Trass3r <u...@known.com> wrote:

version(ARM)
{
immutable X = armSpecificCode(); // you want to run this on an X86???
}

I've always thought that it would be worthwhile to experiment with
LLVM's JIT engine here.
But as has been said quite some care will be necessary for cross
compilation.
Allowing arbitrary non-pure functions would cause lots troubles.

Yeah, I think JIT for CTFE would be *very* interesting. But mainly
for reasons of speed rather than functionality.

How would JIT work in the above case?

You would need to do JIT a target agnostic IR.

Yeah, it's only the glue layer which needs to change. The main complexity is dealing with pointers.

Currently it only seems viable for strongly pure functions.
One would still need to be very careful about target dependencies through libc calls (sinl et.al.), marshalling the arguments and the result is necessary and dmd doesn't have a virtual machine, does it? One could try to fake the latter by compiling to executables, but it would require a target specific runtime/stdlib.

Overall I don't have too much performance issues with CTFE.

I've more issues with badly scaling compiler algorithms now that they
are used with magnitudes bigger input, i.e. unrolled loops or huge array literals. Especially considering that they performance impact mostly stems from codegen and sometime the generated code is only used for compile time initialization.

A lot of garbage is created during CTFE as in-place changes don't always work.
For example I haven't yet succeeded in writing an in-place CTFE quicksort,
so I ended up with 'sort(left) ~ pivot ~ sort(right)'.

martin

Reply via email to