freenode/#sicl - IRC Chatlog
Search
5:00:57
drmeister
I've converted a lot of (typep x '<cleavir-class>) to class-predicates. I've gotten a lot more parallelism out of compile-file-parallel - but there are still find-class invocations taking place.
5:05:13
drmeister
(make-instance (let ((x (load-time-value (list nil)))) (or (car x) (car (rplaca x (find-class 'context))))) ...)
5:13:29
no-defun-allowed
What does that do? It looks something like giving make-instance the class object at load time, with a useless cons thrown in.
5:14:33
drmeister
It allocates a cons cell at load time and the first time it evaluates it calls find-class and stuffs it into the car of the cons cell. Every time after that it returns the class by pulling it out of the car of the cons cell.
5:15:59
drmeister
WIth just (make-instance 'foo ...) that becomes (make-instance (find-class 'foo) ...) and find-class needs to be evaluated every time.
5:21:35
beach
drmeister: I don't think that should be something to do in Cleavir, but in your implementation of MAKE-INSTANCE.
6:02:01
beach
SICL (and therefore Cleavir) is largely about making the code look "natural" (I should use a better term, but I haven't decided which one is best), and to make that "natural" looking code efficient (sometimes even effective) using other means. The entire bootstrapping procedure can be seen as a giant exercise in this direction. I mean, (defclass t () () (:metaclass built-in-class)) and other similar constructs are perfect examples of
6:04:13
beach
Well, I haven't thought it through very carefully, but it seems to me it would be possible.
6:04:49
beach
You can even compile those as special operators if that is more convenient than a compiler macro.
6:05:52
beach
I might do something like that for SICL, since scymtym pointed out the idea of using "cells" for the class database, in addition to the function database that I already use it for in SICL.
6:08:05
beach
Probably FIND-CLASS to start with, assuming that MAKE-INSTANCE with a symbol argument calls FIND-CLASS.
6:15:45
beach
For ordinary function calls with in source code like (f ...), SICL customizes Cleavir to do something like (funcall (car (load-time-value (sicl-genv:function-cell 'f))) ...) but I don't make that explicit in Cleavir itself. This situation seems similar.
6:17:08
beach
That's a very general question. I haven't thought of all aspects of threads. But I think I figured out what to do with the garbage collector.
6:17:36
beach
I am not planning to do parallel compilation any time soon, so I won't have the performance problems you do (or did).
6:18:12
beach
Aside from GC, I have given thought to updating instances and adjusting arrays in the presence of threads.
6:20:46
beach
In general, I don't think I need to think as much about compile-time performance for SICL as you seem to have to think about for Clasp. Mainly since I don't bootstrap the way you do.
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?