"jerro" <a@a.com> wrote in message news:qpipqzzdbpkoxtzvhefw@forum.dlang.org...
>> Compared to normal iteration schemes, yes.  It may be comparable to opApply in terms of performance though.  If you're curious, look at the Fiber context switching code (starting at switchIn and switchOut).
>
> It's much slower than opApply. This loop takes 70s on my machine:
>
>
> foreach(el; visitor(Iterable(1000_000_000)))
>     sum += 1;
>
> And this one takes 2.7s:
>
> auto iter(int n)
> {
>     struct I
>     {
>         int n;
>
>         int opApply(int delegate(ref int) dg)
>         {
>             for(int i = 0; i < n; i++)
>                 if(int r = dg(i))
>                     return r;
>             return 0;
>         }
>     }
>
>     return I(n);
> }
>
> foreach(el; iter(1000_000_000))
>     sum += 1;
>

What compiler options is that with?

> What compiler options is that with?

I used DMD and compiler flags -O -inline -release on x86_64 linux.

On Wed, May 2, 2012 at 9:38 AM, jerro <a@a.com> wrote:

> What compiler options is that with?
>>
>
> I used DMD and compiler flags -O -inline -release on x86_64 linux.
>
>
It may be slow relative to incrementing a integer:

65 seconds without any command line options.
54 seconds with  -O -inline -release.

vs:

3.2 seconds dmd without any command line options.
2.2 seconds with dmd -O -inline -release.

And that is for 1000_000_000 Fiber context switches.
intel 2600K @ 4.5GHz, gnu/linux, ubuntu 12.04.

On Tuesday, 1 May 2012 at 08:26:45 UTC, Nick Sabalausky wrote:
> A little write-up I just did on something I thought was pretty cool:
>
> Combine Coroutines and Input Ranges for Dead-Simple D Iteration
> https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration

Call me stupid, but I've absolutely no idea what you're doing. What problem does the InputVisitor solve ? What are the current solutions ? What is the intent of your code ? What are the supposed advantages ? Your article says nothing about it.

"SomeDude" <lovelydear@mailmetrash.com> wrote in message news:ypakkndfsibcbgeljvgu@forum.dlang.org...
> On Tuesday, 1 May 2012 at 08:26:45 UTC, Nick Sabalausky wrote:
>> A little write-up I just did on something I thought was pretty cool:
>>
>> Combine Coroutines and Input Ranges for Dead-Simple D Iteration https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration
>
> Call me stupid, but I've absolutely no idea what you're doing. What problem does the InputVisitor solve ? What are the current solutions ? What is the intent of your code ? What are the supposed advantages ? Your article says nothing about it.

Just an easier-to-read/write alternative to an opApply or an input range. More natural and straightforward than a hand-written input range, and cleaner syntax than opApply (and without opApply's downside of not being usable as a range).

> It may be slow relative to incrementing a integer:

The opApply isn't just incrementing an integer - it's
calling a function through a pointer. A loop that just
increments an integer is an order of magnitude faster.
This code (I used assembly because a compiler would
optimize away such a simple loop) runs in 0.27s on my
machine:

    auto sum = 0;
    auto n = 1000_000_000;

    asm
    {
        mov EAX, n;
        mov EBX, sum;
loop:
        dec EAX;
        inc EBX;
        test EAX, EAX;
        jne loop;
        mov sum, EBX;
    }

Ranges like iota are often as fast as using a for loop.
For example this code:

    auto sum = 0;
    foreach(i; iota(to!int(args[1])))
        sum += i;

runs in 0.52 seconds when compiled with gdc with flags
-O2 -finline-functions -frelease. When compiled with -O3,
gcc uses paddd instruction and it runs in 0.1s.

> And that is for 1000_000_000 Fiber context switches.

I'm not saying that D fibers are slow - fiber context
switches are way faster than thread context switches.
When using them for IO, such as in vibe.d, overhead
of fibers is negligible. But when used for iteration,
they are way slower than the alternatives, because in
that case there shouldn't be any context switches at all.

"Nick Sabalausky" <SeeWebsiteToContactMe@semitwist.com> wrote in message news:jnr241$nh1$1@digitalmars.com...
> "SomeDude" <lovelydear@mailmetrash.com> wrote in message news:ypakkndfsibcbgeljvgu@forum.dlang.org...
>> On Tuesday, 1 May 2012 at 08:26:45 UTC, Nick Sabalausky wrote:
>>> A little write-up I just did on something I thought was pretty cool:
>>>
>>> Combine Coroutines and Input Ranges for Dead-Simple D Iteration https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration
>>
>> Call me stupid, but I've absolutely no idea what you're doing. What problem does the InputVisitor solve ? What are the current solutions ? What is the intent of your code ? What are the supposed advantages ? Your article says nothing about it.
>
> Just an easier-to-read/write alternative to an opApply or an input range. More natural and straightforward than a hand-written input range, and cleaner syntax than opApply (and without opApply's downside of not being usable as a range).
>

Of course, based on the timing results Jerro and Rory reported, Adam's mixin helper for opApply probably hits a better balance of performance vs usability.