freenode/#sicl - IRC Chatlog
Search
10:44:12
no-defun-allowed
I could pick any of the bits, sure. But it's not a problem with the SICL hash functions.
10:49:41
no-defun-allowed
The problem is that the identity function is not a good hash function for ranges of integers with this table, which Kulukundis mentions in his presentation.
10:50:30
beach
I must conclude that the SICL hash function for integers is not the identity function, yes?
10:50:56
no-defun-allowed
However, he says it's only a problem when the low eight bits are the same (like (loop for n below X collect (ash n 10))), when there would still be collisions for (loop for n below X collect n).
10:52:32
no-defun-allowed
After fixing everything, my table is somehow 400 picoseconds faster (on average of a lot of samples and sizes) at reading the cache than the table in SBCL.
11:01:38
no-defun-allowed
Yes, also that the difference is pretty close to one cycle. Is that even significant? It could be the other way around on another machine.
11:22:49
no-defun-allowed
Still, caching like that could get messy in a concurrent hash table, so faster probing would be more significant.
11:55:49
no-defun-allowed
On the other hand, there is a lot of improvement to be made with inserting mappings. Maybe I should just include the SICL hash functions in my "standalone" implementation, since the table is picky about hash functions.
21:22:56
alandipert
pushed a JACL project update that suggests possible future overlap with SICL via ECL https://gist.github.com/alandipert/a79a345f1b4c822c4d8ddaf992a5fc30