Hi,
The PARI TRY/CATCH exception handling is currently very slow on
Mac OS X (and probably *BSD, although I haven't checked that). I don't
know if Linux is affected but quite possibly not.
How slow is it? Agonizingly slow. The attached "except.cc" computes
"gsqrt(2)" repeatedly, once with each call wrapped into a CATCH/TRY
block and once without the wrapping. With error checking, it's slower
by an order of magnitude:
pari_perform$ time ./except n # No error checking.
real 0m0.700s
user 0m0.694s
sys 0m0.005s
pari_perform$ time ./except p # W/ PARI exception handling.
real 0m8.466s
user 0m5.799s
sys 0m2.660s
Some would probably argue that not every tiny call must be wrapped into
a CATCH/TRY-block, but the fact is that doing this is sometimes
necessary, e.g., for wrapper libraries, or if you cannot or don't want
to reuse the PARI error handling mechanisms in your C program.
Why is it so slow? The problem is that the Mac OS X version of
setjmp/longjmp saves and restores the signal mask, which appears to take
an insane amount of time. Assuming that this is not necessary (if it
is, I think you have a bug on SysV), it is better to use a variant of
setjmp/longjmp that does not do this. Use _setjmp/_longjmp or possibly
sigsetjmp(,0)/siglongjmp() instead.
The attached patch does this as a proof of concept, and with it applied,
I get much better behaviour:
pari_perform$ time ./except n
real 0m0.700s
user 0m0.695s
sys 0m0.004s
pari_perform$ time ./except p
real 0m0.810s
user 0m0.804s
sys 0m0.005s
This patch breaks systems that do not have _setjmp(), so you probably
have to test for its existence in Configure.
Best,
--Lorenz
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser