freenode/#sicl - IRC Chatlog
Search
14:37:50
jcowan
The most common use case, however, is when the invariant of type-specialized code has been violated.
14:38:00
beach
I'm lost. Are you saying that when the programmer detects a problem, suddenly, the compiler will change the behavior of the program?
14:39:13
jcowan
No, only its representation. Suppose that a debugger offers a command to proceed execution until the current function has returned. If the current function is inlined, a naive implementation will give the wrong behavior.
14:39:48
jcowan
(This often comes up when stepping through code; you realize that you have stepped into a call instead of over it.)
14:42:18
beach
I am hoping to make SICL less naive than that, but I don't know how hard that would be.
14:48:15
jcowan
The other main deoptimization case is around type assumptions. A compiler might assume that (+ i j) is fixnum addition and compile it as two inline type checks and an inline fixnum add operation. If the type checks fail, a reasonable thing to do is to recompile the containing function to always call generic #'+.
14:48:58
beach
Yes, but, again, that is not something that the programmer would be aware of, so it is not a debugging situation.
14:50:09
jcowan
However, if a breakpoint/tracepoint is set on calls to +, then such inlines should be deoptimized so that #'+ is actually being called.
14:53:34
jcowan
In any case, constructive inlining is much simpler to provide: if the function cell is changed, then all compiled code which calls that function directly (not by funcall-on-symbol) simply needs to be patched up to call the new function object, not recompiled from expanded source altogether. It's a slam-dunk optimization imo.
14:57:18
jcowan
I think this is particularly helpful in SICL where access to the function cell requires indirection through the global environment. The less of that, the better.
14:58:06
beach
The environment is only involved at load time. After that, the cell is in a variable in the native code.
15:03:11
beach
That was a major problem I had to solve before suggesting first-class global environments. All other proposals I have seen (mostly from Scheme) take a huge performance hit for every function call.
15:37:13
jcowan
Scheme doesn't allow you to portably create a new mutable environment at run time. In any case, runtime access to environments is available only through eval and load (the default being the REPL's environment, which is mutable).
15:37:25
Shinmera
I know I talked about lock-free hash-tables in here before. Today I finally got back to working on that, and I'm having good success so far! https://twitter.com/Shinmera/status/1087735482879037442
15:39:49
beach
jcowan: Right, I was talking about extensions to Scheme. Like this one: https://dl.acm.org/citation.cfm?id=232653&dl=ACM&coll=DL
15:41:53
Shinmera
His approach to writing concurrent algorithms in state-machine form is pretty nice
15:43:15
Shinmera
The published code is also nicely commented, which is a rarity for publications :)
15:53:42
jcowan
In some sciences were are now at the point where the "paper" is an extended abstract, and the real paper is in the "supplementary electronic materials".
17:42:05
jcowan
I have read the Queinnec paper with some pain. However, it is a mixture of concerns from my point of view: I am (and I think you are) only interested in first-class global environments, whereas Q's environments also include the local (lexical) environment.
17:42:49
jcowan
(There are people in the Scheme community who claim that the inability of Scheme's eval to access the lexical environment of its call was a grave error, but they aren't much listened to.)
17:44:39
Bike
kind of a different question from whether it should be possible to access lexical environments in some fashion, though
18:28:13
jcowan
in pre-Scheme, pre-CL days when all variabvles were dynamically scoped, eval had access to local as well as global variables automatically.
19:40:24
Bike
so i got through a lot of the rewrite but just remembered that we do need to generate ASTs from things that aren't functions, so there will be no dynamic environment argument available. not sure how to represent that.
19:58:16
Bike
that is, if i cst-to-ast '(foo 4), i need something in the dynamic-environment input for that call
22:54:57
Bike
other than that everything seems to be working. block and tagbody unwind hir looks sane. having catch have multiple successors for tagbody really cleans things up, both in ast-to-hir code and the graphs themselves
22:55:18
Bike
tomorrow i'll hook it up in clasp in order to remove my illusion that everything seems to be working
22:55:32
Bike
i have it pushed as the dynamic-environment branch if anyone wants to take a look. or i will in a minute anyway.