Boost logo

Boost :

From: Hailin Jin (hljin_at_[hidden])
Date: 2006-10-18 16:45:30


Hi Ulli -- we just tried your test file with GCC 4.0.2, GCC 4.1.1 and
Visual Studio 2005 (VC8). I used Cygwin for both GCC tests. My machine
is Xeon 3.2 dual CPU. Both proxy and accessor implementation run at the
SAME speed (release builds: -O2 for GCC and /O2 for Visual Studio). So
could it be that GCC 3 is not doing a good in optimizing the code?

Hailin

Ullrich Koethe wrote:
> Lubomir Bourdev wrote:
>>
>>> On the other hand, a PixelDereferenceAdapter is semantically also a
>>> view, so the use of the view idea could be extended.
>>
>>
>> PixelDereferenceAdapter is not a view. It is a function object to be
>> invoked upon pixel access, similar to your Pixel Accessor. You can
>> easily attach it to any iterator, locator or a view.
>>
>
> Consider the following view-like syntax:
>
> pixel_view_A(dest_iter) = pixel_view_B(src_iter);
>
> Now, when you absorb the pixel_view objects into the iterators by
> means of proxies, you get the GIL style of adaptation:
>
> *pixel_view_iter_A = *pixel_view_iter_B;
>
> If you replace the assignment with a normal member function, you get
> VIGRA data accessors (which, by the way, were invented by Dietmar
> Kuehl, IIRC):
>
> pixel_view_A.set(pixel_view_B(src_iter), dest_iter);
>
> All these should be semantically equivalent -- the only difference is
> syntax and possibly performance. Hence I'm saying that pixel access
> modifiers are essentially views, and treating them in that way may
> simplify the documentation.
>
> The following advantages and disdvantages of either approach have
> already been pointed out:
>
> Proxies: + nice syntax in algorithms
> + compatible to STL
> + can be chained
> - harder to implement, harder to understand implementation
> - may not work under some exotic circumstances
> DataAccessors: + easy to implement, easy to understand
> + can be chained
> + do always work (even on non-conforming compilers)
> - slightly less readable syntax in algorithms
>
> To add some hard data to the comparison, I performed a benchmark were
> I timed two proxy implementations vs the accessor approach for the
> task of converting a planar RGB image into an interleaved one and vice
> versa. It turned out that on my platform (Pentium M 1.7 GHz, cygwin
> gcc 3.4.4), both proxy implementations were 30 to 60 percent _slower_
> than the equivalent data accessor version. The code is attached (it's
> a stand-alone program).
>
>>
>> I understand your motivation for using pixel adaptors, but in my opinion
>> the benefits of using PixelDereferenceAdapter outweigh its
>> disadvantages.
>
> I'm not convinced.
>
>>
>> GIL incorporates a mechanism for active reduction of code bloat due to
>> variant instantiations. I will present this approach at the LCSD
>> workshop in the upcoming OOPSLA conference, which is in less than a
>> week: http://lcsd.cs.tamu.edu/2006/
>>
>
> I'd like to read this paper.
>
>>
>>> 3. I don't like that the input/output image format (jpeg, png etc.)
>>> must be hardcoded in the program (by using jpeg_read_image() etc.).
>>
>>
>> We initially had a combined I/O methods like:
>>
>> template <typename Image>
>> void read_image(const char* file, Image& img) {
>> switch (image_type_from_file_name(file)) {
>> case kJPEG: jpeg_read_image(file,img); break;
>> case kTIFF: tiff_read_image(file,img); break;
>> ...
>> }
>> }
>>
>> We decided to remove them for three reasons [snip] there are
>> plans to put in ASL a more advanced GIL I/O that allows for dynamic
>> registration of file format modules.
>
> VIGRA's import/export library almost supports this (the only missing
> piece is the possibility to register new converters at runtime - at
> the moment, they must be known at compile time, but otherwise there is
> no need for a design modification).
>
>>> 6. GIL may have alignment problems. For example, the variant
>>> template allocates internal memory as "char[MAX_SIZE]" but then
>>> reinterpret_casts it to an image type.
>>
>>
>> MAX_SIZE is determined by taking the maximum of the size_of of each
>> element in the MPL vector of image types with which the variant is
>> instantiated. So for every variant it is different, and the appropriate
>> size is evaluated at compile time.
>>
>
> I didn't say that the number of bytes was too small. I said that an
> image object might be required to start at a multiple-of-8 address
> (say), whereas a char array may start at an arbitrary address. So the
> reinterpret_cast may return a forbidden address.
>
>>
>>> Casts from "signed short *" to "pixel<int16s, rgb_t> *" and similar
>>> (see the tutorial) are also problematic
>>
>>
>> This cast is necessary to go from the outside world (pointer to the
>> beginning of the image) into GIL.
>> It is not obvious to me how to avoid it. How does VIGRA deal with the
>> case where the user constructs an 8-bit RGB image by providing VIGRA
>> with a raw pointer to the first pixel?
>>
>
> The DataAccessor takes care of this -- the iterator uses the original
> pointer (see the PlanarAccessor in the attached program).
>
>>
>> We have been discussing the accessors/DereferenceAdaptors and promotion
>> traits issues in separate threads. Aside from these differences with
>> VIGRA, do you see any issues with the GIL interfaces that would prevent
>> porting the Vigra algorithms to GIL, or that would affect their
>> performance?
>> If yes, what interfaces are missing and what algorithms need them?
>>
>
> Three things come to mind:
> - many more type conversions; e.g. int8 => uint16; RGB <=> LAB etc.
> - adaptors for the subsampled image view
> - support for multi-dimensional images (e.g. volume data, image
> sequences)
>
> Another important point are RGBA operations. In most cases, the alpha
> channel is to be treated differently from the other channels, so you
> can't just use component-wise operators as for the other color models.
> VIGRA doesn't have an explicit RGBA type (TinyVector<T, 4> can be used
> instead), because so far no-one came up with a convincing proposal for
> these operations. But without them, RGBA is pretty useless.
>
> I don't think any of this is a show stopper, but it means considerable
> work.
>
> And, of course, the documentation has to be improved a lot... (I
> didn't look at the test suite.)
>
> Regards
> Ulli
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk