Directly accessing underlying memory for image

Subject: Directly accessing underlying memory for image
From: Olzhas Zhumabek (anonymous.from.applecity_at_[hidden])
Date: 2019-05-06 19:13:21

Hi,

I am currently looking at issue about weird performance degradation with
VC++ <https://github.com/boostorg/gil/issues/234>. It seems like any usage
of iterators from views will cause performance penalty. Change from pure
memory (std::vector) -> gil algorithms -> range for causes exponential
degradation in performance in my benchmarks. It also seems like the issue
is not aliasing (input and output targets being the same). I also replaced
pixel plus with simple plus, since it is single channel pixel, and the
result didn't change.

I've tried to write a benchmark that tries to access underlying memory, but
the tests show that the computation is not correct. Could somebody please
have a look? This code is executed in the benchmark loop:

auto start = std::addressof(input_view(0, 0));
auto end = std::addressof(input_view(input_view.width() - 1,
input_view.height() - 1));
auto d_start = std::addressof(output_view(0, 0));
while (start != end) {
*d_start++ = *start + 1;
++start;
}

and here are declarations for those views:

gil::gray16_image_t img(1024, 1024, gray16_pixel_t{ 0 });
gil::gray16_image_t img2(1024, 1024, gray16_pixel_t{ 0 });

auto input_view = gil::const_view(img);
auto output_view = gil::view(img2);

It basically tries to add 1 to the zeroed image. I've tried to trace the
thing that operator() calls as I expect it returns reference to the wrong
place, but there seems to be multiple levels of templates that I am not
able to get through completely.

P.S. build environment is very hard to setup for the case in the github
issue, but it seems like using vcpkg makes it more or less straightforward.

Olzhas