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".
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
> Incredibly, the conditional nulling-out inside your iterator
> increment() appears to be optimized away altogether. Its 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
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
-- Eric Niebler Boost.org http://www.boost.org
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk