<div dir="ltr">Brian,<div><br></div><div>Do you mean the generality of my AVX  internal precision problem?  </div><div><br></div><div>I agree that is a very common issue, the surprising thing there was that we were already constraining the code generation in way that worked as over the different processor generations and types we used, up until we hit the first Haswell cpus with AVX2 support (even though no AVX2 instructions were generated).  Perhaps it shouldn't have surprised me, but It took me a few tests to work that out because the problem was confounded with the problem I discuss in this thread (which is unrelated).  Once I separated them it was easy to spot.</div>

<div><br></div><div>So that is a solved issue for now, but I am still interested the partitioning issue in the image metric, as I only have a work around for now.</div><div><br></div></div><div class="gmail_extra"><br><br>

<div class="gmail_quote">On Wed, Mar 19, 2014 at 11:24 AM, brian avants <span dir="ltr"><<a href="mailto:stnava@gmail.com" target="_blank">stnava@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><a href="http://software.intel.com/en-us/articles/consistency-of-floating-point-results-using-the-intel-compiler" target="_blank">http://software.intel.com/en-us/articles/consistency-of-floating-point-results-using-the-intel-compiler</a><br>



<div><br></div><div>just as an example of the generality of this problem</div></div><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div><br></div>brian<br><div><br></div><div><br>

</div></div></font></span><div><div class="h5">
<br><br><div class="gmail_quote">On Wed, Mar 19, 2014 at 11:22 AM, Simon Alexander <span dir="ltr"><<a href="mailto:skalexander@gmail.com" target="_blank">skalexander@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div dir="ltr">Brian, Luis,<div><br></div><div>Thanks.  I have been using Mattes as you suspect.<br><div><br></div><div>I don't quite understand how precision is specifically the issue with # of cores.  There are all kinds of issues with precision and order of operations in numerical analysis, but often data partitioning (i.e. for concurrency) schemes can be set up so that the actual sums are done the same way regardless of number of workers, which keeps your final results identical.  Is there some reason this can't be done for the Matte's metric?   I really should look at the implementation to answer that, of course.</div>





<div><br></div><div>Do you have a pointer to earlier discussions?  If I can find the time I'd like to dig into this a bit, but I'm not sure when I'll have the bandwidth.  I've "solved" this currently by constraining the core count.</div>





</div><div><br></div><div>Perhaps interestingly, my earlier experiments were confounded a bit by a precision issue, but that had to do with intrinsics generation on my compiler behaving differently on systems with AVX2 (even though only AVX intrinsics were being generated).  So that made things confusing at first until I separated the issues.</div>





</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 19, 2014 at 9:49 AM, brian avants <span dir="ltr"><<a href="mailto:stnava@gmail.com" target="_blank">stnava@gmail.com</a>></span> wrote:<br>





<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">yes - we had several discussions about this during v4 development.<div><br></div><div>experiments showed that differences are due to precision.  </div>





<div><br></div><div>one solution was to truncate precision to the point that is reliable. </div>

<div><br></div><div>but there are problems with that too.   last i checked, this was an </div><div><br></div><div>open problem, in general, in computer science.</div></div><div class="gmail_extra"><span><font color="#888888"><br clear="all">





<div><div>

<br></div>brian<br><div><br></div><div><br></div></div></font></span><div><div>
<br><br><div class="gmail_quote">On Wed, Mar 19, 2014 at 9:16 AM, Luis Ibanez <span dir="ltr"><<a href="mailto:luis.ibanez@kitware.com" target="_blank">luis.ibanez@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">







<div dir="ltr">Hi Simon,<div><br></div><div>We are aware of some multi-threading related issues in </div><div>the registration process that result in metric values changing</div><div>depending on the number of cores used.</div>








<div><br></div><div>Are you using the MattesMutualInformationMetric ?</div><div><br></div><div>At some point it was suspected that the problem was the </div><div>result of accumulative rounding, in the contributions that</div>








<div>each pixel makes to the metric value.... this may or may</div><div>not be related to what you are observing.</div><div> </div><div><br></div><div>   Thanks</div><div><br></div><div>       Luis</div><div><br></div></div>








<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 20, 2014 at 3:27 PM, Simon Alexander <span dir="ltr"><<a href="mailto:skalexander@gmail.com" target="_blank">skalexander@gmail.com</a>></span> wrote:<br>








<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I've been finding some regressions in registration results when using systems with different numbers of cores (so the thread count is different).  This is resolved by fixing the global max.<div>








<br></div>

<div>It's difficult for me to run the identical code on against 4.4.2, but similar experiments were run in that timeframe without these regressions.</div><div><br></div><div>I recall that there were changes affecting multhreading in the v4 registration in 4.5.0 release, so I thought this might be a side effect.</div>










<div><br></div><div>So a few questions:</div><div><br></div><div>Is this behaviour expected? </div><div><br></div><div>Am I correct that this was not the behaviour in 4.4.x ?</div><div><br></div><div>Does anyone who has a feel for  the recent changes 4.4.2 -> 4.5.[0,1]  have a good idea where to start looking?  I haven't yet dug into the multithreading architecture, but this "smells" like a data partitioning issue to me.</div>










<div><br></div><div>Any other thoughts?</div><div><br></div><div>cheers,</div><div>Simon</div></div>
<br>_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at<br>
<a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Kitware offers ITK Training Courses, for more information visit:<br>
<a href="http://kitware.com/products/protraining.php" target="_blank">http://kitware.com/products/protraining.php</a><br>
<br>
Please keep messages on-topic and check the ITK FAQ at:<br>
<a href="http://www.itk.org/Wiki/ITK_FAQ" target="_blank">http://www.itk.org/Wiki/ITK_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.itk.org/mailman/listinfo/insight-developers" target="_blank">http://www.itk.org/mailman/listinfo/insight-developers</a><br>
<br>_______________________________________________<br>
Community mailing list<br>
<a href="mailto:Community@itk.org" target="_blank">Community@itk.org</a><br>
<a href="http://public.kitware.com/cgi-bin/mailman/listinfo/community" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/community</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at<br>
<a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Kitware offers ITK Training Courses, for more information visit:<br>
<a href="http://kitware.com/products/protraining.php" target="_blank">http://kitware.com/products/protraining.php</a><br>
<br>
Please keep messages on-topic and check the ITK FAQ at:<br>
<a href="http://www.itk.org/Wiki/ITK_FAQ" target="_blank">http://www.itk.org/Wiki/ITK_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.itk.org/mailman/listinfo/insight-developers" target="_blank">http://www.itk.org/mailman/listinfo/insight-developers</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>