un-requested compiler optimisations

spir denis.spir at gmail.com
Thu Apr 14 11:24:41 PDT 2011


On 04/14/2011 06:57 PM, Andrej Mitrovic wrote:
> This leads me to another question I've always wanted to ask. A call such as:
>
> auto b=map!foo(map!bar1(map!bar2(a));
>
> This constructs a lazy range. What I'm wondering is if there are any
> performance issues when constructing long chains of ranges like that,
> since this basically routes one function to the next, which routes to
> the next, etc. E.g:
>
> auto a = [1, 2];
> auto b = retro(a);
> auto c = retro(b);
> auto d = retro(c);
>
> Under the surface, I assume calling d.front would mean the following calls:
> d.front()->c.back()->b.front()->a.back()
>
> Or another example:
> auto b = retro(retro(a));
>
> Can the compiler optimize the second case and convert b.front to just
> do one field access?

If it does optimise, then it is definitely a compiler bug. Since you 
*explicitely* ask for a double reverse, it *must* just do it. Suppressing them 
is here just breaking the language's semantics!

It is not the compiler's role to interpret, meaning to guess your reasons for 
requesting that; and the compiler is certainly not in position to do it. Even 
less to *judge* that request as stupid, and thus ignore it (unlike in the army 
;-). You are the master, asking for stupid computations is both your right and 
your problem ;-)
Anyway, there are probably perfectly valid reasons to do a double reverse; at 
least (0) exploring (1) teaching (2) benchmarking.

In a similar vein:
{
     long n;
     static N = 10_000;
     foreach (_ ; 0..N) {
         n = factorial(9);
     }
}

Should the compiler optimise by computing n only once? (even possibly at 
compile-time)
Then, what if I'm doing that in purpose? (be it stupid or not)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com



More information about the Digitalmars-d-learn mailing list