libera/#sbcl - IRC Chatlog
Search
15:16:52
phao
Hi. Is there a guide on efficient numerical computation (floating point stuff, openmp, mpi, stuff like that I guess) with sbcl?
17:53:23
stassats
got a proof of concept for proper callbacks https://gist.github.com/stassats/9c6debdde5f7370ba2b0c7974002f347
17:56:47
stassats
two things to figure out: where to stash it so that it doesn't move and how to fixup the thread tls id
19:05:08
stassats
simply returning is just 5x faster than calling the old callback, i guess 4x is as good as it gets
19:16:30
stassats
wonder if there can be some non-lisp mode of operations, not registering as a lisp thread, respecting the C calling conventions
19:17:20
stassats
so you could have a non-lisp thread talking to C and not being stopped by the GC, but, naturally, it can't touch any movable lisp memory
20:17:49
karlosz
stassats: real callbacks sound really great, especially now that there's a documented interface for them
20:17:49
Colleen
karlosz: Bike said 7 hours, 48 minutes ago: i've been thinking of it as a reverse of type inference in the sense that there can be both a simple data-dependent analysis like meta evaluate, and then a more involved control flow dependent analysis like constraint propagation
20:17:49
Colleen
karlosz: Bike said 7 hours, 47 minutes ago: and it seems to me that constraint prop might be overkill, since in the reverse case we only need it when there's more than one definition for a thing, which is rarer than having more than once use (which is why constraint prop for types is useful)
20:17:49
Colleen
karlosz: Bike said 7 hours, 46 minutes ago: it's true a reverse analysis could be a different thing from meta-evaluate, though. it's just dual or whatever, and simple enough that i thought interleaving them might make snese
20:19:58
karlosz
what are you thinking for making the xeps (or whatever indirection mechanism) not move?
20:42:14
karlosz
so there's two options: allocating the 16 bytes trampoline (jmp and all) in static space, or just allocating the addresses in static space which get fixed up like anything else
20:45:28
karlosz
well, the original linkage mechanism for the runtime to call out to lisp is basically keeping static fdefns around
21:23:00
karlosz
stassats: would just pinning the call stack work? what if the c function does something funky like store the callback routine address in a global variable
21:27:37
karlosz
the original way the runtime uses (static fdefns), funcall1, funcall2, funcall3..., call_into_lisp, and ldb
21:31:06
karlosz
oh, here's another reason we'll want trampolines in general that i don't see being able to do with pinning xeps and using the address directly - gc'ing the code and invalidating the callback
21:32:54
karlosz
right, but say you have C code that stores that callback address into a global variable
21:35:14
karlosz
we could make calling into lisp a bit nicer too; not just from user code but also within our own runtime
21:37:17
karlosz
this is pretty exciting; we might be able to get rid of call_into_lisp all together
21:48:32
stassats
https://gist.github.com/stassats/9c6debdde5f7370ba2b0c7974002f347#file-callback-lisp-L19
21:56:16
karlosz
so the plan is to load thread-tn from the c tls area, and the XEP needs to know where the tls area is somehow
22:00:09
karlosz
you would be able to just do (loadw thread-tn tp-tn (make-tls-fixup "thread_local...."))
22:01:55
stassats
according to go https://github.com/golang/go/blob/master/src/runtime/tls_arm64.s#L22
22:09:25
stassats
how just changing current_thread to be thread-local and making call_into_lisp use it can break something
22:10:24
stassats
with Unrecognized trap instruction 54000103 in sigtrap_handler() (PC: 0x18080f1e4)
22:11:04
stassats
although it says Received signal 5 @ 180895160 in non-lisp pthread 0x16b967000, resignaling to a lisp thread.
22:45:53
stassats
a fault in get_sb_vm_thread is hard to debug, because the fault handler calls get_sb_vm_thread
23:06:30
stassats
also getting crashed on child side of fork pre-exec BUG IN CLIENT OF LIBPLATFORM: Trying to recursively lock an os_unfair_lock