May 29, 2012 Re: CTFE slower than expected | ||||
---|---|---|---|---|
| ||||
Posted in reply to Manu | 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 Re: CTFE slower than expected | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 Re: CTFE slower than expected | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | 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 Re: CTFE slower than expected | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 Re: CTFE slower than expected | ||||
---|---|---|---|---|
| ||||
Posted in reply to Philippe Sigaud | 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.
|
Copyright © 1999-2021 by the D Language Foundation