Compile-time optimization

[JS]

On Tuesday, 23 July 2013 at 22:38:35 UTC, Yota wrote:
> On Tuesday, 23 July 2013 at 20:11:21 UTC, JS wrote:
>> Your code doesn't exactly do what I wanted but probably 
>> because I wasn't clear... I think it is modifiable and solves 
>> the problem I was having(again, assuming your code is correct).
>>
>> Note though that something like
>>
>> string x = "asd"
>> join(x,...); // x is compile time known and should be joined 
>> at compile time. Not sure if D is smart enough to get this one?
>>
>> When I get some time later I'll check your code out, what I 
>> want to do is get something like
>>
>> string x = join(a, b, "a", "b"); to produce the same code as
>> string x = a~b~"ab";
>>
>> (no looping using for each except for string arrays)
>>
>> Thanks!
>
>
> Don't forget that tuples can store more than just types!  See 
> this for instance.
>
>   import std.stdio;
>
>   typeof(Xs[0]) sum(Xs...)()
>   {
>       pragma(msg, Xs); // tuple(1, 2, 3)
>       typeof(Xs[0]) y;
>       foreach(x; Xs) y ~= x;
>       return y;
>   }
>
>   int main() {
>       auto n = sum!(1, 2, 3);
>       enum m = sum!(1, 2, 3);
>
>       pragma(msg, typeof(n)); // int
>       writeln(n); // 6
>       writeln(m); // 6
>
>       return 0;
>   }
>
> Works great.  When I comment out the 'sum!("1", "2", "3")' and 
> replace it with a literal '6', the compiled EXE is byte for 
> byte exactly the same.  You can exchange the '+=' for '~=' and 
> it will concatenate strings instead.  Of course, now all 
> arguments MUST be known at compile time, but that's no surprise.
>
> PS: OK, just noticed that you were hoping to mix run time and 
> compile time arguments.  Oops....
> Oh well, posting anyway because I think it's neat. lol
>
> As for a~"B"~"C" compiling into a~"BC", I think we just need to 
> work on constant folding in the compiler. (If it doesn't 
> already do this anyway.)

Well, it's not that simple. Constant folding is easy when it is 
obvious to the compiler... but something buried in foreach loop 
that uses runtime and compile time objects is not obvious.

My three points out of the post is:

1. D needs some way to make doing this stuff easier.
2. It needs to be done! ;)
3. Goto 1.

I didn't realize D could even potentially do it, and still not 
sure if it can(have to check out T's post again and work with the 
code).

I think there is a lot of potential power behind such techniques 
with regard to optimization.

Suppose you are writing a matrix library. Wouldn't it be nice to 
have certain matrix computations that can be done at compile time 
actually done? (I suppose what I'm trying to do is extend the 
compiler's "constant folding" to be able to deal with much more 
complex cases).


Another way to potentially do it, I think, is for the compiler to 
automatically expand ctfe functions and replace runtime entities 
with "placeholder" code which is then expanded at runtime.

e.g., for a simple join

join(T...)(T t)
{
     string s;
     foreach(tt; t)
         s ~= tt;
     return s;
}

the compiler can unroll the loop to get

s ~= t[0]~t[1]~t[2]~...;

replace the compile time entities, e.g., suppose t[1] and t[3] 
are known at compile time at the invocation, then

s ~= t[0]~"abcd"~t[2]~"asdf";

then this code could be used inline for the join call instead of 
the actual code. The key here is there is no dependence on the 
for loop. If all arguments are compile-time evaluable, then s 
could be just a reference lookup to a static string. If it can't 
be done, then no big deal, it is optimized as far as it can go. 
Only if all arguments passed are runtime entities will the exact 
code be used.

This seems like it would take a pretty smart compiler and 
possibly it would have issues in some many cases. I personally 
don't mind writing the code itself but it seems pretty complex, 
and having no way to debug the code generation easily(AFAIK) 
makes it difficult to do.

Possibly using version(ctfe) can help... I'll work on it when I 
get a chance...