[Insight-developers] itk performance numbers

[Johnson, Hans J]

Rupert,

In ITKv4 the metrics ARE THE OPTIMIZED VERSIONS.  We moved all the optimized versions of the code out of review and replaced the old un-optimized versions.

My guess is that we fixed many problems with thread-safety, and that in many cases these fixes were known to cause some performance hits.  The goal was to keep the v3Registration framework backwards compatible but thread-safe in a minimalistic effort and focus all our novel and performance development efforts on the v4 registration framework.

Hans

--
Hans J. Johnson, Ph.D.
hans-johnson at uiowa.edu<mailto:hans-johnson at uiowa.edu>
Assistant Professor of Psychiatry
University of Iowa Carver College of Medicine
W278 GH, 200 Hawkins Drive
Iowa City, Iowa 52242
Phone:  319-353-8587

From: Rupert Brooks <rupert.brooks at gmail.com<mailto:rupert.brooks at gmail.com>>
Date: Thursday, July 26, 2012 7:56 AM
To: Bradley Lowekamp <blowekamp at mail.nih.gov<mailto:blowekamp at mail.nih.gov>>
Cc: ITK <insight-developers at itk.org<mailto:insight-developers at itk.org>>
Subject: Re: [Insight-developers] itk performance numbers

Brad,

The false sharing issue is a good point - however, i dont think this is the cause of the performance degradation.  This part of the class (m_Threader, etc) has not changed since 3.20.  (I used the optimized metrics in my 3.20 builds, so its in Review/itkOptMeanSquares....) It also does not explain the performance drop in single threaded mode.

Testing will tell...  Seems like a Friday afternoon project to me, unless someone else gets there first.

Rupert

--------------------------------------------------------------
Rupert Brooks
rupert.brooks at gmail.com<mailto:rupert.brooks at gmail.com>



On Wed, Jul 25, 2012 at 5:18 PM, Bradley Lowekamp <blowekamp at mail.nih.gov<mailto:blowekamp at mail.nih.gov>> wrote:
Hello,

Continuing to glance at the class.... I also see the following member variables for the MeanSquares class:

  MeasureType *   m_ThreaderMSE;
  DerivativeType *m_ThreaderMSEDerivatives;

Where these are index by the thread ID and access simultaneously across the threads causes the potential for False Sharing, which can be a MAJOR problem with threaded algorithms.

I would think a good solution would be to create a per-thread data structure consisting of the Jacobin, MeasureType, and DerivativeType, plus padding to prevent false sharing, or equivalently assigning max data alignment to the structure.

Rupert, Would like to take a stab at this fix?

Brad


On Jul 25, 2012, at 4:31 PM, Rupert Brooks wrote:

Sorry if this repeats - i just got a bounce from Insight Developers, so im trimming the message and resending....
--------------------------------------------------------------
Rupert Brooks
rupert.brooks at gmail.com<mailto:rupert.brooks at gmail.com>



On Wed, Jul 25, 2012 at 4:12 PM, Rupert Brooks <rupert.brooks at gmail.com<mailto:rupert.brooks at gmail.com>> wrote:
Aha.  Heres around line 183 of itkTranslationTransform.

// Compute the Jacobian in one position
template <class TScalarType, unsigned int NDimensions>
void
TranslationTransform<TScalarType, NDimensions>::ComputeJacobianWithRespectToParameters(
  const InputPointType &,
  JacobianType & jacobian) const
{
  // the Jacobian is constant for this transform, and it has already been
  // initialized in the constructor, so we just need to return it here.
  jacobian = this->m_IdentityJacobian;
  return;
}

Thats probably the culprit, although the root cause may be the reallocating of the jacobian every time through the loop.

Rupert

<snipped>




________________________________
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.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-developers/attachments/20120726/28737dd8/attachment.htm>