[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/
- [Octave-bug-tracker] [bug #52809] interpreter performance is slow on development branch, (continued)
- [Octave-bug-tracker] [bug #52809] interpreter performance is slow on development branch, Michael Godfrey, 2018/01/06
- [Octave-bug-tracker] [bug #52809] interpreter performance is slow on development branch, John W. Eaton, 2018/01/08
- [Octave-bug-tracker] [bug #52809] interpreter performance is slow on development branch, Dan Sebald, 2018/01/09
- [Octave-bug-tracker] [bug #52809] interpreter performance is slow on development branch, Michael Godfrey, 2018/01/09
- [Octave-bug-tracker] [bug #52809] interpreter performance is slow on development branch, Dan Sebald, 2018/01/09
- [Octave-bug-tracker] [bug #52809] interpreter performance is slow on development branch, Rik, 2018/01/09
- [Octave-bug-tracker] [bug #52809] interpreter performance is slow on development branch, Michael Godfrey, 2018/01/09
- [Octave-bug-tracker] [bug #52809] interpreter performance is slow on development branch, Dan Sebald, 2018/01/09
- [Octave-bug-tracker] [bug #52809] interpreter performance is slow on development branch, Dan Sebald, 2018/01/09
- [Octave-bug-tracker] [bug #52809] interpreter performance is slow on development branch, Michael Godfrey, 2018/01/09
- [Octave-bug-tracker] [bug #52809] interpreter performance is slow on development branch,
Dan Sebald <=
- [Octave-bug-tracker] [bug #52809] interpreter performance is slow on development branch, John W. Eaton, 2018/01/10
- [Octave-bug-tracker] [bug #52809] interpreter performance is slow on development branch, Rik, 2018/01/10
- [Octave-bug-tracker] [bug #52809] interpreter performance is slow on development branch, Dan Sebald, 2018/01/10