freenode/#sbcl - IRC Chatlog
Search
18:28:02
Xach
hmm, is http://report.quicklisp.org/2020-05-30/failure-report/sel.html#software-evolution-library_run-rest-server due to sbcl changes?
19:43:34
Krystof
35: ((:METHOD FINALIZE-INHERITANCE :AFTER (T)) #<STANDARD-CLASS SOFTWARE-EVOLUTION-LIBRARY/SOFTWARE/LISP:READER-QUOTE>)
20:17:28
Krystof
(I can't even work out how to trigger the layout-invalid case in %ensure-both-classoids-valid any more)
20:21:44
ajb`
I use SBCL at work and write a lot of code that is performance sensitive and I get a bit bored inserting declarations and fighting with SBCL. So, for the last couple months (weekends only, so it's slow) I've been experimenting with the type inferencing / constraint propagation part of SBCL. I figured it might be worth asking if anyone has any pointers here or if anyone is currently working on this?
20:21:57
ajb`
What PK wrote here https://pvk.ca/Blog/2013/11/22/the-weaknesses-of-sbcls-type-propagation/ seems still true, though I will admit it took me a long time to understand it. As this is my first time working on SBCL, and anything compiler related since school, there's a bit of a learning curve --- which has been fun! I've read http://home.pipeline.com/~hbaker1/TInference.html which helped give a perhaps overly optimistic perspective.
20:29:37
Krystof
Xach: is there a way for me to grep for who in quicklisp defines finalize-inheritance :after (t)?
20:49:56
pfdietz
I had already been looking at that finalize-inheritance problem in sel. Not a good idea.
20:58:58
Krystof
mind you, it looks like software-evolution-library is trying to use this intentionally
21:01:39
pfdietz
Oh yes, my fingers are all over that code. But Eric did the finalize-inheritance part.
21:02:17
pkhuong
ajb`: if you want to speed up your experimentation cycle on constraint propagation, I think your best bet is to invest in some way to serialise the input and output of the constraint propagation pass.
21:03:08
pkhuong
that'll let you move the most of the code out of process, and make it easier to generate regression tests.
21:06:23
pkhuong
I believe stassats and karlosz have been working on optimising the representation, they might have some context on the code base. I found a big problem was that a lot of code doesn't really benefit from constraint propagation at all, and the rest tends to only need a small subset of the cleverness one might come up with.
21:08:13
pkhuong
optimisation literature tends to focus on SSA; that would be a heavy lift in SBCL, and it's not obviously easy to "just" convert to / from SSA before constraint propagation (since that feeds into IR1 transforms which will mangle the flow graph). I think a better avenue might be to look at abstract interpretation for ideas.
21:23:30
pfdietz
I have to go eat, but I was experience problems with exactly that this week. We should talk.
21:40:23
ajb`
pkhoung: Thanks! I haven't found too many problems with just modifying the constraint propagation phase in a running image (yes it's annoying when I screw it up and it explodes)... but, yes, it would be nice to have a set of test instances to operate on (currently done manually for some basic loops that fail type inferencing currently). What do you mean by "look at abstract interpretation for ideas"?
21:41:45
pfdietz
Ok, back. What he was trying to do was use finalize-inheritance to define some methods on a class based on a value of a :class allocation slot. The problem I was having was this finalization was being invoked inside the compiler, so methods were being redefined there, which I think caused problems.
21:43:10
pfdietz
Anyway, I want to redo how that works because that approach seems too clever by half.
21:44:45
pfdietz
It was causing hard to reproduce failures when loading ql systems, failures that would go away on the second attempt to load things.
22:06:03
Krystof
right, defining methods on finalize-inheritance that aren't to do with actually finalizing inheritance is incredibly dubious
22:07:18
Krystof
I can patch over this specific instance in sel, but there's so much else that can potentially go wrong: any time the compiler needs to do a subtypep on your class, you could end up with a finalize-inheritance call, and running arbitrary user code inside the compiler's context is error-prone
22:12:18
Krystof
(maybe calling arbitrary code from the compiler's context shouldn't be error-prone; maybe the compiler should be fully re-entrant)
22:22:48
Krystof
well that one ought to be fixable by something similar: somewhere where we know we're doing our own macroexpansion, bind *macroexpand-hook* locally
22:26:15
Krystof
at the very least, when we get to the metacircle (when we notice that we are calling user-gf while trying to construct the effective method for user-gf) we could break it by binding *macroexpand-hook* to nil at that point