www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Compile-time vs. compile-time

reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
Finally got around to working on my draft article "Compile-time vs.
compile-time" again today. Mainly added another case study for a
commonly encountered issue, and cleaned up the outdated stuff on
"static" foreach (not the *real* static foreach that we have now).  Now
I'm reasonably happy with its current form, and am thinking to add it to
the list of articles on the wiki.  But thought I should solicit some
feedback here first. So here it is:

	https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time#But_what_of_runtime_performance.3F

object.destroy! :-P


T

-- 
What do you mean the Internet isn't filled with subliminal messages? What about
all those buttons marked "submit"??
Jan 02 2018
parent reply ag0aep6g <anonymous example.com> writes:
On 01/03/2018 02:51 AM, H. S. Teoh wrote:

 	https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time#But_what_of_runtime_performance.3F
 
 object.destroy! :-P


In the CTFE section, you explain that it came from constant folding, but 
you don't point out how the two are different. After reading the 
section, a newbie might think that the term "CTFE" is for when constant 
folding evaluates function calls. But that's not what we mean by "CTFE".

What's missing is that CTFE is forced/guaranteed. It's not an 
optimization. When we say "CTFE", we mean the cases where compilation 
fails if the expression cannot be evaluated.

I doesn't help that the `i` variables in the examples are (seemingly) 
globals, but you also talk about putting them in a "busy inner loop". If 
I just copy the code as it is, `i` is a global and I get actual CTFE. If 
I put `i` in a loop, it's a local and it's up to the compiler if it does 
non-CTFE constant folding.

Also, you mistyped Stefan Koch's name.
Jan 03 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 03, 2018 at 02:44:21PM +0100, ag0aep6g via Digitalmars-d wrote:

 On 01/03/2018 02:51 AM, H. S. Teoh wrote:

 	https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time#But_what_of_runtime_performance.3F
 
 object.destroy! :-P


 
 In the CTFE section, you explain that it came from constant folding,
 but you don't point out how the two are different. After reading the
 section, a newbie might think that the term "CTFE" is for when
 constant folding evaluates function calls. But that's not what we mean
 by "CTFE".
 
 What's missing is that CTFE is forced/guaranteed. It's not an
 optimization.  When we say "CTFE", we mean the cases where compilation
 fails if the expression cannot be evaluated.


I wouldn't say that CTFE means that it is forced/guaranteed. But you're
right that it could be confusing the way I described it.  I added a
section to clarify that usually the compiler would not use CTFE to
constant-fold complex expressions, unless the value is required at
compile-time.



 I doesn't help that the `i` variables in the examples are (seemingly)
 globals, but you also talk about putting them in a "busy inner loop".
 If I just copy the code as it is, `i` is a global and I get actual
 CTFE. If I put `i` in a loop, it's a local and it's up to the compiler
 if it does non-CTFE constant folding.


Are you sure that's non-CTFE?  Isn't standard constant folding a part of
CTFE?  Anyway, the new section should clear up the confusion.



 Also, you mistyped Stefan Koch's name.


Fixed, thanks!


T

-- 
Try to keep an open mind, but not so open your brain falls out. -- theboz
Jan 04 2018
parent ag0aep6g <anonymous example.com> writes:
On 01/04/2018 11:59 PM, H. S. Teoh wrote:

 I wouldn't say that CTFE means that it is forced/guaranteed. But you're
 right that it could be confusing the way I described it.  I added a
 section to clarify that usually the compiler would not use CTFE to
 constant-fold complex expressions, unless the value is required at
 compile-time.


[...]

 Are you sure that's non-CTFE?  Isn't standard constant folding a part of
 CTFE?


Myself, I use "CTFE" only for the forced kind of compile-time evaluation.

This is my train of thought: CTFE is when `__ctfe` is set. Anything else 
would be too confusing. During forced compile-time evaluation, `__ctfe` 
is obviously set. But an optional optimization cannot set `__ctfe`, 
because that might change the value of the optimized expression. And 
that's something an optimization must not do.

Example:
----
int foo() { return __ctfe ? 10 : 20; }
int main() { return foo(); }
----

The program must return 20, no matter how aggressively the compiler 
optimizes.

As far as I can tell, the compilers share this view. For the example, 
they optimize `main` to `return 20;` [1]. So they evaluate `foo()` 
during compilation and use `__ctfe = false`.

