[vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays

Will Schroeder will.schroeder at kitware.com
Fri Nov 9 11:39:32 EST 2018


Personally I'd love to see one of the core algorithms (isocontouring?)
currently using GetVoidPointer() / vtkTemplateMacro rewitten using the
preferred approach of your choosing :-) (or alternatively point us to good,
non-trivial examples). Along with benchmarking to see what the impacts
are... IMO code examples like this can go a long way to helping others do
the right thing.

On Fri, Nov 9, 2018 at 10:51 AM Allie Vacanti <allison.vacanti at kitware.com>
wrote:

> On Fri, Nov 9, 2018 at 10:19 AM Will Schroeder <will.schroeder at kitware.com>
> wrote:
>
>> Great blog, thanks for the clear explanations and evaluations. It's a
>> great resource for folks trying to keep up with VTK.
>>
>> As the blog hints at, one concern which is readily apparent when perusing
>> VTK source code is the number of options available to do the same thing.
>> I'd really like to see consolidation at some point. Many of our *core*
>> algorithms like contouring (whether you are looking at marching cubes,
>> synchronized templates or flying edges) use the old template macro
>> dispatch, while classes like vtkContourGrid use virtual methods etc. and so
>> on. If you are a budding visualization enthusiast or algorithm
>> writer/developer this can be quite confusing, as the code is increasingly
>> peppered with complexity -- a potential barrier to new developers and
>> community growth.
>>
>> Finally, the examples used in the blog to demonstrate the different
>> iterators are necessarily simple. However I'd like to see how these various
>> approaches work in more complex algorithms when data flies in many
>> simultaneous directions :-)
>>
>> But maybe the reality is that we need multiple options for good reasons
>> e.g., to address increasing computing complexity.... but I'd like to
>> explicitly agree this is the case rather than leaving a trail of alternate
>> implementations. So is there a roadmap for consolidation etc?
>>
>
> There is not a plan to deprecate the older methods at this point. In the
> past, changes to the vtkDataArray API have been frowned upon as they can
> force external (and internal!) code to require significant and expensive
> refactoring effort to use the new methods. My goal with this post is to
> provide education and insight into the various ways to access array data,
> and compare their good and bad traits as fairly as possible.
>
> A lot of the current preferred techniques build upon the older APIs and
> use them under the covers -- they just package them up in ways that are
> easier to use. For instance, the new iterators use vtkDataArrayAccessor,
> GetPointer, and VTK_ASSUME internally. The Accessors internally use both
> the vtkDataArray API and the vtkGenericDataArray API. I don't necessarily
> view the newer techniques as full-on replacements for the old APIs, but
> rather layers on top of them that simplify the usage of the older
> techniques, especially in performance-critical and generic contexts.
>
> The older APIs still have merit, IMO:
>
> vtkDataArray APIs are slow, but easy to write. They're just fine for fast
> prototyping and proof of concepts, and situations where a fast execution
> path is not as important as having broad support for any array that comes
> in. It's also critical to have for the fall-back pattern when a dispatch
> fails.
>
> vtkGenericDataArray API is the cornerstone of all of modern fast-path code.
>
> Accessors can and probably should be discouraged once the iterators are
> in. They still may be more convenient, however, when dealing with more
> complex traversals and access patterns that would be cumbersome using
> iterators.
>
> AOS::GetPointer and SOA::GetComponentArray are still extremely useful for
> writing very low-level optimized code in the rare cases where having
> separately tuned implementations for SOA vs. AOS would pay off.
>
> However....vtkDataArray::GetVoidPointer() should be chucked in the bin,
> IMO. It made sense when it was added, but it relies on the AOS assumption,
> which is no longer guaranteed. There would be significant internal and
> external development cost to move away from it, so idk what to do about
> that one. Maybe just permanent deprecation, or hide it behind a
> compatibility layer? We'd need a decent sized chunk of funding to migrate
> VTK itself away from it first.
>
> So, rather than deprecating and removing old methods, creating simpler
> layers on top of them and providing reference / educational resources seems
> like the better option to me.
>
> As for more complex examples, there are absolutely cases where iterator
> APIs are not going to be the best choice. For complicated code doing
> multiple lookups and random accesses, using a more verbose / explicit API
> will lead to much more maintainable, readable, and debuggable code. The
> array APIs or Accessors would still be preferred in those cases.
>
> But for simple traversals, or work that could be accomplished by
> leveraging the STL? Iterators are the way to go :-)
>
> Allie
>
>>

-- 
William J. Schroeder, PhD
Kitware, Inc. - Building the World's Technical Computing Software
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com
http://www.kitware.com
(518) 881-4902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtk-developers/attachments/20181109/98213c98/attachment-0001.html>


More information about the vtk-developers mailing list