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-1... -- Eric Niebler Boost.org http://www.boost.org