<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif">> Personally I'd love to see one of the core algorithms (isocontouring?) currently using GetVoidPointer() / vtkTemplateMacro rewitten
</span>… <span style="font-family:"Verdana",sans-serif">Along with benchmarking<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Fully agree.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Andras<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>From:</b> vtk-developers <vtk-developers-bounces@public.kitware.com>
<b>On Behalf Of </b>Will Schroeder<br>
<b>Sent:</b> Friday, November 9, 2018 11:40 AM<br>
<b>To:</b> Allison Vacanti <allison.vacanti@kitware.com><br>
<b>Cc:</b> vtk-developers <vtk-developers@vtk.org><br>
<b>Subject:</b> Re: [vtk-developers] RFC: STL algos and C++11 for-range syntax with vtkDataArrays<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif">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.<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Nov 9, 2018 at 10:51 AM Allie Vacanti <<a href="mailto:allison.vacanti@kitware.com">allison.vacanti@kitware.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal">On Fri, Nov 9, 2018 at 10:19 AM Will Schroeder <<a href="mailto:will.schroeder@kitware.com" target="_blank">will.schroeder@kitware.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif">Great blog, thanks for the clear explanations and evaluations. It's a great resource for folks trying to keep up with VTK.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif">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 :-) <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif">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?<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<br>
<br>
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.<br>
<br>
The older APIs still have merit, IMO:<br>
<br>
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.<br>
<br>
vtkGenericDataArray API is the cornerstone of all of modern fast-path code.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
But for simple traversals, or work that could be accomplished by leveraging the STL? Iterators are the way to go :-)<br>
<br>
Allie<o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">William J. Schroeder, PhD<br>
Kitware, Inc. - Building the World's Technical Computing Software<br>
28 Corporate Drive<br>
Clifton Park, NY 12065<br>
<a href="mailto:will.schroeder@kitware.com" target="_blank">will.schroeder@kitware.com</a><br>
<a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com&data=02%7C01%7Classo%40queensu.ca%7Cce7963eb2bdb42f6e46f08d64661f59e%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636773783891778104&sdata=PHnBjiaRfntrcqGZHa1Wo5K6FKkgKUjE5PZ1QirbkV0%3D&reserved=0" target="_blank">http://www.kitware.com</a><br>
(518) 881-4902<o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>