On Sun, May 10, 2026 at 01:06:44PM +0800, Qian Yun wrote:
> On 5/10/26 12:42 PM, Waldek Hebisch wrote:
> >
> > I do not see how Lisp EQ hash table could help us: mathematicaly
> > equal expressions may be EQ but also may be not. So if we do
> > not get hit we need to do linear search. While cache hits
> > may be faster, I would expect much more cases when we need
> > linear search (actually, it is not clear to me if we will
> > get _any_ hits).
> >
>
> The "EQ hashtable" is a little misleading: the insertion
> of new kernels is still a linear search, just like current
> situation. The comparison are done via "kerEqual", not EQ.
Well, currently in 'kernelEnterInCache' we first try binary
search. AFAICS this handles majority of calls. Only when
this fails we do linear search. Doing linear search
always is likely to slow down things. It is not clear to
me if smaller cache is enough to compensate this.
Also, there are potential traps when doing linear search
in a hash table. Namely, comparisons may insert new kernels.
Current code contains special cases so that insertion
douring search is handled correctly.
> > I interrupted 'jet.input' after 16 minutes, I do not know if it
> > was just slow and would eventually finish (normally on the same
> > machine the whole testsuite finishes after 25 seconds of real
> > time).
> >
>
> Did you do a fresh build?
Yes.
> What's your SBCL version?
Debian sbcl 2.2.9
> On my side, "make check" returns quickly with 10 failed tests,
> no hangup.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/agB6iaDYXDU6aDzW%40fricas.org.
