freenode/#clasp - IRC Chatlog
Search
21:25:50
Bike
i guess for a start i could od it the stupid way of defining intrinsics to call that return the value of setjmp
21:33:17
karlosz
if you paste in that code somewhere and call analyze-catches from my-hir-transformations before do-inlining it should just work
21:33:42
karlosz
it should just work after do-inlining as well, but the dag can get more complicated
21:35:38
karlosz
it shouldnt matter, since i work off of the DAG, but big interactions with inlining are a bit harder to graph
21:36:29
karlosz
definitely has to happen before PCV though, because cells block proper def-use chains
21:38:36
Bike
to see if an unwind is a non-escape unwind, you just check if the destination is an escape-catch
21:39:30
Bike
anyway, that reminds me of a tangentially related issue. can copy propagation or inlining coupled with PCV result in extra reads from the closure vector? like if you have (defun mcar (x) (if (primop:typeq x cons) (primop:car x) nil)) and inline that, it looks like it does a separate read for each x
21:45:22
Bike
i only looked at a quick disassembly but it seemed like there were already two reads. maybe i should look closer though.
21:45:36
Bike
anyway, besides being inefficient this would have thread safetey problems, so we should avoid it
21:47:32
karlosz
yes. there is no general copy-prop going on at the moment before P-C-V, so you must be seeing an existing p-c-v thing
21:50:16
Bike
like if you have "read -> typeq -> read -> car", another thread could write to the sell after the typeq but before the next read
21:51:12
drmeister
kpoeck: Building with the old generated-encodings.lsp code in the docker container is taking a looooooooong time.
21:54:15
Bike
maybe you could have a binding assignment for the parameter of car, and not copy prop through it?
21:54:19
karlosz
yes, i know how to fix it. the solution is to keep the redundant assignments around and make p-c-v isolate X
21:54:36
karlosz
the copy prop in full-inlining-pass when converting binding assignments is the problem
21:55:02
frgo__
kpoeck: There's also https://sysdig.com/partners/docker/ - but I don't have experience with sysdig
21:55:22
karlosz
i made a change recently that broke that, since i wasn't thinking of that case, i'll send a PR to revert it
21:56:29
karlosz
as long as this lexical-location/binding-assignment/p-c-v stuff is thought out a bit differently
21:59:28
karlosz
but this is a problem because some lexical locations should not be subject to copy prop
21:59:55
karlosz
you're right we can just find every load value form and copy prop out from there and it should be fine though
22:02:40
karlosz
i just meant that there are obviously some useless assignments lying around and lexical locations that serve no purpose other than to copy
22:03:01
karlosz
but sometimes they are actually important, and i introduced binding assignments to make it more clear when that should be the case
22:03:12
karlosz
but the problem is there are more cases like that where it's dangerous to copy prop
22:03:27
karlosz
like how when you had assignments introduced between dynenvs from eliminate-catches
22:03:49
karlosz
it's just not obvious at all from looking at the class of the datum whether it's actually important in some way
22:04:22
karlosz
but all the different types of lexical locations get lumped together (why is dynenv a lexical location and not some other class of datum?)
22:06:13
karlosz
it doesn't know it has to do some special logic because DE2 looks like a plain lexical location
22:08:19
karlosz
things like the lexical locations introduced by binding assignments are also special
22:09:11
karlosz
that's the lambda-var/lvar distinction in sbcl - one can be closed over, the other can't
22:10:09
karlosz
it's not a real issue right now, but i think once optimizations start being used more aggressively i think treating everything as a lexical location will sort of be annoying
22:15:01
Bike
i've been thinking about things because at some point i want to introduce compiler support for CAS of lexical variables, and that will have to tie in to PCV somehow or another
22:15:52
Bike
possibly also assignments with an atomic order mark, though it'll only matter if it's closed over
22:20:45
karlosz
yeah. the thing with variables introduced by lambda is that they can become memory cells
22:22:17
karlosz
P-C-V won't distinguish between temporaries and lambda variables and just close over anything willy nilly
22:22:52
Bike
we also close over return values at the moment. it's dumb. i think that's removed in cleavir2 tho.
23:15:29
drmeister
::notify yitzi The docker image is working great. I think we can get started prototyping with this.
23:18:14
drmeister
::notify yitzi Ping me when you are online - I have some questions about portability of code from jupyter notebook to jupyter lab
23:25:40
Colleen
yitzi: drmeister said 10 minutes, 11 seconds ago: The docker image is working great. I think we can get started prototyping with this.
23:25:40
Colleen
yitzi: drmeister said 7 minutes, 26 seconds ago: Ping me when you are online - I have some questions about portability of code from jupyter notebook to jupyter lab
0:18:15
karlosz
Bike: i flamed the new ast-interpreter code here: ocf.io/~karlos/asdf-60s-new-ast-int.svg
0:21:41
karlosz
there's some consing for augment environment (maybe a list makes more sense than a hash table), but it seems like maybe it's interpreting more than it should be?
0:22:16
karlosz
i don't think it makes sense for the ast-interpreter to walk the same closure more than once, for example
0:23:36
karlosz
i find firefox is much better than chrome at actually rendering these svgs in particular
0:28:03
karlosz
well, it's not obvious to me from looking at asdf.lisp whether that's actually what is happening
0:47:04
karlosz
i've been seeing a pretty big build time regression (even since before kpoeck's changes) which i'm going to try and track down. The recent ast-interpreter changes and and generated encodings fix is saving 2 minutes, but it's still slower than it was last week
0:47:47
Bike
i made some pretty wide changes to how standard objects are allocated but i didn't see a slowdown with my commits