[ITK] [ITK-users] VectorImage vs image of vectors
Olivier Commowick
Olivier.Commowick at inria.fr
Tue Nov 11 06:23:03 EST 2014
Hello
It works perfectly fine for me as well (I get 0.22s for slow vs 1.6s for fast), the labels are indeed wrong now :) I even wonder if we shouldn’t extend this patch to itk vector object in the filter, but that would make the code rather ugly.
Thanks
Olivier
> On Nov 10, 2014, at 21:20 , Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>
> Hello,
>
> Thanks for providing the test case, and the report of this performance issue.
>
> Please find the following patch in gerrit:
>
> http://review.source.kitware.com/#/c/17928/ <http://review.source.kitware.com/#/c/17928/>
>
> Initial performance of your test
>
> $ ./bin/smoothingTest
> Fast filter time: 5.558
> Slow filter time: 33.7993
>
> After patch:
>
> $ ./bin/smoothingTest
> Fast filter time: 5.50313
> Slow filter time: 2.4181
>
> It appears the labels are now wrong :) I'm really amazed with what I presume is the good auto-vectorization SSE optimization that clang 6.0 compiler was able to do. There are other more complicated memory layout optimization that could be done, but I see no need. So I am getting a 13.9X speed up on my laptop.
>
> Please test to see if this works for you too.
>
> Brad
>
>
>
> On Nov 10, 2014, at 12:02 PM, Bradley Lowekamp <blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov>> wrote:
>
>> The underlying interaction with the buffer and the accessor is rather complicated. But the results of a access to the image is a reference not a copy.
>>
>> I believe The problem with this filer and the VectorImage is the number temporaries created in these blocks:
>>
>> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/ImageFilterBase/include/itkRecursiveSeparableImageFilter.hxx#L105-L123 <https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/ImageFilterBase/include/itkRecursiveSeparableImageFilter.hxx#L105-L123>
>>
>> each of the terms creates a temporary variable length vector which causes an memory allocation.
>>
>> I'll think about the best way to do this. I bet with out much trouble we can get 10-30x performance restoration... here.
>>
>> Brad
>>
>>
>> On Nov 10, 2014, at 11:28 AM, Olivier Commowick <Olivier.Commowick at inria.fr <mailto:Olivier.Commowick at inria.fr>> wrote:
>>
>>> Hi,
>>>
>>> I finally took some time to test this further using ITK smoothing filters. Here is an example file that illustrates my problem. Running it in some profiler, it appears that the time is truly lost in allocations and freeing elements (variable length vectors, method AllocateElements and free) when browsing elements in a vector image (while this doesn’t happen for images of itk vectors). Looking into it, there is a part of itk vectorimage I didn’t know about which is the accessor classes and functors.
>>>
>>> Would someone have an explanation of the system itself and if it might spend its time creating variable length vectors, or if the problem would come from somewhere else ? Nothing urgent though, I took the second technique in the previous email for my urgent things.
>>>
>>> Thanks in advance
>>> Olivier
>>>
>>>
>>>> On Nov 3, 2014, at 17:18 , Williams, Norman K <norman-k-williams at uiowa.edu <mailto:norman-k-williams at uiowa.edu>> wrote:
>>>>
>>>> 2 observations:
>>>>
>>>> 1. I think the redundant SetSize you mentioned is almost certainly
>>>> unnecessary. I¹ve seen similar unnecessary vector/array sizing other
>>>> places in ITK; I think it arose out of an abundance of caution, and just
>>>> never showed up on anyone¹s optimization radar yet.
>>>>
>>>> 2. There¹s a technique you can use to get around the
>>>> itk::Image<itk::Vector<TScalar,TVecLength>, TDim> problem, if there is a
>>>> small, finite number of possible vector lengths. Put the code using the
>>>> vector image inside a function templated over TVecLength. Then at
>>>> runtime, determine the vector length and invoke the template function with
>>>> that vector length.
>>>>
>>>> E.G.
>>>>
>>>> template<typename TScalar,unsigned NVecLength, unsigned NDim>
>>>> void DoSomething()
>>>> {
>>>> typedef itk::Image< itk::Vector<TScalar, NVecLength>, NDim > ImageType;
>>>> ...
>>>> }
>>>>
>>>> int main(int,char *[])
>>>> {
>>>> ...
>>>> switch(vecLength)
>>>> {
>>>> case 3:
>>>> DoSomething<double,3,3>();
>>>> break;
>>>> case 11:
>>>> DoSomething<double,11,3>();
>>>> Š
>>>> }
>>>> }
>>>>
>>>> This is of course in most cases bad C++ programming practice, but it does
>>>> allow you to accommodate different data types in a program.
>>>>
>>>> On 11/3/14, 8:39 AM, "Olivier Commowick" <Olivier.Commowick at inria.fr <mailto:Olivier.Commowick at inria.fr>>
>>>> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> I encountered some weird behavior in ITK. For some reason, I have in my
>>>>> code some vector images that I need to smooth using a Gaussian filter. It
>>>>> appears that whether the image is stored as a VectorImage or an Image of
>>>>> itk Vectors is actually extremely important in terms of performance for
>>>>> this task. Namely, if using VectorImages, the processing time can be much
>>>>> worse (30s vs 1s with an image of vectors). My problem is that I cannot
>>>>> really use the templated itk::Image <itk::Vectors <Type, Size> , Ndim >
>>>>> since I do not know Size at compilation time.
>>>>>
>>>>> Looking deeper into the code, I have two questions for whoever would know
>>>>> about these images:
>>>>> - the first one is on the Variable length vector: it seems to me that the
>>>>> operator= method always starts by destroying current data, even if the
>>>>> vector size is the same. It doesn¹t seem really efficient so I was
>>>>> wondering if there was any reason for that
>>>>> - the second one is on the VectorImage itself: is there something in it
>>>>> that would justify the computation times to be much worse ?
>>>>>
>>>>> If someone has any info on which image type I should be using or why
>>>>> VectorImage would be slower, I would be grateful.
>>>>>
>>>>> Thanks in advance
>>>>>
>>>>> ---
>>>>>
>>>>> Olivier Commowick, Ph.D.
>>>>> Research Scientist
>>>>> INRIA Rennes - Bretagne Atlantique, VISAGES Team
>>>>> Campus de Beaulieu
>>>>> 35042 Rennes
>>>>> FRANCE
>>>>>
>>>>> Phone: +33 2 99 84 25 92
>>>>> Email: Olivier.Commowick at inria.fr <mailto:Olivier.Commowick at inria.fr>
>>>>> Web: http://olivier.commowick.org/ <http://olivier.commowick.org/>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _____________________________________
>>>>> Powered by www.kitware.com <http://www.kitware.com/>
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
>>>>>
>>>>> Kitware offers ITK Training Courses, for more information visit:
>>>>> http://www.kitware.com/products/protraining.php <http://www.kitware.com/products/protraining.php>
>>>>>
>>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>>> http://www.itk.org/Wiki/ITK_FAQ <http://www.itk.org/Wiki/ITK_FAQ>
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://public.kitware.com/mailman/listinfo/insight-users <http://public.kitware.com/mailman/listinfo/insight-users>
>>>>
>>>>
>>>>
>>>> ________________________________
>>>> Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you.
>>>> ________________________________
>>>
>>>
>>> ---
>>>
>>> Olivier Commowick, Ph.D.
>>> Research Scientist
>>> INRIA Rennes - Bretagne Atlantique, VISAGES Team
>>> Campus de Beaulieu
>>> 35042 Rennes
>>> FRANCE
>>>
>>> Phone: +33 2 99 84 25 92
>>> Email: Olivier.Commowick at inria.fr <mailto:Olivier.Commowick at inria.fr>
>>> Web: http://olivier.commowick.org/ <http://olivier.commowick.org/>
>>>
>>>
>>>
>>>
>>>
>>> <smoothingTest.cxx>
>>
>> _____________________________________
>> Powered by www.kitware.com <http://www.kitware.com/>
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html <http://www.kitware.com/opensource/opensource.html>
>>
>> Kitware offers ITK Training Courses, for more information visit:
>> http://www.kitware.com/products/protraining.php
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/insight-users
>> _______________________________________________
>> Community mailing list
>> Community at itk.org
>> http://public.kitware.com/mailman/listinfo/community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20141111/ba830821/attachment-0001.html>
-------------- next part --------------
_____________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Kitware offers ITK Training Courses, for more information visit:
http://www.kitware.com/products/protraining.php
Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-users
More information about the Community
mailing list