How about a 100% CTFE?

[Martin Nowak]

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

> On 07.11.2011 21:36, Martin Nowak wrote:
>> On Mon, 07 Nov 2011 20:42:17 +0100, Trass3r <un at 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