<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
Thanks for the suggestions. These extra benchmarks should be feasible in the next week. Especially if I manage to get started properly with Google benchmark. I need to look into sse2/ave2. My feeling is that will be easier and more effective for the reference
case than for Pronto, because pronto is geared to express all operations at the pixel level.
<br>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Even Rouault <even.rouault@spatialys.com><br>
<b>Sent:</b> 14 June 2018 21:22:36<br>
<b>To:</b> gdal-dev@lists.osgeo.org<br>
<b>Cc:</b> Alex HighViz; Hagen-Zanker AH Dr (Civil & Env. Eng.)<br>
<b>Subject:</b> Re: [gdal-dev] Help with idiomatic GDAL solution for raster algebra benchmark</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hi,<br>
<br>
Interesting work.<br>
<br>
A few thoughts:<br>
<br>
- the benchmark_3_rasters_reference() could receive a few comments for non-<br>
advanced users to mention that it is correct only if all the rasters use Byte <br>
datatype, and all have the same block size.<br>
<br>
- It would be interesting to see a variant of this reference benchmark that <br>
does no computation at all, that is to say remove the for (int iY = 0; iY < <br>
nYValid; iY++) loop . That would show how much CPU computation time is really <br>
involved<br>
<br>
- 1000x1000 is somewhat small. Perhaps benchmark on larger rasters<br>
<br>
- with some tricks, it should probably be possible to have a compiler generate <br>
SSE2/AVX2 instructions for the computation loop of the reference benchmark, <br>
since it looks like an excellent candidate for vectorization. Or that could be <br>
done at hand with a few _mm_ intrinsincs. Do you think that Pronto could use <br>
that ?<br>
<br>
- it would be interested if you could also benchmark a VRT with Python numpy-<br>
based pixel function, and enable Numba. See<br>
<a href="http://www.gdal.org/gdal_vrttut.html#gdal_vrttut_derived_python">http://www.gdal.org/gdal_vrttut.html#gdal_vrttut_derived_python</a> (or just pure
<br>
numpy based computation + Numba)<br>
<br>
- the benchmark only involve integer computations. What if you do linear <br>
combination of bands with floating-point coefficients for example ?<br>
<br>
Even<br>
<br>
> Dear all,<br>
> <br>
> I few times I have posted to the list trying to promote the idea of<br>
> providing iterators over pixels in a raster band , and more generally to<br>
> make raster data accessible using (future) standard conforming ranges. It<br>
> would make implementing algorithms on raster data a lot more intuitive. <br>
> These ideas are implemented in Pronto Raster which is an OSGeo Community<br>
> C++ library. Feedback in this list has been that such a solution would<br>
> incur costly computational overheads.<br>
> <br>
> I now have some preliminary benchmark results, where I compare Pronto Raster<br>
> solutions for a simple raster overlay operation (OUT = 3 * A + B * C) to a<br>
> direct and idiomatic GDAL implementation. The results seem to indicate that<br>
> overheads can be negligible, depending on which Pronto Raster functions are<br>
> used. I would very much appreciate it if some more experienced GDAL C++<br>
> users could look at my "idiomatic GDAL implementation" to see if it really<br>
> is what it claims to be and I am not overstating the results. I can use<br>
> your help.<br>
> <br>
> I'd also be interested to hear any opinion about these results and the costs<br>
> / benefits associated with providing pixel ranges for raster bands.<br>
> <br>
> For details on the benchmark see here: <br>
> <a href="https://github.com/ahhz/raster/blob/master/docs/_posts/2018-06-14-Prelimina">
https://github.com/ahhz/raster/blob/master/docs/_posts/2018-06-14-Prelimina</a><br>
> ry-benchmark-results-are-promising.md or here:<br>
> <a href="http://ahhz.github.io/raster/Preliminary-benchmark-results-are-promising/">
http://ahhz.github.io/raster/Preliminary-benchmark-results-are-promising/</a><br>
> <br>
> Many thanks, Alex<br>
<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com">http://www.spatialys.com</a><br>
</div>
</span></font></div>
</body>
</html>