Re: [hub] on the specialized iteration over elements

czw., 16 kwi 2026 o 23:49 Ion Gaztañaga <[email protected]> napisał(a):

> El 16/04/2026 a las 21:42, Andrzej Krzemienski via Boost escribió:
> > Hi Everyone,
> > Once again, thank you Joaquín for this contribution to the community.
> >
> > This is not really a review, but I wanted to talk about this idea to
> > implement a specialized algorithm for iterating over the container
> elements
> > in the form of hub::visit.
> >
> > First, should we draw from this a more general observation that iterators
> > are an abstraction with overhead, and other containers (deque?) would
> also
> > benefit from this inversion-of-control approach?
>
> Yes, this is a real abstraction penalty. For deque, I'm expementing (you
> can see it in the develop branch of containers) with segmented iterators
> (based on Austern's classic paper,
> https://lafstern.org/matt/segmented.pdf) and the initial tests shows
> improvement vs current STL implementations.
>
> Member functions know the internal structure of the container, so that
> iteration can be implemented more efficiently.
>
> Another advantage of those "visit"-like member functions is that in some
> platforms, knowing the internal data structure allows using prefetch
> instructions so that the CPU can do work while the memory we are very
> probably going to touch next is already requested to the cache.
>
> With hive, I think the same optimization applies: the member function
> iterates more efficiently and explicitly prefetching next block and/or
> element array (the hardware prefetcher probably only helps with
> contiguous memory accesses) while calling the function object (which is
> doing work) can mask the memory latency and make a difference.
>
> The STL is great but any abstraction has a penalty. I suspect
> std::ranges has even a greater performance penalty.


Ok, so in the context of this review, focusing only on the API part, maybe
this concept of "iteration with the opportunity to use segmented iteration"
calls for a "generic" interface with the ability for concrete containers to
customize (specialize) for their implementation details?

If I am implementing my own iterator-agnostic algorithm, I would like to be
able to say, "iterate over this range in the fastest possible way".

Regards,
&rzej;
_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/NIRLRSNJC3GKUCJ5G326U7ICHQFRJB2P/