Re: TRY/CATCH is unnecessarily slow on OS X

["Lorenz Minder" <lminder@gmx.net>]

Hi,

Bill Allombert wrote:
> On Wed, Sep 09, 2009 at 06:01:19AM +0200, Lorenz Minder wrote:
> > I guess the question now is:  Given that TRY/CATCH is meant only for
> > internal use, and that a different error handling mechanism is under way,
> > do you think the number of uses of those macros in libpari warrant a patch
> > that uses _setjmp() when possible?
> 
> There is still the issue that PARI should behave in the same way
> on all system. Imagine the user change the signal blocked set asynchronously
> during TRY/CATCH and their changes get reverted on some system and not others...
> (and it depends on the race condition...)

Right.

> Looking at your patch it seems that:
> 1) you are doing getrusage(RUSAGE_SELF,...) instead of getrusage(0,...)
> Your code seems more correct, I do not know why PARI does getrusage(0,...)
> 2) You add the system time to the user time. This would change PARI behaviour.
> 3) You are initializing T before calling TIMER() in TIMERstart.
> That should not be necessary, because the return value of TIMER()
> is discarded, but this is probably cleaner this way.

To clarify, I sent this patch because it would be a bit fishy to send
timing results with a changed timer, but remain blurry on the exact
changes to the timer.  The goal was not primarily to have it merged.

I don't know if this patch should be applied or not.  I think it's
relatively clear that sys+user time is the quantity you actually care
for, not just user time, but doubt that changing this now is a good
idea:  You would no longer be able to compare the benchmark numbers with
previous releases.

To your points 3):  I put this there first and foremost because it makes
debugging easier.  (For one thing, you won't have to wonder about
spurious negative delays in TIMER...)  It's also a bug, though:  In C,
the use of uninitialized memory causes undefined behavior, even if it's
just used to compute something that is thrown away anyways.  It's a
minor problem, but I think this should be fixed.

> So I do not see how this avoid the negative timing.

That's a result of how the time estimates are computed in NetBSD.  The
system has an accurate timing of total (sys+user) time, but only a
relatively rough estimate of the relative contributions of system and
user time to that total time.  These proportions, together with the
total time, are used to calculate system and user time.  If the estimate
of the proportions changes a lot in little time, you'll see one of the
estimates (system or user time) going backwards.

In contrast, the estimate of the total time usage always increases
monotonically, and is much more precise than either the system or user
time individually.

Best,
--Lorenz
-- 
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02