[Insight-developers] itkNarrowBandImageFilterBase using itkBarrier

[Bill Hoffman]

There are a few problems.   Please check the dashboard for warnings and failed tests.
Looks like borland does not like the itkNarrowBandImageFilterBaseTest.  Also, there
are a few scattered unused variable warnings.


Thursday, August 28 2003


-Bill


At 02:35 PM 8/27/2003, Raul San Jose Estepar wrote:

>Josh,
>
>given the progress made with itkBarrier I decided to commit
>the new itkNarrowBandImageFilterBase (I keep in mind your "hold off"
>recommendation). I want to see how the class makes through the testing
>system. If many problems arise, we will go back to the previous version.
>
>
>/Raul
>
>
>On Tue, 26 Aug 2003, Joshua Cates wrote:
>
>> Yes at some point we should propagate these changes all the way up to
>> FiniteDifferenceSolver.  That really was the way to go from the beginning.
>> There may be significant speedup for 2D images or smaller volumes on the
>> dense solver.  I wouldn't expect much speedup on larger volumes, however,
>> since the time spent in each iteration for many applications is so huge
>> (sometimes on the order of several minutes).
>>
>> Josh.
>>
>> ______________________________
>>  Josh Cates
>>  Scientific Computing and Imaging Institute
>>  University of Utah
>>  Email: cates at sci . utah . edu
>>  Phone: (801) 587-7697
>>  URL:   http://www . sci . utah . edu/~cates
>>
>>
>> On Tue, 26 Aug 2003, Raul San Jose Estepar wrote:
>>
>> >
>> >
>> > Roger,
>> >
>> > I didn't make a thorough exec time testing but I don't think it is
>> > merelly platform dependent.
>> > Before we were spawning threads
>> > twice per iteration. That means that for 50 iteration we were using OS
>> > resources 100 times. Now, threads are spawned only ones and the iterative
>> > scheme runs with the same set of threads (following totally the spirit of
>> > itkParallelSparseField). I think that this change could be abstracted in
>> > itkFiniteDifference to have a pure threaded ApplyUpdate and ComputeUpdate.
>> > That would be a significant speedup for DenseSolvers as well. However,
>> > this kind of changes are for post-realease period for sure.
>> >
>> >
>> > /Raul
>> >
>> > On Tue, 26 Aug 2003, Joshua Cates wrote:
>> >
>> > > Hi Raul,
>> > >
>> > > Great news! Did you see a speedup from these changes?  Could be platform
>> > > dependent.
>> > >
>> > > My inclination would be to hold off checking in these changes for a couple
>> > > of weeks until after the release is tagged. This will give us some time to
>> > > work out the remaining barrier class bug on windows.  Since the narrow
>> > > band solver is not yet in widespread use, these optimizations won't be
>> > > missed yet.
>> > >
>> > > Josh.
>> > >
>> > > ______________________________
>> > >  Josh Cates
>> > >  Scientific Computing and Imaging Institute
>> > >  University of Utah
>> > >  Email: cates at sci . utah . edu
>> > >  Phone: (801) 587-7697
>> > >  URL:   http://www . sci . utah . edu/~cates
>> > >
>> > >
>> > > On Tue, 26 Aug 2003, Raul San Jose Estepar wrote:
>> > >
>> > > >
>> > > > Hi Josh and et al.,
>> > > >
>> > > > we have ready and revamped implementation of the NarrowBand solver that
>> > > > use
>> > > > itkBarrier to synchronized the computing flow without spawning threads
>> > > > several times (as we talked).
>> > > >
>> > > > I was thinking about checking in today. Is it a good idea to hold on this
>> > > > till itkBarrier problems are solved?.
>> > > >
>> > > > We have another class (itkIsoContourDistanceImageFilter) that relies on
>> > > > itkBarrier to sync threads.
>> > > >
>> > > > Indeed, (maybe Luis you have the answer to this) I tried to check in the
>> > > > code yesterday evening to see how things were going through the system but
>> > > > CVS didn't allow me. The new implementation
>> > > > revamps the previous one,
>> > > > is there any lock to this kind of check in?. I'm aware of this change
>> > > > affects several methods in that class, but the code conceptually looks
>> > > > neater plus a significant performance improvement is achieved.
>> > > >
>> > > >
>> > > > /Raul
>> > > >
>> > > >
>> > > > On Mon, 25 Aug 2003, Joshua Cates wrote:
>> > > >
>> > > > > Hi Jim,
>> > > > >
>> > > > > We added some additional testing to itkBarrierTest.cxx and managed to get
>> > > > > failure (timeouts) on several Windows platforms.  Looks like there is a
>> > > > > bug somewhere in the Windows implementation.  I will try to debug this
>> > > > > locally on my Borland build.  In the meantime, I've removed the offending
>> > > > > code for itkBarrierTest so as not to slow down continuous builds.
>> > > > >
>> > > > > Josh.
>> > > > >
>> > > > > ______________________________
>> > > > >  Josh Cates
>> > > > >  Scientific Computing and Imaging Institute
>> > > > >  University of Utah
>> > > > >  Email: cates at sci . utah . edu
>> > > > >  Phone: (801) 587-7697
>> > > > >  URL:   http://www . sci . utah . edu/~cates
>> > > > >
>> > > > >
>> > > > > _______________________________________________
>> > > > > Insight-developers mailing list
>> > > > > Insight-developers at itk . org
>> > > > > http://www . itk . org/mailman/listinfo/insight-developers
>> > > > >
>> > > >
>> > > > _______________________________________________
>> > > > Insight-developers mailing list
>> > > > Insight-developers at itk . org
>> > > > http://www . itk . org/mailman/listinfo/insight-developers
>> > > >
>> > >
>> > >
>> >
>> > _______________________________________________
>> > Insight-developers mailing list
>> > Insight-developers at itk . org
>> > http://www . itk . org/mailman/listinfo/insight-developers
>> >
>>
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk . org
>> http://www . itk . org/mailman/listinfo/insight-developers
>>
>
>_______________________________________________
>Insight-developers mailing list
>Insight-developers at itk . org
>http://www . itk . org/mailman/listinfo/insight-developers