<html>
<head>
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><font size="-2">Even,<br>
<br>
thank you for your prompt reply. To be more specific, the
successive steps of my procedure are<br>
<br>
1] gdalwarp of a vrt file referring to 8 bands (stored as
gtiffs) of Landsat8 image from UTM into the equivalent</font><font
size="-2"><font size="-2"> EPSG:4326 </font>vrt file:<br>
gdalwarp -of vrt -r cubic -t_srs EPSG:4326 -tr 0.00025 0.00025
-te -77.54 69.69 -70.01 72.07 -srcnodata 0 -dstnodata 0
LC80260102014095LGN00_REF.vrt
LC80260102014095LGN00_REF_EPSG4326.vrt <br>
<br>
(this first step is almost instantaneous given that it only
produces a vrt file.<br>
<br>
2] translate the obtained vrt file into a gtiff file using
gdal_translate:<br>
gdal_translate -co INTERLEAVE=BAND -co COMPRESS=LZW -co
PREDICTOR=2 -co BIGTIFF=IF_SAFER
LC80260102014095LGN00_REF_EPSG4326.vrt<small> </small>LC80260102014095LGN00_REF_EPSG4326.tif<br>
<br>
It is in this second step that htop reports the use of
multithreads by </font><font size="-2">gdal_translate. <br>
<br>
Any idea where I am doing something wrong or why htop</font><font
size="-2"> reports the use of multithreads by gdal_translate in
this case?<br>
</font><font size="-2"><font size="-2"><br>
As a side note, I noticed that applying the same procedure 8
times on the individual bands is much faster (~100 times) than
applying it once starting from the vrt file referring to the 8
individual bands as described above but also fail to
understand such a behaviour.<br>
<br>
Thank you again for your time and your amazing contributions
to gdal.<br>
<br>
Best regards,<br>
<br>
Pierre<br>
<br>
<br>
</font></font>On 01/14/2015 10:52 AM, Even Rouault wrote:<br>
</div>
<blockquote cite="mid:1421229178.54b63c7a79884@imp.free.fr"
type="cite">
<pre wrap="">Pierre,
Nor gdal_translate nor the VRT driver uses multithreading. But it is possible
that the driver that handles the underlying dataset referenced by the VRT uses
multithreading. There are very few of them however. I can only think of :
- JP2KAK. You can specify JP2KAK_THREADS=1
- JP2OpenJPEG. You can specify GDAL_NUM_THREADS=1
Even
</pre>
<blockquote type="cite">
<pre wrap="">Hello,
while translating a vrt file into a tif file with gdal_translate, I
noticed thanks to htop utility that gdal_translate is using
multithreading (typicallay 4 threads). I fail to find any multithreading
option for gdal_translate (contrary to gdal_warp that has a multi option
and where the number of threads can be set with -wo "NUM_THREADS=x").
Is there any possibility to prevent gdal_translate from multithreading?
Setting the global environment variable OMP_NUM_THREADS to 1 does not
help. I had a quick look to gdal_translate.cpp but did not find any
explicit reference to multithreading.
This behaviour of gdal_translate is an issue in case of distributed
computing. Indeed, cluster nodes with many cores are spending most of
their time with kernel time to serve a number of threads largely
exceeding the number of CPUs.
Any hint on how to solve this problem will be greatly appreciated.
Cheers,
Pierre
------------------------
Pierre Soille
EC Joint Research Centre
Ispra, Italy
------------------------
_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>