I think you can call SWIG with the -threads argument on the command line so it will always release the GIL. Could be an easy option if it works<br><br>On Tuesday, 13 September 2016, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le mardi 13 septembre 2016 11:07:39, Rutger a écrit :<br>
> I overlooked the fact that it still moves through Python, is that the<br>
> 'only' hurdle preventing parallel IO?<br>
<br>
Not sure to understand your question. But if you have several sources, you<br>
could potentially do parallelized reading of them from the Python code by<br>
using Python threads and GDAL Python API. But looking in the SWIG generated<br>
code, it doesn't seem that SWIG releases the GIL automatically before calling<br>
native code. Hum... So that should probably added manually, at least around<br>
GDALRasterIO() calls, otherwise you'll get zero perf improvements.<br>
<br>
> Since gdalwarp for example has the<br>
> -multi flag, it seems as if GDAL is capable of it, or is that a<br>
> specific/specialized implementation?<br>
<br>
Parallelized I/O doesn't mean much by itself without more context. You may<br>
want to parallelize reading of different regions of the same dataset, or<br>
parallelize reading of different datasets. Due to GDAL objects not being<br>
thread-safe, the first case (reading of different regions of the same dataset)<br>
can be solved with the second one by opening several datasets for the same<br>
filename.<br>
<br>
Regarding gdalwarp -multi, here's how that works. When you warp a dataset,<br>
there's a list of all chunks (windows) to be processed that is generated.<br>
gdalwarp -multi does the following<br>
<br>
Thread I/O                                              Thread computation<br>
Read data for chunk 1<br>
Read data for chunk 2                   Do calculations for chunk 1<br>
Write output of chunk 1                 Do calculations for chunk 2<br>
Read data for chunk 3<br>
Write output of chunk 2                 Do calculations for chunk 3<br>
<br>
<br>
><br>
> Numba has several options which might eliminate using Python during<br>
> execution. There are c-callbacks:<br>
> <a href="http://numba.pydata.org/numba-doc/dev/user/cfunc.html" target="_blank">http://numba.pydata.org/numba-<wbr>doc/dev/user/cfunc.html</a><br>
<br>
You can also use @jit(nopython=True, nogil=True) and your Python method will<br>
end up being pure native code (provided that you don't use too high level stuff<br>
otherwise the jit'ification will fail with an exception).<br>
<br>
And for code that is not inlined in the VRT, you can also add cache=True so<br>
that the jit'ification can be reused.<br>
<br>
With all that the cost of the Python layer becomes neglectable (except loading<br>
the Python environment the first time, if not already loaded, but for a<br>
computation that will be longer than a few seconds, that's not really a big<br>
deal)<br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'gdal-dev@lists.osgeo.org')">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/gdal-dev</a></blockquote>