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

Andras Lasso lasso at queensu.ca
Fri Nov 9 11:56:35 EST 2018

> Personally I'd love to see one of the core algorithms (isocontouring?) currently using GetVoidPointer() / vtkTemplateMacro rewitten … Along with benchmarking

Fully agree.

I wish there was a +1 button that I could click to show support, instead of littering everyone’s mailbox with yet another email. I hope VTK forum will be available soon.


From: vtk-developers <vtk-developers-bounces at public.kitware.com> On Behalf Of Will Schroeder
Sent: Friday, November 9, 2018 11:40 AM
To: Allison Vacanti <allison.vacanti at kitware.com>
Cc: vtk-developers <vtk-developers at vtk.org>
Subject: Re: [vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays

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<mailto:allison.vacanti at kitware.com>> wrote:
On Fri, Nov 9, 2018 at 10:19 AM Will Schroeder <will.schroeder at kitware.com<mailto: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 :-)


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<mailto:will.schroeder at kitware.com>
(518) 881-4902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtk-developers/attachments/20181109/e0675396/attachment.html>

More information about the vtk-developers mailing list