Re: compiling crashes, compiling and loading slowness

--===============3943994316529484225==
Content-Type: multipart/alternative; boundary="0000000000001b7056064f72a5cd"

--0000000000001b7056064f72a5cd
Content-Type: text/plain; charset="UTF-8"

Further analysis suggests that symbol-hash will be fine for the
function-name and slot-name tables. The equivalence predicate wants to be
EQ for names which are symbols, but robinhood hashsets don't have a way to
hash symbols by their address while not messing up if GC moves them. That's
why I naturally thought of an EQUAL table which will properly deal with
SETF names as well as hash symbols by EQ. I think the correct fix will
indeed be a custom mixer but we don't need to involve the package.  Using
this quick test:

(let ((dummies (loop repeat 5000 collect (make-symbol "BLAH")))
      (alist))
  (dolist (sym dummies)
    (let* ((h (sb-kernel:symbol-hash sym))
           (cell (assoc h alist)))
      (if cell
          (incf (cdr cell))
          (push (cons h 1) alist))))
  (sort alist #'> :key #'cdr))

the worst number of colliding symbols was 15.  Even doubling the 5000 to
10000 saw no more than 18 collisions, and using up to 50,000 saw at worst
70 collisions. I then asked how many spelled-the-same symbols I would need
for the robinhood hashset to screw up (using that same quick-and-dirty loop
above), and the answer was over 200,000 symbols.
Or teach robinhood hashsets to use EQ hash and also rehash after key
movement, but I don't really like that as much as just mixing better

--0000000000001b7056064f72a5cd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Further analysis suggests that symbol-hash will be fine fo=
r the function-name and slot-name tables. The equivalence predicate wants t=
o be EQ for names which are symbols, but robinhood hashsets don&#39;t have =
a way to hash symbols by their address while not messing up if GC moves the=
m. That&#39;s why I naturally thought of an EQUAL table which will properly=
 deal with SETF names as well as hash symbols by EQ. I=C2=A0think the corre=
ct fix will indeed be a custom mixer but we don&#39;t need to involve the p=
ackage.=C2=A0 Using this quick test:<div><br><div><font face=3D"monospace">=
(let ((dummies (loop repeat 5000 collect (make-symbol &quot;BLAH&quot;)))<b=
r>=C2=A0 =C2=A0 =C2=A0 (alist))<br>=C2=A0 (dolist (sym dummies)<br>=C2=A0 =
=C2=A0 (let* ((h (sb-kernel:symbol-hash sym))<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0(cell (assoc h alist)))<br>=C2=A0 =C2=A0 =C2=A0 (if cell<b=
r>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (incf (cdr cell))<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 (push (cons h 1) alist))))<br>=C2=A0 (sort alist #&#39;&g=
t; :key #&#39;cdr))<br></font></div></div><div><br></div><div>the worst num=
ber of colliding symbols was 15.=C2=A0 Even doubling the 5000 to 10000 saw =
no more than 18 collisions, and using up to 50,000 saw at worst 70 collisio=
ns. I then asked how many spelled-the-same symbols I would need for the rob=
inhood hashset to screw up (using that same quick-and-dirty loop above), an=
d the answer was over 200,000 symbols.</div><div>Or teach robinhood hashset=
s to use EQ hash and also rehash after key movement, but I don&#39;t really=
 like that as much as just mixing better=C2=A0</div></div>

--0000000000001b7056064f72a5cd--


--===============3943994316529484225==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============3943994316529484225==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Sbcl-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-help

--===============3943994316529484225==--