gnuastro-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gnuastro-devel] [task #13986] Determine the number of threads at runtim


From: Mosè Giordano
Subject: [gnuastro-devel] [task #13986] Determine the number of threads at runtime
Date: Sun, 01 May 2016 23:50:06 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.2.0

URL:
  <http://savannah.gnu.org/task/?13986>

                 Summary: Determine the number of threads at runtime
                 Project: GNU Astronomy Utilities
            Submitted by: giordano
            Submitted on: lun 02 mag 2016 01:50:05 CEST
         Should Start On: lun 02 mag 2016 00:00:00 CEST
   Should be Finished on: lun 02 mag 2016 00:00:00 CEST
                Category: Development
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                  Effort: 0.00

    _______________________________________________________

Details:

I don't see the point of having the --with-numthreads configure option.  What
happens if the program is built on computer X with N threads and then shipped
on another system Y with M threads?  I guess that on Y it'll use N threads by
default.  This is what happens with running programs provided by distro
repository in most GNU/Linux systems.  What happens if configure script is run
while the system is experiencing a heavy load (so nprocs returns a number
lower than the number of processors actually installed)?  I guess that all
programs will use by default a low number of threads because of an initial
"misconfiguration".

Instead, I think that it's much safer to determine runtime (rather than at
configuration time) the number of threads with `sysconf(_SC_NPROCESSORS_ONLN)'
(or `get_nprocs()', but `_SC_NPROCESSORS_ONLN' should be more portable).  This
is better also because this function returns the number of processors actually
available, so that the programs won't overload the system if already under
stress.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/task/?13986>

_______________________________________________
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]