The spec's wording isn't as clear as it could be, but can be interpreted 
this way, I think. The relevant statements are [2]:

1) "The __ctfe boolean pseudo-variable [...] evaluates to true at 
compile time, but false at run time".
2) "In order to be executed at compile time, the function must appear in 
a context where it must be so executed".

Unfortunately, the first one says "at compile time" which can very well 
be understood to mean that `__ctfe` should be true during constant 
folding as done by the optimizer.  But then the second statement would 
forbid this optional constant folding, because it doesn't allow 
execution "at compile time" unless the context forces it.

So I'm interpreting "at compile time" to be a synonym for the feature 
called "CTFE". And then it makes perfect sense (to me):

1) "The __ctfe boolean pseudo-variable [...] evaluates to true [during 
CTFE], but false [elsewhere]". -- Makes sense.
2) "In order to be executed [via CTFE], the function must appear in a 
context where [its result must be available during compilation]". -- 
Meaning that anything else isn't CTFE.


[1] https://godbolt.org/g/6xrDF7
[2] https://dlang.org/spec/function.html#interpretation
Jan 05 2018
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, January 04, 2018 14:59:44 H. S. Teoh via Digitalmars-d wrote:

 On Wed, Jan 03, 2018 at 02:44:21PM +0100, ag0aep6g via Digitalmars-d 


wrote:

 On 01/03/2018 02:51 AM, H. S. Teoh wrote:

   https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time#Bu
   t_what_of_runtime_performance.3F> >
 object.destroy! :-P


 In the CTFE section, you explain that it came from constant folding,
 but you don't point out how the two are different. After reading the
 section, a newbie might think that the term "CTFE" is for when
 constant folding evaluates function calls. But that's not what we mean
 by "CTFE".

 What's missing is that CTFE is forced/guaranteed. It's not an
 optimization.  When we say "CTFE", we mean the cases where compilation
 fails if the expression cannot be evaluated.


 I wouldn't say that CTFE means that it is forced/guaranteed. But you're
 right that it could be confusing the way I described it.  I added a
 section to clarify that usually the compiler would not use CTFE to
 constant-fold complex expressions, unless the value is required at
 compile-time.


 I doesn't help that the `i` variables in the examples are (seemingly)
 globals, but you also talk about putting them in a "busy inner loop".
 If I just copy the code as it is, `i` is a global and I get actual
 CTFE. If I put `i` in a loop, it's a local and it's up to the compiler
 if it does non-CTFE constant folding.


 Are you sure that's non-CTFE?  Isn't standard constant folding a part of
 CTFE?  Anyway, the new section should clear up the confusion.


As I understand it, CTFE and constant folding aren't really related at all.
Obviously, a value that was generated as part of CTFE could then take part
in constant folding if appropriate, because once the value is generated, it
really isn't any different from if that value were written by hand. However,
CTFE is never done as a compiler optimization. It's only ever done because a
value is required at compile time. So, constant folding won't even trigger
CTFE, just like the compiler will never decide that it might be more
efficient to call a function at compile time and thus call it at compile
time instead of runtime.

- Jonathan M Davis
Jan 04 2018
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 04, 2018 at 04:57:25PM -0700, Jonathan M Davis via Digitalmars-d
wrote:

 On Thursday, January 04, 2018 14:59:44 H. S. Teoh via Digitalmars-d wrote:


[...]

 Are you sure that's non-CTFE?  Isn't standard constant folding a
 part of CTFE?  Anyway, the new section should clear up the
 confusion.


 
 As I understand it, CTFE and constant folding aren't really related at
 all.  Obviously, a value that was generated as part of CTFE could then
 take part in constant folding if appropriate, because once the value
 is generated, it really isn't any different from if that value were
 written by hand. However, CTFE is never done as a compiler
 optimization. It's only ever done because a value is required at
 compile time. So, constant folding won't even trigger CTFE, just like
 the compiler will never decide that it might be more efficient to call
 a function at compile time and thus call it at compile time instead of
 runtime.


[...]

Ah, I see. That clears up some misunderstanding on my part. I'll update
the article accordingly. Thanks!


T

-- 
Chance favours the prepared mind. -- Louis Pasteur
Jan 04 2018