[Insight-developers] itkNarrowBandImageFilterBase using itkBarrier

[Raul San Jose Estepar]

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
> >
>
>