May 29, 2012
On 5/29/2012 8:06 AM, Manu wrote:
> On 29 May 2012 15:52, Don Clugston <dac@nospam.com <mailto:dac@nospam.com>> wrote:
>
>     On 29/05/12 12:25, Manu wrote:
>
>         Is there any way to improve it?
>
>
>     Oh yeah. Orders of magnitude, easily. The slowness is not in any way
>     inherent to CTFE. The experience will be completely different, once I have
>     some time to work on it -- I know exactly how to do it.
>
>
> Alright, well I've got a case of beer with your name on it if you can pull it
> off! ;)

tl,dr: CTFE started out as a glorified constant folder, not an interpreter. An interpreter needs a different design.
May 29, 2012
Walter Bright:

> tl,dr: CTFE started out as a glorified constant folder, not an interpreter. An interpreter needs a different design.

And I presume a basic JITting interpreter for CTFE (like one in LDC2 using existing LLVM JIT tools) needs yet another design.

Bye,
bearophile
May 29, 2012
On 5/29/12, Don Clugston <dac@nospam.com> wrote:
> Oh yeah. Orders of magnitude, easily.

Does this also imply speedups for static foreach loops? I've got quite a few of those and they seem to slow down compilation a bit. I've had a funny error message once saying there's an error on line ~50_000 in a 1000-line module, so I guess static foreach can expand to quite a bit of code, maybe I should be more careful with those..
May 30, 2012
Le 29/05/2012 23:53, Walter Bright a écrit :
> On 5/29/2012 8:06 AM, Manu wrote:
>> On 29 May 2012 15:52, Don Clugston <dac@nospam.com
>> <mailto:dac@nospam.com>> wrote:
>>
>> On 29/05/12 12:25, Manu wrote:
>>
>> Is there any way to improve it?
>>
>>
>> Oh yeah. Orders of magnitude, easily. The slowness is not in any way
>> inherent to CTFE. The experience will be completely different, once I
>> have
>> some time to work on it -- I know exactly how to do it.
>>
>>
>> Alright, well I've got a case of beer with your name on it if you can
>> pull it
>> off! ;)
>
> tl,dr: CTFE started out as a glorified constant folder, not an
> interpreter. An interpreter needs a different design.

Can you elaborate on that ?

I would be very interested to have your experience with that, which problems you faced, what you'd have done differently if you would have known the future.
May 30, 2012
On 29/05/12 23:23, Philippe Sigaud wrote:
> On Tue, May 29, 2012 at 2:52 PM, Don Clugston<dac@nospam.com>  wrote:
>
>>> Is there any way to improve it?
>>
>>
>> Oh yeah. Orders of magnitude, easily.
>
> !
>
>> The slowness is not in any way
>> inherent to CTFE. The experience will be completely different, once I have
>> some time to work on it -- I know exactly how to do it.
>
> Did 2.058 or 2.059 see any new code for CTFE? Like the OP, I've the
> impression CTFE/mixins suddenly became far slower. I'm not
> complaining, I understand it's a difficult part of DMD, but I wondered
> if what I see is real or imaginary.

The behaviour of __traits(allMembers) changed (it now returns an array of string literals) and I expect that to be a little bit slower.
Compiling Phobos is now *much* slower than it used to be, due to changes in Phobos. (eg, import std.random; is unbelievably slow).


As for CTFE, certain cases became faster (eg, repeated use of global array literals).

But if you can pinpoint a case where CTFE itself became slower, I'd like to know.

1 2
Next ›   Last »