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