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
<[EMAIL PROTECTED]> wrote:
>
>
>
> On Nov 7, 5:08 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> > On Nov 7, 2007 4:34 AM, John Cremona <[EMAIL PROTECTED]> 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."
> >
>
> 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
>
>
> >
>


-- 
John Cremona

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sage-support
URLs: http://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/
-~----------~----~----~----~------~----~------~--~---

Reply via email to