freenode/#sicl - IRC Chatlog
Search
4:32:11
drmeister
beach: I look forward to seeing your talk on Tuesday. Bike and I were talking about the call site optimization. I don't want to put words in his mouth but he felt that in cleavir "truckler" (sp?) would be important to get the type system expressive enough to implement call site optimization. Is that consistent with your thinking?
4:33:37
beach
I just barely finished my coffee, so can't think clearly yet. I hadn't seen the connection between Trucler and call-site optimization.
4:38:00
drmeister
Have you folks made progress in implementing the method - or are there advancements over the paper I read several months ago? I guess I'll find out.
4:38:25
beach
I have a significant backlog of ideas, most of which have been published in papers, that I haven't had time to act upon. So I don't always see all the implications.
4:39:45
beach
I am trying hard to subcontract some implementation work so that I can concentrate more on the ideas and on other things like documentation.
4:40:27
beach
So no-defun-allowed is working on register allocation. And perhaps Gnuxie[m] will work on the disassembler.
4:43:00
beach
drmeister: I think if I started a fundraiser for SICL, I could probably get a few thousand € per month, but then there are few people who are both qualified and available. It's a big problem.
4:45:15
beach
Such a thing, I hope, would generate more interest from people who are qualified to help.
4:46:35
beach
But the "call-site manager", i.e. the module in charge of creating the snippets for call-site optimization technique, will be very simple initially, and it will just generate snippets containing the code for the default function-call protocol.
4:47:42
beach
I know, and I see how much you suffer from that, and I would not want that for myself.
4:49:17
beach
Yes, I know. But I have neither the time, the energy, nor the desire to keep up with external stuff the way you do.
4:49:35
no-defun-allowed
Would adding ELEMENT-TYPEs to HIR affect Clasp? I guess not, as you use your own Cleavir, and those types can be safely ignored, but I should double check.
4:54:17
beach
Different topic: We know that type declarations do not mean that the types are verified. And we know that CHECK-TYPE would be the thing to do if we want that, but CHECK-TYPE signals a correctable error, and I worry about code bloat if I were to use CHECK-TYPE in small functions like CAR/CDR.
4:54:18
beach
Should I quit worrying, define a macro similar to CHECK-TYPE that signals an ordinary condition, or something else?
4:54:38
drmeister
no-defun-allowed: Ask Bike - but you folks shouldn't worry about compatibility with us. We will catch up.
5:17:35
no-defun-allowed
beach: It so happens I thought about this yesterday. After a test with SBCL, I found that a custom CHECK-TYPE-like macro either was slower or about as fast as using CHECK-TYPE.
5:18:56
no-defun-allowed
(CHECK-TYPE X INTEGER) expands to (DO () ((TYPEP X 'INTEGER)) (SETF X (SB-KERNEL:CHECK-TYPE-ERROR 'X X 'INTEGER))) and all the code is in CHECK-TYPE-ERROR. I suppose you could even move the loop into CHECK-TYPE-ERROR too.
5:19:47
beach
Sure, but if you implement both from scratch, there should be no difference in performance.
5:20:11
no-defun-allowed
I think the level of code bloat would be comparable to that of the error paths of argument parsing.
5:21:07
no-defun-allowed
Yes, we could move the loop into CHECK-TYPE-ERROR to keep it out of CAR in that case.
5:21:11
beach
I guess when implemented as a function like what SBCL does, the bloat would be limited.
5:24:39
no-defun-allowed
I found out as I accidentally wrote a macro which expands to using a declaration instead of CHECK-TYPE; so I fixed it, but it ran slower (even though I believe SBCL does runtime checks with safe code). Then I investigated the implementation of CHECK-TYPE, and found it couldn't be written faster. Then I found another optimisation which made it faster then before.
5:25:56
no-defun-allowed
That momentary dip in performance appears to happen frequently when I write virtual machines.
5:28:19
no-defun-allowed
What I found out was that I could perform "type splitting" on arithmetic instructions, which involves optimistically testing if all the arguments are FIXNUMs, and then generating a fast path for fixnum arithmetic. I believe you did something similar with sequence functions long ago, but I forgot exactly what.
5:29:48
beach
For the sequence functions, I suppose it would have been something other than fixnums.
5:32:00
no-defun-allowed
Yes, you do type splitting on sequence types and other loop invariants such as the :end argument, instead of number types.
5:36:50
no-defun-allowed
Now I don't know where I got the idea that it is called "splitting". The Self compiler performs "type prediction" with some messages generating a fast path for fixnums and arithmetic messages as I describe.
5:37:14
no-defun-allowed
Did that make any sense? A name would help, but I don't think it is a new technique.
6:58:17
beach
There is a named function call in the loop, so it is subject to the technique in the ELS paper this year.
6:59:21
beach
But, what if we don't generate real snippets for calls to error functions or to functions like CHECK-TYPE-ERROR, and instead a call to a "dynamic linker".
7:05:20
beach
Well, maybe not so interesting. The information about the arguments would have to be present in the code object of the caller, but not in the instruction stream. It may be the same amount of information though. Is there an advantage of removing this information from the instruction stream?
7:07:32
beach
Something to contemplate today I guess. And this idea of "dynamic linking" could be useful for other stuff.
7:08:51
beach
For one thing, it could be used to avoid having the call-site manager generate default snippets for all callers right away. Those snippets could be allocated as they are needed.
7:13:53
beach
It would also be faster define or redefine callers. Rather than the call-site manager having to generate a snippet up front, it could reuse a default one that invokes the dynamic linker, or generate a very simple one that does it.
8:17:25
beach
So if we use CHECK-TYPE, for reasons of internationalization, we must omit the STRING argument.
8:18:26
beach
If additional information is required, we would have to include it in the type instead.
8:22:40
heisig
Yes, more specific type specifiers are much better than any kind of string, even without internationalization.
8:26:56
beach
I am also tempted to try to include source information in the error. Then, if we are in an IDE, the PLACE argument to check-type would be highlighted, rather than the name appearing in an error message.
8:27:51
beach
There are lots of situations like this where I want to rethink what traditional Common Lisp implementations do, and adapt the behavior to better tools like an IDE or a real debugger.
8:28:44
beach
Something similar to what traditional Common Lisp implementations do would also have to be included, in case someone has the bad idea to run it from a terminal.
8:29:16
beach
But I want to think about the consequences to the compiler for both these situations to be possible.
8:32:09
beach
The highlighting idea is advantageous for two reasons. First, usually, the message would have symbols in upper case, whereas the code would typically be lower case. Second, there may be several places (typically variables) with the same name in different scopes, By highlighting the right one, the message becomes easier to understand.
8:36:23
beach
Another thing I want to do is to "hide" the use of Acclimation. Currently, condition reporters are necessarily separate from the definition of the condition, but if we use external libraries, that is not always going to be the case. So I want to figure out a way to make the condition reporter in the definition be the English-language one, while still allowing for the *LANGUAGE* variable to be changed.
8:38:06
no-defun-allowed
Sometimes I use the string argument to CHECK-TYPE for "intentional" types, but a suitable alias for the type would be better still.
8:38:23
beach
Another reason I want to "hide" it is that if SICL contains modules with condition definitions in it, and those modules are independently useful, I don't want to impose Acclimation on other users. By re-including the English-language condition reporter in the condition definition, it will be easier for others to use the code.
8:39:35
beach
no-defun-allowed: Right. Since there are several ways of expressing a particular type, we can use specific variants to generate specific messages.