Re: [boost] [range] fat iterators?

Subject: Re: [boost] [range] fat iterators?
From: Eric Niebler (eniebler_at_[hidden])
Date: 2013-11-12 12:13:07

On 11/12/2013 8:21 AM, Evgeny Panasyuk wrote:
> 12.11.2013 19:41, Eric Niebler:
>> I've now built a filter_range, transform_range, and an
>> istream_range in this vein. Initial results are looking promising,
>> but I haven't benchmarked performance, yet. A commenter on my blog
>> claims to have benchmarked perf of istream_range, with good
>> results, which is encouraging.
> 
> While new "slim" istream_range is faster than version with "fat" 
> iterators, it is still not the fastest possible. In particular, it
> does two comparisons per cycle iteration: one is "!rng_->next()", and
> another is comparison of iterators, like "it != last".
<snip>

The commenter on my blog claims this extra check is optimized away by a
smart compiler like gcc. He says[^1]:

> Your istream_range solution is pretty awesome. I tested the generated
> assembly on gcc.godbolt.org and compared it to plain old while()
> looping and D-style iteration
> http://coliru.stacked-crooked.com/a/d22192e264e59715
> 
> Incredibly, the conditional nulling-out inside your iterator
> increment() appears to be optimized away altogether. It’s very
> surprising that the compiler can prove that a nullptr value will be
> compared to the other nullptr value lurking inside the end()
> iterator. Essentially the same assembly is generated for all 3
> approaches.

It remains to be seen how well compilers can optimized several stacked
range adapters, but at least in the simple cases we don't have to accept
compromise.

[^1]:
http://ericniebler.com/2013/11/07/input-iterators-vs-input-ranges/#comment-1140

-- 
Eric Niebler
Boost.org
http://www.boost.org