On Thu, 19 Oct 2017, Stefano wrote:
re Jack's suggestion of stopwatching my jobs, I try to explain
more clearly
my question: there _are_ big differences in execution time, that is 100%
sure. It may depend, for unclear reasons, on the (i) the total number of jobs
or (ii) the number of Gretl jobs or (iii) both. Given that I cannot control
RAM and CPU use of other useres I cannot measure the coeteris paribus effect
of changing the number of my simultaneous Gretl jobs. So the question is:
does anybody know if there are any reasons why running more than one Gretl
job at a time may affect speed?
You will get a significant slow-down if the total number of threads
exceeds the number of cores on the machine (or the number of
supported threads if this exceeds the number of "real cores" due to
hyper-threading).
By default gretl expects to use OpenMP on a multi-core machine. You
may find that it helps to limit the number of threads spawned by
each instance of gretl, as in
OMP_NUM_THREADS=2 gretlcli <jobspec>
or possibly
OPENBLAS_NUM_THREADS=2 gretlcli <jobspec>
if gretl is linked against an OpenBLAS library that uses "raw"
pthreads instead of OpenMP (not recommended, BTW). You could
probably set both environment variables "just in case".
Worst case is this sort of thing: you have a machine with 8 cores
and you launch 4 gretl instances without limiting their thread
usage; then each instance will try to use 8 threads and performance
will degrade severely.
Allin