[ITK-dev] Kents Work on Explicit instantiation of ITK

Matt McCormick matt.mccormick at kitware.com
Tue Mar 17 12:21:26 EDT 2015


Hi Brad,

> That part has need been working for a very long time, and many of the parts that it used have been removed from ITK. Do you know of people using that part of Wrapping?

No, the code base would need to be cleaned up.

> Also the goal of that project was to instantiate everything, not just the most frequently used components. Additionally having to build WrapITK, would not make the compilation of SimpleITK any quicker.

The modules that are built are instantiated, and only with the types
specified. Eventually there should be a CastXML binary, so enabling
should not take any longer.

Matt

> Brad
>
> On Mar 17, 2015, at 11:00 AM, Matt McCormick <matt.mccormick at kitware.com> wrote:
>
>> Hi,
>>
>> Instead of maintaining a duplicate set of type instantiations, it may
>> be worth exploiting the ITK_WRAP_EXPLICIT option (see
>> Wrapping/Generators/Explicit).  This will re-use all the wrapping type
>> instantiation logic, which is also CMake configurable.
>>
>> 2 cents,
>> Matt
>>
>>
>>
>> On Tue, Mar 17, 2015 at 10:44 AM, Bradley Lowekamp
>> <blowekamp at mail.nih.gov> wrote:
>>> Hans,
>>>
>>> Thanks for sharing this work.
>>>
>>> I was able to utilize your script and methodology for SimpleITK to
>>> explicitly instantiate about 16 classes with their commonly used arguments
>>> as by SimpleITK [1]. I created a separate library in SimpleITK which
>>> contains these explicitly instantiated classes [2].
>>>
>>> These instantiations reduced the size of the .o files for SimpleITK by ~30%
>>> (500MB), and enabled linking once again on Windows 64. Some systems seem to
>>> also gain significant performance in build time (over 2X), but there are
>>> many reasons for it including running into memory or IO limitations on the
>>> individual system.
>>>
>>> However I was not able to get it working with the explicitly instantiated
>>> library as shared. The mixtures of export specification of the initial ITK
>>> declaration and the explicit instantiation linking specification didn't
>>> appear to work. I think they need to be consistent? I followed the
>>> methodology that was done for the MetaDataObjects[3]. If I build ITK and
>>> SimpleITK as shared but with the Explicit library as static it appears to
>>> work.
>>>
>>> Any help on explicitly instantiation with shared libraries would be
>>> appreciated!
>>>
>>> Thanks,
>>> Brad
>>>
>>> [1]
>>> https://github.com/SimpleITK/SimpleITK/blob/a6e62785a9e8ebc41dfb3e15f72e1985a620bf22/Code/Explicit/include/sitkExplicitITK.h
>>> [2]
>>> https://github.com/SimpleITK/SimpleITK/blob/a6e62785a9e8ebc41dfb3e15f72e1985a620bf22/Code/Explicit/src/CMakeLists.txt
>>> [3]
>>> https://github.com/InsightSoftwareConsortium/ITK/blob/d195bfb21e8af086c67208c2b96d5fd5992c66ca/Modules/Core/Common/include/itkMetaDataObject.h#L191-L224
>>>
>>> On Jan 28, 2015, at 12:16 PM, Johnson, Hans J <hans-johnson at uiowa.edu>
>>> wrote:
>>>
>>> Yes!  I’d love someone to investigate further:
>>>
>>>
>>> https://github.com/hjmjohnson/ITK/tree/TryExplicitInstantiationTesting
>>>
>>> https://github.com/hjmjohnson/ITK/commit/0576c75c8a760f1cafcde3125210134a39502304
>>>
>>>
>>> Hans
>>>
>>>
>>>
>>> _______________________________________________
>>> 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://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-developers
>>>
>


More information about the Insight-developers mailing list