freenode/#sicl - IRC Chatlog
Search
13:58:39
Bike
beach: i think the specific threading question drmeister might have had in mind was what you do when a thread tries to read from a function cell while another one tries to write to it, since that's what he's dealing with
14:07:44
jcowan
Bike: Assuming that single cells can be updated atomically, I don't see why that's a problem.
14:08:12
beach
If the cell slot is aligned, most architectures would read or write it atomically I would think. But I may be wrong.
14:13:11
Bike
yeah, i figured atomism is the way to do it, but with clasp we have some really weird problem with doing that apparently
14:13:17
jcowan
In the vast majority of cases (except when funcall is invoked on a symbol or a function is declared notinline) it isn't necessary to read the function cell anyway.
14:14:39
jcowan
There might conceivably be machines whose pointer size is bigger than the number of bits on the memory bus: certainly the 8086/286 were like that
14:17:44
jcowan
Not sure what you mean by "change". It's clear that any function not declared notinline can be inlined, which means that dynamically setting the function cell can't affect call sites. Even if the function is not physically placed within its caller, invoking it directly is still legitimate, as the caller can't tell the difference between that and actual inlining.
14:18:43
beach
jcowan: So you are saying most functions are inlined or are allowed by the compiler to be inlined?
14:20:21
beach
jcowan: Furthermore, if you do what you are allowed to do in a compilation unit, then you make it impossible for the programmer to C-c C-c on individual functions to get a new version.
14:20:39
jcowan
If you claim that functions not declared notinline cannot be inlined, I would like to see the source of that claim.
14:21:49
jcowan
And I claim that there is no user-visible difference between actual inlining and direct invocation, which I might call "constructive inlining" (I grew up in a legal family).
14:21:59
beach
You are right. But if you do that, you make it impossible to practice incremental development.
14:23:34
beach
When a function is compiled, all macros are expanded. If a macro changes after the function has been compiled, then the function does not take the new macro definition into account.
14:23:39
jcowan
What happens when you declare a funciton inline and then redefine it, assuming the compiler respects inline declarations?
14:25:04
jcowan
Good point about macros. But presumably if a macro is redefined, compiled code doesn't see that change either.
14:25:35
jcowan
In any case, the recompilation could be done from the output of expansion rather than the actual source code.
14:27:54
beach
Since we are in #sicl, let me restate the goal of SICL to be an excellent system interactive development and debugging. If that means that it is not ultra fast, then so be it.
14:28:34
jcowan
Sounds like it *must* be compromised in the case of redefined macros; you are compelled to redefine compiled code that invokes such macros by hand (although the system could keep track for you and let you do it with one touch)
14:30:06
jcowan
Debuggability is usually provided in highly optimizing JS compilers by a process of deoptimization, which has the advantage that even functions on the current execution stack can be deoptimized.
14:30:46
jcowan
So the (human) debugger never sees the effects of optimization. This may not be practical in a system committed to AOT compilation.
14:32:03
beach
What would be some situation where such deoptimization would be required in order for the programmer to debug the code?
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