freepooma-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Freepooma-devel] mixing domain and stride information


From: Richard Guenther
Subject: Re: [Freepooma-devel] mixing domain and stride information
Date: Tue, 12 Apr 2005 11:15:26 +0200 (CEST)

On Mon, 11 Apr 2005, ron hylton wrote:

> Hi all.
>
> I just tried to migrate some of my code from the CodeSourcery release to
> FreePooma and I'm finding that some custom engine types I've written don't
> work.  After some digging I've come to feel that the original behavior was
> the correct one.
>
> The issue is the separation of domain data and stride data.  Domains
> describes how elements are logically addressed by integers, and strides how
> the data is physically laid out in specific engines.  The original Pooma
> kept these quite distinct, but I've found places in FreePooma where strides
> in BrickViewBase are being computed from domain information in BrickBase
> rather than stride values from BrickBase.  I really think BrickViewBase
> should ask the BrickBase what the strides are and not make assumptions about
> how domains are mapped to memory.
>
> The four places I've found are
>
> BrickBase<Dim>::restoreStrides()
> BrickViewBase::viewInit(const BrickBase<Dim> &bbase, const Interval<Dim>
> &domain)
> BrickViewBase::viewInit(const BrickBase<Dim> &bbase, const Range<Dim>
> &domain)
> BrickViewBase::sliceInit(const Interval<BaseDim> &baseDom, const
> SliceRange<BaseDim,Dim> &dom)
>
> I think it's important to keep domain information and physical layout
> information separate, and I would urge that the original behavior be
> restored in those four places and any others where similar changes have been
> made.

I guess you are talking about current CVS HEAD, not the FreePOOMA-2.4.1
release.

I agree in principle that domain information and physical layout kept
separate; though I do not see how this is violated at the moment.  I
think it would help to see how one of your custom engines uses the
BrickBase class to help me understand the problem.  The changes I made
resulted from optimization work, and it would be a lot simpler, if f.i.
the compressible engines were not so tightly integrated with the
uncompressed ones.  I.e. I consider this sharing of BrickBase bad and
do not see much benefit in it - so, in the long run I might have
disentangled Brick and CompressibleBrick.

Maybe you can help me see the actual problems.

Thanks,
Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]