cpu time

5 views
Skip to first unread message

Paul Zimmermann

unread,
Nov 7, 2007, 7:20:49 AM11/7/07
to sage-s...@googlegroups.com
Hi,

it seems the cpu time reported by SAGE does not include that of the spawned
processes (sorry for using an old release :-)

mermoz% sage
----------------------------------------------------------------------
| SAGE Version 2.8.10, Release Date: 2007-10-28 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------

sage: p=65257526772644948764799212887702573391887715235981530343703506731
sage: time FindGroupOrder(p,489731259)
CPU times: user 0.87 s, sys: 0.07 s, total: 0.94 s
Wall time: 70.30
2^2 * 3^2 * 7 * 13 * 5521 * 589213 * 1103171 * 1149307 * 1310261 * 10091759 * 63065897 * 120597437 * 48024231181

I doubt the given cpu times take into account the PARI/GP computations. As a
comparison, Magma takes 55s for that computation on my computer.

The wall time is not very useful (my machine has a load of 3-4). It would be
more useful to have to cpu time used by the spawned processes, or simply the
total cpu time used by SAGE and those processes.

Paul Zimmermann

def FindGroupOrder(p,s):
K = GF(p)
v = K(4*s)
u = K(s^2-5)
x = u^3
b = 4*x*v
a = (v-u)^3*(3*u+v)
A = a/b-2
x = x/v^3
b = x^3 + A*x^2 + x
E = EllipticCurve(K,[0,b*A,0,b^2,0])
return factor(E.cardinality())

John Cremona

unread,
Nov 7, 2007, 7:34:55 AM11/7/07
to sage-s...@googlegroups.com
Paul,

It is true that the cpu time does not include any of the child
processes, and also that in many cases most of the computation is done
by those.

In this case the cardinality is either computed via a call to the
libpari function ellap, or by running gp and calling the sea
implementation there. The crossover is at 10^18 (as you can see by
typing E.cardinality??) so your example is using sea via gp.

Many people agree with you that it would be more useful to have the
aggregate time. There are some complicated issues though, which I
cannot remember (despite searching sage-devel). I expect that this
will come up at SD6! Someone more expert in Sage than me might give
you a better answer.

John


--
John Cremona

Simon King

unread,
Nov 7, 2007, 8:47:53 AM11/7/07
to sage-support
John,

> Many people agree with you that it would be more useful to have the
> aggregate time.

So do i.

In the meantime, it would be ok for me to determine the cpu time of,
say, a Singular child process via the Singular timer. But apparently
this is non-trivial, according to this example:

sage: R=singular.ring(0,'(x(1..10))','dp')
sage: singular.eval('system(\"--ticks-per-sec\",100)')
''
sage: singular.eval('int t=timer')
''
sage: singular.eval('ideal G = maxideal(14)')
''
sage: singular.eval('timer-t')
'0'

When i do the same thing in Singular, the answer is not 0 but 35
(hence, 0.35s cpu-time).

Is there a way to access the Singular timer?

Yours
Simon

Martin Albrecht

unread,
Nov 7, 2007, 8:57:59 AM11/7/07
to sage-s...@googlegroups.com
On Wednesday 07 November 2007, Simon King wrote:
> John,
>
> > Many people agree with you that it would be more useful to have the
> > aggregate time.
> So do i.

I made this trac ticket #1118

http://trac.sagemath.org/sage_trac/ticket/1118

> In the meantime, it would be ok for me to determine the cpu time of,
> say, a Singular child process via the Singular timer. But apparently
> this is non-trivial, according to this example:

Actually, for Singular it is trivial:

sage: R=singular.ring(0,'(x(1..10))','dp')

sage: t= singular.cputime()


sage: singular.eval('ideal G = maxideal(14)')

sage: singular.cputime(t)

Martin


--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_www: http://www.informatik.uni-bremen.de/~malb
_jab: martinr...@jabber.ccc.de

Simon King

unread,
Nov 7, 2007, 10:17:15 AM11/7/07
to sage-support
Dear Martin,

> Actually, for Singular it is trivial:
>
> sage: R=singular.ring(0,'(x(1..10))','dp')
> sage: t= singular.cputime()
> sage: singular.eval('ideal G = maxideal(14)')
> sage: singular.cputime(t)

This is indeed non-trivial! Even when i compute maxideal(19), which
takes a couple of seconds, singular.cputime(t) only returns 0.001. I
doubt that this is the correct time.

Yours
Simon

mabshoff

unread,
Nov 7, 2007, 10:22:51 AM11/7/07
to sage-support

On Nov 7, 4:17 pm, Simon King <k...@mathematik.uni-jena.de> wrote:
> Dear Martin,
>

