Hi, Interesting work.
A few thoughts: - the benchmark_3_rasters_reference() could receive a few comments for non- advanced users to mention that it is correct only if all the rasters use Byte datatype, and all have the same block size. - It would be interesting to see a variant of this reference benchmark that does no computation at all, that is to say remove the for (int iY = 0; iY < nYValid; iY++) loop . That would show how much CPU computation time is really involved - 1000x1000 is somewhat small. Perhaps benchmark on larger rasters - with some tricks, it should probably be possible to have a compiler generate SSE2/AVX2 instructions for the computation loop of the reference benchmark, since it looks like an excellent candidate for vectorization. Or that could be done at hand with a few _mm_ intrinsincs. Do you think that Pronto could use that ? - it would be interested if you could also benchmark a VRT with Python numpy- based pixel function, and enable Numba. See http://www.gdal.org/gdal_vrttut.html#gdal_vrttut_derived_python (or just pure numpy based computation + Numba) - the benchmark only involve integer computations. What if you do linear combination of bands with floating-point coefficients for example ? Even > Dear all, > > I few times I have posted to the list trying to promote the idea of > providing iterators over pixels in a raster band , and more generally to > make raster data accessible using (future) standard conforming ranges. It > would make implementing algorithms on raster data a lot more intuitive. > These ideas are implemented in Pronto Raster which is an OSGeo Community > C++ library. Feedback in this list has been that such a solution would > incur costly computational overheads. > > I now have some preliminary benchmark results, where I compare Pronto Raster > solutions for a simple raster overlay operation (OUT = 3 * A + B * C) to a > direct and idiomatic GDAL implementation. The results seem to indicate that > overheads can be negligible, depending on which Pronto Raster functions are > used. I would very much appreciate it if some more experienced GDAL C++ > users could look at my "idiomatic GDAL implementation" to see if it really > is what it claims to be and I am not overstating the results. I can use > your help. > > I'd also be interested to hear any opinion about these results and the costs > / benefits associated with providing pixel ranges for raster bands. > > For details on the benchmark see here: > https://github.com/ahhz/raster/blob/master/docs/_posts/2018-06-14-Prelimina > ry-benchmark-results-are-promising.md or here: > http://ahhz.github.io/raster/Preliminary-benchmark-results-are-promising/ > > Many thanks, Alex -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
