Better pointer hash #5
Labels
Comments
Closed
|
Two questions:
If the answer to the first two questions is "no", and the answer to the third is "yes", it is possible to use a very simple "universal hash" that (provably!) solves the problem. |
akopytov
pushed a commit
to akopytov/LuaJIT
that referenced
this issue
Oct 15, 2016
Aarch64 v2.1 new
gut
pushed a commit
to PPC64/LuaJIT
that referenced
this issue
Aug 30, 2017
Removed the complicated handling of lj_vm_ffi_call (it was a variable size frame) and now backtrace works all over (e.g:) #0 0x00003fffb7d4875c in __libc_send (fd=32, buf=0x3fffb09a0028, len=8192, flags=0) at ../sysdeps/unix/sysv/linux/send.c:31 #1 0x00003fffb7bea214 in socket_send (ps=0x3fffb7bc7778, data=0x3fffb09a0028 'A' <repeats 200 times>..., count=8192, sent=0x3fffffffee60, tm=0x3fffb7bc97d8) at usocket.c:205 #2 0x00003fffb7be4ef8 in sendraw (buf=0x3fffb7bc77a0, data=0x3fffb09a0028 'A' <repeats 200 times>..., count=52428800, sent=0x3fffffffeee8) at buffer.c:176 #3 0x00003fffb7be4960 in buffer_meth_send (L=0x3fffb7f6d280, buf=0x3fffb7bc77a0) at buffer.c:87 LuaJIT#4 0x00003fffb7bec3f4 in meth_send (L=0x3fffb7f6d280) at tcp.c:130 LuaJIT#5 0x0000000010042d44 in lj_BC_FUNCC () LuaJIT#6 0x0000000010043f24 in lj_ff_coroutine_resume () LuaJIT#7 0x000000001001d7d4 in lua_pcall (L=0x3fffb7f60378, nargs=0, nresults=-1, errfunc=2) at lj_api.c:1129 LuaJIT#8 0x00000000100045e8 in docall (L=0x3fffb7f60378, narg=0, clear=0) at luajit.c:121 LuaJIT#9 0x00000000100053ec in handle_script (L=0x3fffb7f60378, argx=0x3ffffffffa40) at luajit.c:291 LuaJIT#10 0x0000000010006600 in pmain (L=0x3fffb7f60378) at luajit.c:551 LuaJIT#11 0x0000000010042d44 in lj_BC_FUNCC () LuaJIT#12 0x000000001001da40 in lua_cpcall (L=0x3fffb7f60378, func=0x10006334 <pmain>, ud=0x0) at lj_api.c:1153 LuaJIT#13 0x00000000100067a4 in main (argc=2, argv=0x3ffffffffa38) at luajit.c:580
Closed
|
While on a tangential investigation: CRC32 is available on many x86/x64 and ARM/ARM64 CPUs nowadays. The latency isn't too bad (3 cycles). But at least for pointers the hash quality is lower than the current ARX pointer hash. I tried quite a few variations. This is a surprising result and I have no good explanation. |
Closed
|
Real-world code doesn't use it that much. The hash is 'good enough' for the remaining cases. |
vittorioromeo
pushed a commit
to vittorioromeo/LuaJIT
that referenced
this issue
Feb 4, 2024
Repo Sync
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The pointer hash leaves something to be desired. However the constraints on acceptable hash functions are very strict. Not just for performance, but also for instruction space, since this is inlined in lots of places, including JIT-compiled code.
Changing the pointer hash affects: performance (hah!), inlined hash constants in C switch statements, all JIT backends.
There have been previous discussions on the mailing list with (so-so) benchmarks. TODO: gather all links.
The text was updated successfully, but these errors were encountered: