www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - CTFE slower than expected

reply Manu <turkeyman gmail.com> writes:
--485b397dd7a9799a9e04c12a42f3
Content-Type: text/plain; charset=UTF-8

I've been trying to work out why my compile times have gone to hell
recently.

I have a lib, it takes 3.5 seconds to compile.
I add one CTFE heavy module, it's not huge, certainly much smaller than the
rest of the app, and it blows out to 18 seconds. I've done some experiments
removing bits and pieces of code, I can isolate the bits that add seconds
to the compile time, but the big offenders are one-line mixins which use
CTFE fairly aggressively to generate the strings they mix in.

Can anyone comment on CTFE as implemented? Why is it so slow? It's
certainly not executing a lot of code. I can imagine executing the same
routine in an interpreted language like lua would take milliseconds or
less, not multiple seconds.
What are the bottlenecks? Is there any way to improve it?

--485b397dd7a9799a9e04c12a42f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>I&#39;ve been trying to work out why my compile times have gone to hel=
l recently.</div><div><br></div>I have a lib, it takes 3.5 seconds to compi=
le.<div>I add one CTFE heavy module, it&#39;s not huge, certainly much smal=
ler than the rest of the app, and it blows out to 18 seconds. I&#39;ve done=
 some experiments removing bits and pieces of code, I can isolate the bits =
that add seconds to the compile time, but the big offenders are one-line mi=
xins which use CTFE fairly aggressively to generate the strings they mix in=
.</div>
<div><br></div><div>Can anyone comment on CTFE as implemented? Why is it so=
 slow? It&#39;s certainly not executing a lot of code. I can imagine execut=
ing the same routine in an interpreted language like lua would take millise=
conds or less, not multiple seconds.</div>
<div>What are the bottlenecks? Is there any way to improve it?</div>

--485b397dd7a9799a9e04c12a42f3--
May 29 2012
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2012-05-29 10:25:54 +0000, Manu <turkeyman gmail.com> said:

 What are the bottlenecks? Is there any way to improve it?

The answer to those questions is usually found by profiling. Asking people for what they think is slow is almost certain to give you wrong answers. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
May 29 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf300fab6f6cf6ff04c12b7e12
Content-Type: text/plain; charset=UTF-8

On 29 May 2012 14:28, Michel Fortin <michel.fortin michelf.com> wrote:

 On 2012-05-29 10:25:54 +0000, Manu <turkeyman gmail.com> said:

  What are the bottlenecks? Is there any way to improve it?

The answer to those questions is usually found by profiling. Asking people for what they think is slow is almost certain to give you wrong answers.

I'm not in a hurry. I'm mainly asking out of curiosity, and wondering if others are thinking the same thing, or if there are motions to improve it. --20cf300fab6f6cf6ff04c12b7e12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 29 May 2012 14:28, Michel Fortin <span dir=3D= "ltr">&lt;<a href=3D"mailto:michel.fortin michelf.com" target=3D"_blank">mi= chel.fortin michelf.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail= _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= 1ex"> <div class=3D"im">On 2012-05-29 10:25:54 +0000, Manu &lt;<a href=3D"mailto:= turkeyman gmail.com" target=3D"_blank">turkeyman gmail.com</a>&gt; said:<br=

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> What are the bottlenecks? Is there any way to improve it?<br> </blockquote> <br></div> The answer to those questions is usually found by profiling. Asking people = for what they think is slow is almost certain to give you wrong answers.</b= lockquote><div><br></div><div>I&#39;m not in a hurry.=C2=A0I&#39;m mainly a= sking out of curiosity, and wondering if others are thinking the same thing= , or if there are motions to improve it.</div> <div><br></div></div> --20cf300fab6f6cf6ff04c12b7e12--
May 29 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-05-29 12:25, Manu wrote:
 I've been trying to work out why my compile times have gone to hell
 recently.

 I have a lib, it takes 3.5 seconds to compile.
 I add one CTFE heavy module, it's not huge, certainly much smaller than
 the rest of the app, and it blows out to 18 seconds. I've done some
 experiments removing bits and pieces of code, I can isolate the bits
 that add seconds to the compile time, but the big offenders are one-line
 mixins which use CTFE fairly aggressively to generate the strings they
 mix in.

 Can anyone comment on CTFE as implemented? Why is it so slow? It's
 certainly not executing a lot of code. I can imagine executing the same
 routine in an interpreted language like lua would take milliseconds or
 less, not multiple seconds.
 What are the bottlenecks? Is there any way to improve it?

Many small string mixins are slow, even if they're string literals and not generated. If possible, it's better with one huge string mixin. -- /Jacob Carlborg
May 29 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-05-29 14:37, Manu wrote:

 That's interesting. I can probably give that a shot.
 So you think that's a bigger cost than the CTFE code that generates the
 strings?

I don't know. I just did a test with Derelict that needed to be compatible with D1 and D2 and therefore used string mixins for things like __gshared. For example: http://www.dsource.org/projects/derelict/browser/branches/Derelict2/DerelictGL/derelict/opengl/glfuncs.d#L699 Putting all those declarations in their own string mixins make a difference. -- /Jacob Carlborg
May 29 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--0023544706f05742cb04c12c17e0
Content-Type: text/plain; charset=UTF-8