Hello Simon,

If you can reproduce this with a "stock" Singular somebody ought to
report this back to Hannes.

> Yours
> Simon

Cheers,

Michael

William Stein

unread,
Nov 7, 2007, 11:06:29 AM11/7/07
to sage-s...@googlegroups.com
On Nov 7, 2007 7:22 AM, mabshoff

Just for the record, I do *not* see the problem / discrepeancy that Simon
King is observing:

was@linux:~$ sage
----------------------------------------------------------------------
| SAGE Version 2.8.12, Release Date: 2007-11-06 |


| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------

sage: R=singular.ring(0,'(x(1..10))','dp')
sage: t= singular.cputime()
sage: time singular.eval('ideal G = maxideal(14)')
CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s
Wall time: 0.29
''
sage: singular.cputime(t)
0.28999999999999998

William Stein

unread,
Nov 7, 2007, 11:08:17 AM11/7/07
to sage-s...@googlegroups.com
On Nov 7, 2007 4:34 AM, John Cremona <john.c...@gmail.com> wrote:
> It is true that the cpu time does not include any of the child
> processes, and also that in many cases most of the computation is done
> by those.
>
> In this case the cardinality is either computed via a call to the
> libpari function ellap, or by running gp and calling the sea
> implementation there. The crossover is at 10^18 (as you can see by
> typing E.cardinality??) so your example is using sea via gp.
>
> Many people agree with you that it would be more useful to have the
> aggregate time.

So do I. If anybody figures out how to compute this aggregate time in a way
that doesn't itself significantly impact the performance of Sage, I'd love to
add this feature to the output of "time". So far, nobody has figured out how
to do this and explained it to any of us. Here "this" is basically
"figuring out
the total CPU time used by a group of unix processes."

William

mabshoff

unread,
Nov 7, 2007, 11:16:51 AM11/7/07
to sage-support

On Nov 7, 5:08 pm, "William Stein" <wst...@gmail.com> wrote:

Hello,

Some info on this:

sage: time?
Type: Magic function
Base Class: <type 'instancemethod'>
String Form: <bound method InteractiveShell.magic_time of
<IPython.iplib.InteractiveShell object at 0x2afc0e987550>>
Namespace: IPython internal
File: /home/was/s/local/lib/python2.5/site-packages/IPython/
Magic.py
Definition: time(self, parameter_s='')
Docstring:
Time execution of a Python statement or expression.

The CPU and wall clock times are printed, and the value of
the
expression (if any) is returned. Note that under Win32,
system time
is always reported as 0, since it can not be measured.

This function provides very basic timing functionality.
In Python
2.3, the timeit module offers more control and
sophistication, so this
could be rewritten to use it (patches welcome).


but man getrusage tells us:

getrusage() returns current resource usages, for a who of
either RUSAGE_SELF or RUSAGE_CHILDREN. The
former asks for resources used by the current process, the
latter for resources used by those of its
children that have terminated and have been waited for.

So I assume that we can either use "timeit" or patch getrusage in
python to add up the resources used by the children on top of self. I
didn't actually look at the code, so this is shooting from the hip :)

> William

Cheers,

Michael

Simon King

unread,
Nov 7, 2007, 11:29:13 AM11/7/07
to sage-support
Dear Michael,

On Nov 7, 4:22 pm, mabshoff <Michael.Absh...@fsmath.mathematik.uni-
dortmund.de> wrote:
<snip>


> > This is indeed non-trivial! Even when i compute maxideal(19), which
> > takes a couple of seconds, singular.cputime(t) only returns 0.001. I
> > doubt that this is the correct time.
>
> If you can reproduce this with a "stock" Singular somebody ought to
> report this back to Hannes.

This reminds me something.

Recently i was building Singular from the sources. It kind of worked,
but the timer was spoiled. Only rtimer did what it was supposed to.
Hannes couldn't tell me what i did wrong. The timer of the downloaded
Singular binary works, but the timer of "my own" Singular doesn't.
Strange.

I suspect that the timer problem of my Sage/Singular has the same
source. By the way, i just checked that the timer of Sage/Singular on
another machine (built by a colleague of mine) doesn't work either.

Two questions:
1) Any idea why the Singular timer doesn't work when i build it? I
mean, what piece of software involved in building Singular is
responsible for the timer?
2) Would it work to replace the Sage-Singular by a softlink to the
downloaded Singular binary (with timer)?

Yours
Simon

John Cremona

unread,
Nov 7, 2007, 11:33:59 AM11/7/07
to sage-s...@googlegroups.com
Isn't there a problem with this:

"the latter for resources used by those of its
children that have terminated and have been waited for."

