[Top][All Lists]
[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/