On 29 May 2012 15:10, Jacob Carlborg <doob me.com> wrote:

 On 2012-05-29 12:25, Manu wrote:

 I've been trying to work out why my compile times have gone to hell
 recently.

 I have a lib, it takes 3.5 seconds to compile.
 I add one CTFE heavy module, it's not huge, certainly much smaller than
 the rest of the app, and it blows out to 18 seconds. I've done some
 experiments removing bits and pieces of code, I can isolate the bits
 that add seconds to the compile time, but the big offenders are one-line
 mixins which use CTFE fairly aggressively to generate the strings they
 mix in.

 Can anyone comment on CTFE as implemented? Why is it so slow? It's
 certainly not executing a lot of code. I can imagine executing the same
 routine in an interpreted language like lua would take milliseconds or
 less, not multiple seconds.
 What are the bottlenecks? Is there any way to improve it?

Many small string mixins are slow, even if they're string literals and not generated. If possible, it's better with one huge string mixin.

That's interesting. I can probably give that a shot. So you think that's a bigger cost than the CTFE code that generates the strings? --0023544706f05742cb04c12c17e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 29 May 2012 15:10, Jacob Carlborg <span dir= =3D"ltr">&lt;<a href=3D"mailto:doob me.com" target=3D"_blank">doob me.com</= a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On 2012-05-29 12:25, Manu wrote:<br=

rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"> I&#39;ve been trying to work out why my compile times have gone to hell<br> recently.<br> <br> I have a lib, it takes 3.5 seconds to compile.<br> I add one CTFE heavy module, it&#39;s not huge, certainly much smaller than= <br> the rest of the app, and it blows out to 18 seconds. I&#39;ve done some<br> experiments removing bits and pieces of code, I can isolate the bits<br> that add seconds to the compile time, but the big offenders are one-line<br=

mix in.<br> <br> Can anyone comment on CTFE as implemented? Why is it so slow? It&#39;s<br> certainly not executing a lot of code. I can imagine executing the same<br> routine in an interpreted language like lua would take milliseconds or<br> less, not multiple seconds.<br></div></div><div class=3D"im"> What are the bottlenecks? Is there any way to improve it?<br> </div></blockquote> <br> Many small string mixins are slow, even if they&#39;re string literals and = not generated. If possible, it&#39;s better with one huge string mixin.</bl= ockquote><div><br></div><div>That&#39;s interesting. I can probably give th= at a shot.</div> <div>So you think that&#39;s a bigger cost than the CTFE code that generate= s the strings?</div></div> --0023544706f05742cb04c12c17e0--
May 29 2012
prev sibling next sibling parent reply Don Clugston <dac nospam.com> writes:
On 29/05/12 12:25, Manu wrote:
 I've been trying to work out why my compile times have gone to hell
 recently.

 I have a lib, it takes 3.5 seconds to compile.
 I add one CTFE heavy module, it's not huge, certainly much smaller than
 the rest of the app, and it blows out to 18 seconds. I've done some
 experiments removing bits and pieces of code, I can isolate the bits
 that add seconds to the compile time, but the big offenders are one-line
 mixins which use CTFE fairly aggressively to generate the strings they
 mix in.

 Can anyone comment on CTFE as implemented? Why is it so slow?

You really don't want to know. What it's actually doing is horrific. Bug 6498. The reason why it's still like that is that CTFE bugs have kept cropping up (mostly related to pointers and especially AAs), which have prevented me from doing anything on the performance issue.
 It's
 certainly not executing a lot of code. I can imagine executing the same
 routine in an interpreted language like lua would take milliseconds or
 less, not multiple seconds.
 What are the bottlenecks?

It's was originally based on the const-folding code used by the optimizer. So most of the code was written with totally goals (that didn't include performance).
 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.
May 29 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
parent deadalnix <deadalnix gmail.com> writes:
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
prev sibling parent Don Clugston <dac nospam.com> writes:
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.
May 30 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf300fb2833aacca04c12e2d5c
Content-Type: text/plain; charset=UTF-8

On 29 May 2012 15:52, Don Clugston <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! ;) --20cf300fb2833aacca04c12e2d5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 29 May 2012 15:52, Don Clugston <span dir=3D"= ltr">&lt;<a href=3D"mailto:dac nospam.com" target=3D"_blank">dac nospam.com= </a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin= :0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 29/05/12 12:25, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Is there any way to improve it?</blockquote>= </div><div class=3D"im"> <br></div> Oh yeah. Orders of magnitude, easily. The slowness is not in any way inhere= nt to CTFE. The experience will be completely different, once I have some t= ime to work on it -- I know exactly how to do it.<br></blockquote><div> <br></div><div>Alright, well I&#39;ve got a case of beer with your name on = it if you can pull it off! ;)</div></div> --20cf300fb2833aacca04c12e2d5c--
May 29 2012
prev sibling next sibling parent d coder <dlang.coder gmail.com> writes:
--f46d04083de7b112c104c12ff52d
Content-Type: text/plain; charset=ISO-8859-1

 Alright, well I've got a case of beer with your name on it if you can pull
 it off! ;)

+1. I too am waiting for CTFE improvements. I am working on a DSL and with the present limitations, it is impractically slow and memory consuming while compiling. --f46d04083de7b112c104c12ff52d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gma= il_quote"><div><br></div><div>Alright, well I&#39;ve got a case of beer wit= h your name on it if you can pull it off! ;)</div> </div> </blockquote></div><br><div>+1. I too am waiting for CTFE improvements. I a= m working on a DSL and with the present limitations, it is impractically sl= ow and memory consuming while compiling.</div><div><br></div> --f46d04083de7b112c104c12ff52d--
May 29 2012
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
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.
May 29 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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 29 2012