We want to add up the time used by child processes *which are still
running*. For example, if sage needs to use maxima (say) it checks to
see if maxima is already running and starts it if not. Then it sends
input to maxima and reads the output, as many times as necessary. The
child maxima process will not end until the sage process itself ends.

I'm sure we do not want to fire up a fresh maxima every time maxima is
needed (and make it quit each time) because of overheads. SImilarly
with all the other subsidiary programs used by Sage.

Hence this is not a system issue of finding out how much time other
processes have taken in all. To use system calls we would need the
system to tell us how much cpu time another process has used since we
last asked -- perhaps this would be possible if there is a system call
to ask a running process how much time it has used so far. I guess
that is possible (at least on unix) since that gets reported e.g. by
the ps function. Assuming that, Sage would need to keep a little list
with an entry for each subsidiary program like maxima storing how much
time that process has used so far, and at appropriate times update it.

Otherwise we would be at the mercy of the subsid. programs themselves
telling how much time they have used -- which I'm sure is not provided
by all (and is likely to be untrustworthy by some, also).

John


On 07/11/2007, mabshoff


--
John Cremona

mabshoff

unread,
Nov 7, 2007, 11:37:46 AM11/7/07
to sage-support

On Nov 7, 5:29 pm, Simon King <k...@mathematik.uni-jena.de> wrote:
> Dear Michael,
>
> On Nov 7, 4:22 pm, mabshoff <Michael.Absh...@fsmath.mathematik.uni-dortmund.de> wrote:

Hi Simon,

>
> <snip>
>
> > > This is indeed non-trivial! Even when i compute maxideal(19), which
> > > takes a couple of seconds, singular.cputime(t) only returns 0.001. I
> > > doubt that this is the correct time.
>
> > If you can reproduce this with a "stock" Singular somebody ought to
> > report this back to Hannes.
>
> This reminds me something.
>
> Recently i was building Singular from the sources. It kind of worked,
> but the timer was spoiled. Only rtimer did what it was supposed to.
> Hannes couldn't tell me what i did wrong. The timer of the downloaded
> Singular binary works, but the timer of "my own" Singular doesn't.
> Strange.
>
> I suspect that the timer problem of my Sage/Singular has the same
> source. By the way, i just checked that the timer of Sage/Singular on
> another machine (built by a colleague of mine) doesn't work either.
>
> Two questions:
> 1) Any idea why the Singular timer doesn't work when i build it? I
> mean, what piece of software involved in building Singular is
> responsible for the timer?

I would assume that they use getrusage, but I haven't checked.

> 2) Would it work to replace the Sage-Singular by a softlink to the
> downloaded Singular binary (with timer)?
>

It should work and has been done so by several people in the past,
i.e. on Solaris. I guess you can either modify the Singular script to
point to your own Singular or copy over the binary to Singular-3.0.3.

> Yours
> Simon

Cheers,

Michael

mabshoff

unread,
Nov 7, 2007, 11:47:26 AM11/7/07
to sage-support

On Nov 7, 5:33 pm, "John Cremona" <john.crem...@gmail.com> wrote:

Hello John,

> Isn't there a problem with this:
>
> "the latter for resources used by those of its
> children that have terminated and have been waited for."

Yep, that is indeed a problem.

>
> We want to add up the time used by child processes *which are still
> running*. For example, if sage needs to use maxima (say) it checks to
> see if maxima is already running and starts it if not. Then it sends
> input to maxima and reads the output, as many times as necessary. The
> child maxima process will not end until the sage process itself ends.
>
> I'm sure we do not want to fire up a fresh maxima every time maxima is
> needed (and make it quit each time) because of overheads. SImilarly
> with all the other subsidiary programs used by Sage.

You are 100% right.

>
> Hence this is not a system issue of finding out how much time other
> processes have taken in all. To use system calls we would need the
> system to tell us how much cpu time another process has used since we
> last asked -- perhaps this would be possible if there is a system call
> to ask a running process how much time it has used so far. I guess
> that is possible (at least on unix) since that gets reported e.g. by
> the ps function. Assuming that, Sage would need to keep a little list
> with an entry for each subsidiary program like maxima storing how much
> time that process has used so far, and at appropriate times update it.
>
> Otherwise we would be at the mercy of the subsid. programs themselves
> telling how much time they have used -- which I'm sure is not provided
> by all (and is likely to be untrustworthy by some, also).

Mhhh. maybe someone should go out and search if there isn't some
python module already which can do that before we start reinventing
the wheel. It sounds like something somebody else would have already
implemented :)

>
> John

<SNIP>

Cheers,

Michael

Reply all
Reply to author
Forward
0 new messages