Raymond Toy <toy.raymond at gmail.com> writes:
> Rupert> I reverted the commit at the time, but thought I'd spend
> Rupert> some time this morning trying to work out what had
> Rupert> happened. As such, I was (pleasantly?) surprised to see
> Rupert> Dan Gildea's commit 6951fd reverting my reversion.
>
> Actually, I think I mentioned it, but your revert didn't seem to make
> a difference. Dan's did, because he changed the new handler-case
> stuff back to catch/throw.
Ah, that makes sense. Sorry, I was a little preoccupied at the time.
> It turns out that cmucl on x86 (but not sparc or ppc) has a
> particularly bad implementation that causes cmucl to search the entire
> heap to find the a handler.
>
> Also, while looking into this, I noticed the use of catch/throw in
> pnthrootp is useless. cnthroot is only called from pnthrootp, and
> pnthrootp always catches anything that cnthroot would throw. Hence we
> can greatly simply this by having cnthroot just return nil. I made
> this change on the original handler-case version and the time for
> rtest15 went down from a couple of hundred seconds to tens of seconds.
>
> I also looked at some disassembly. The code for handler-case and error
> is signficantly larger than catch/throw. If these are important, it
> might really be good to continue to use catch/throw. I found that one
> of the integrals in rtest15 calls rat-error tens of thousands of
> times!
Wow!
I was thinking about what to do on the train today (sans Laptop because
also carrying a violin :-( ), and it occurred to me that the
ignore-rat-error macro together with the rat-error function that I
hacked together can be made to work perfectly well with catch/throw, and
the whole thing will be completely safe if I stick a catch block in
toplevel-macsyma-eval or somewhere similar.
So I'll try that and check that performance is as expected. Since we
don't depend on particular versions of lisp implementations, we can't
really assume a cmucl with this particular performance wart fixed for
several years, I guess, so I'll make the changes work without using
conditions.
Thank you very much for the detailed write-up.
Rupert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: <http://www.math.utexas.edu/pipermail/maxima/attachments/20131116/bd26a525/attachment.pgp>