[Insight-developers] itkNarrowBandImageFilterBase using itkBarrier

[Raul San Jose Estepar]

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
>