freenode/#sicl - IRC Chatlog
Search
4:04:59
beach
ebrasca: You shadow the symbol, and then if you need to refer to the CL symbol in your package, you use the CL: prefix.
5:50:08
no-defun-allowed
I was going to say that I had succeeded in porting Kulukundis's hash table, then I ran the tests and found I have a #<SICL-LINEAR-PROBING-HASH-TABLE:LINEAR-PROBING-HASH-TABLE :test EQL size -1/64 {100E29E5A3}>.
5:53:09
jackdaniel
now you could advertise sicl as the only implementation with negative consing - imagine the possibilities
5:54:46
no-defun-allowed
Just checked, Haskell already has snoc which appears to negative cons already. So I will probably have to fix that, as we aren't first to invent that, and we'll look like weirdo Haskell users.
6:03:00
no-defun-allowed
Okay, now it works. I had accidentally broken the metadata scanning functions. However, the REHASHING tests provided are not necessarily testing the specification; the HyperSpec states "the actual amount by which the hash-table will grow upon rehash is implementation-dependent." and that :rehash-size is just "advice".
6:12:45
no-defun-allowed
In the case of this design, hash table sizes have to be powers of 2 and larger than one group, and resizing must always multiply the size by another (positive) power of 2 to preserve the size invariants.
6:36:42
beach
So I guess my next task is MIR-to-LIR, aside from the FIXMEs in HIR-to-MIR. The current MIR-to-LIR is very error prone because I essentially put every operand in a register before issuing the operation, and then store the resulting register on the stack.
6:36:43
beach
There is no guarantee that I am not using the same register for more than one thing at the same time. So perhaps this is a good tie to start working on register allocation.
6:39:41
no-defun-allowed
I found GETHASH is currently 30% or so faster on linear-probing hash tables than bucket hash tables, but only up to a certain size. When it is larger than that size, the linear-probing hash table becomes much slower, and I'm not immediately sure why.
6:42:35
no-defun-allowed
I hope it's not intrinsic; the graphs in the Cppcon presentation didn't show the original table becoming much slower with larger tables.
7:20:24
no-defun-allowed
I ran the benchmark with smaller increments in hash table counts (using the E6 series instead of powers of 10), and there appears to be a sawtooth pattern on a plot of GETHASH time versus hash table count.
7:28:51
no-defun-allowed
My first guess is that it has to do with when we decide to resize, if it is periodic. Also, the graph looks like <https://applied-langua.ge/~hayley/gethash-versus-count.png>
7:30:32
beach
The purpose of a hash table is to have relatively constant access time, independent of the size.