[Insight-users] multi-threading capable metric

[Miller, James V (Research)]

Ahh...

I threaded the MatchCardinalityImageToImageMetric as an experiment in 
what it would take to thread (all) the ImageToImageMetrics.  Eventually, 
I would like to move this capability into all ImageToImageMetrics. As 
you noticed, it is not that much work once the architecture is in place.
I think it took me about an hour or two to move the threading code from 
ImageSource to this metric.  Most of that time was dealing with const
correctness (which if you look in the metric, I just casted away...)

What is holding me back is that I have an unresolved problem with the 
multi-threaded image metric. A registration method using this metric
actually ran slower (wall time) than a single threaded version. This
smells of a resource contention problem.  I didn't see anything that 
would have caused extra mutexes to be used (didn't look like any
SmartPointers were being used). My recollection is that the metric 
was only slower on one architecture.  The other architectures saw 
a traditionally linear speedup.

Other people have multithreaded image to image metrics (not in the library)
that do not slow down with the number of threads.  They may not have 
been using the one architecture that showed the slowdown. Another
hypothesis is that the MatchCardinality metric is much simpler to the
other metrics people are threading.  So any threading/mutex overhead was
hidden by the computational complexity of the metric.

Jim





-----Original Message-----
From: Michael [mailto:michakuhn@gmx.ch]
Sent: Monday, May 17, 2004 6:45 AM
To: insight-users
Subject: [Insight-users] multi-threading capable metric


Hi,

I've seen that there is a multi-threading capable metric 
(MatchCardinalityImageToImageMetric) in the toolkit. I've had a look at 
the code and noticed that only little changes are required to change 
this metric into a mean squares metric. Even adding a GetDerivative() 
method was possible with little effort. I didn't analyze other cases 
very closely, but my impression is that it would be possible to adapt 
this threading capable metric to other metric functions as well. 
Therefore I thought that it might be reasonable to introduce a generic 
threading capable metric (with a basic architecture similar to the one 
of the MatchCardinalityImageToImageMetric) from which different specific 
threading capable metric subclasses can be derived.

Can anybody see any major disadvantages (or implementation problems) 
caused by such a threading capable superclass? Or can maybe somebody 
confirm that such a class would be a reasonable extension?

Thanks,

Michael

_______________________________________________
Insight-users mailing list
Insight-users@itk.org
http://www.itk.org/mailman/listinfo/insight-users