octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #52809] interpreter performance is slow on dev


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #52809] interpreter performance is slow on development branch
Date: Wed, 10 Jan 2018 00:39:17 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Follow-up Comment #20, bug #52809 (project octave):

Well, cputime() is a pretty important function to leave to the vagaries of
unix time management and system interface of old.

It sounds to me that the issue is that some people may not be getting good
time resolution with cputime() because their system's support of the routine
we are using is lacking.  Some of these older routines have a reference called
CLOCK_PROCESS_CPUTIME_ID, which I've grepped for but don't see in Octave's
source code.  Just the fact there is such a setting suggests that, yeah,
different hardware could have different resolution...an undesirable result
from Octave's cputime() perspective.

Here is a good discussion on various time routines in Unix:

https://stackoverflow.com/questions/12392278/measure-time-in-linux-time-vs-clock-vs-getrusage-vs-clock-gettime-vs-gettimeof

and it sounds as though the latest Unix routine is this
guaranteed-to-be-high-resolution clock_gettime:

https://linux.die.net/man/3/clock_gettime

That routine has a selectable input, of which we'd be interested in
CLOCK_PROCESS_CPUTIME_ID.  It returns the information in a 


struct timespec {
        time_t   tv_sec;        /* seconds */
        long     tv_nsec;       /* nanoseconds */
};


I grep for tv_sec and tv_nsec and I see such elements in the Octave code,
quite a lot actually.  However, the usage looks to be for date/time related
code.  From what I looked at yesterday regarding cputime(), the impression I
got was that getrusage() was the means of determining cputime().  getrusage()
is one of the routines where the resolution can vary from system to system.

So, perhaps we need to switch the cputime() routine to using the
clock_gettime() C function (and keep any C++ objects to a minimum, just relay
the system-function output to the OV output).

What do people think?  Should we open a different bug report for this?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52809>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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