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.

Am 20.10.2017 um 02:58 schrieb Allin Cottrell: > 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 Do I remember correctly that the parallel-computing approach in gretl is roughly as follows: (?) - for some built-in functionality gretl uses OpenMP "automagically"

- for hansl scripting and thus user-designed parallelism it's MPI

I guess you explained the difference at the Berlin conference, but it's been a while.