[Insight-developers] Clearly something is wrong with ITKv4 multi-threading

[Nicholas Tustison]

Hi Hans,

I second Brad's assessment of "amazing" especially 
considering how long we've noticed this difference bet-
ween our previous implementations and the current 
one that exists in ITK.  This is really exciting!

Good work, Hans.

Thanks,
Nick



On Sep 24, 2013, at 11:04 PM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:

> Hans,
> 
> That improvement sounds amazing! I look forward to seeing this patch!
> 
> 
> Kent,
> 
> Just to follow up with my comment. I had previous done just about the same thing Hans did in his patch to the v3 MattesMutualInformation. I was suggesting using the same convention I did there. Specifically what was done here:
> 
> https://github.com/Kitware/ITK/blob/master/Modules/Registration/Common/include/itkMattesMutualInformationImageToImageMetric.h#L345
> 
> This is not the best way to do it, but if we do it this way consistently, when we come up with a better technique they can be easily all upgraded.
> 
> Thanks,
> Brad
> 
> On Sep 24, 2013, at 9:55 AM, "Johnson, Hans J" <hans-johnson at uiowa.edu> wrote:
> 
>> Kent,
>> 
>> I'm at the MICCAI conference and was able to do some diagnosis in the down
>> time today.  I believe that I have a patch that DRASTICALLY improves the
>> performance of the test case while preserving the numerical results.
>> 
>> Old   Code 3414 seconds
>> Fixed Code   90 seconds  <-- Yes 90 seconds.
>> 
>> It's late here in Japan, so I need to do some more validation and style
>> cleanup, but I hope to submit a patch tomorrow.
>> 
>> What I need from you today is that you address the comment in the gerrit
>> patch I pushed over the weekend.  Matt and Brad both had comments on ways
>> to improve style for consistency.  Once you have a new pull request in
>> place, I'll rebase my changes on those.
>> 
>> Hans
>> 
>> On 9/24/13 10:49 PM, "Williams, Norman K" <norman-k-williams at uiowa.edu>
>> wrote:
>> 
>>> This is interesting diagnostic work.
>>> 
>>> If the problem is threads sharing a smart pointer to a transform, could
>>> they instead share a plain old const pointer to the transform?  The
>>> threads aren't all modifying the transform, are they?
>>> --
>>> Kent Williams norman-k-williams at uiowa.edu
>>> 
>>> 
>> 
>> 
>> 
>> ________________________________
>> 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.
>> ________________________________
>