Errors in TDPL

[bearophile]

Andrei Alexandrescu:

>That's not too difficult; for integers, retro(iota(a, b)) could actually be a rewrite to iota(b - 1, a, -1).<

This is good. In my dlibs the xchain converts xchain(xchain(x, y), z) and similar into xchain(x, y, z).


>Figuring out all corner cases, steps greater than 1, and what to do for floating point numbers is doable but not trivial either, and works against modularity.<

I suggest to focus on the most important case, integer/uint indexes (and +1 or -1 increment).

My post has shown some different problems:
- A longer compilation time (and binary size)
- A 1/10 performance when the code is compiled in standard way, this is bad
- a smaller performance when the code is compiled in optimized mode.

The asm of the opt version shows calls to two or more functions inside the loop, and one of those functions is not so small, this probably reduces performance more than an extra inlined product. So in my opinion getting rid of those calls (inlining them) is more important if you want a faster retro(iota).

------------------------

I have added your last version:

// test4
import std.c.stdio: printf;
import std.range: iota;
void main() {
    enum int N = 100_000_000;
    int count;
    foreach (i; iota(N - 1, 0, -1))
        count++;
    printf("%d\n", count);
}



Running time, best of 3, seconds:
  test1:     0.31
  test1 opt: 0.07
  test2:     0.31
  test2 opt: 0.12
  test3:     6.38
  test3 opt: 0.52
  test4:     4.70
  test4 opt: 1.25

not opt version = dmd (no other option)
opt version = dmd -O -release -inline

Compile times opt version, seconds:
  test1: 0.05
  test2: 0.05
  test3: 0.28
  test4: 0.29

The compilation time is the same, the not-opt test4 is faster than not-opt test3, but opt test4 is quite slower than opt test3.

Bye,
bearophile