freenode/#clasp - IRC Chatlog
Search
14:59:27
Colleen
Bike: drmeister said 13 hours, 18 minutes ago: I've made a mistake, satiation the way I imagined it does fully solve the dispatch problem. Instances of CL defined classes like STANDARD-GENERIC-FUNCTION have FUNCTION in their class precedence list - so the single-dispatch generic functions for FUNCTION have to handle instances of STANDARD-GENERIC-FUNCTION. It's not just C++ classes that have to respond. It looks like I'll have to put a mutex on
14:59:42
Bike
drmeister: rather than using mutices, you can just use atomics and CAS like we do for call histories
15:00:39
Bike
::notify karlosz local call idea: 1) lose local-call class 2) add slot to abstract-call that's either NIL or the FUNCTION being called 3) inline etc use that slot but leave enclose in place 4) a later, possibly client specific pass eliminates the enclose instruction if the calls don't need it
16:28:52
Bike
https://github.com/clasp-developers/clasp/blob/master/src/lisp/kernel/clos/discriminate.lsp#L501-L503 unfortunately the code is a little janky for bootstrap reasons
16:30:09
drmeister
Yes. I’ll set it up that way. I used a vector because I thought I could satiate it fully and searching it would be faster. But a dispatch vector needs a mutex and that would make things slower and more complicated
16:32:05
drmeister
It was falling back to searching the class precedence list a lot of the time anyway - and that was plenty fast.
16:35:33
drmeister
I'll keep it simple - I'll build a call history during dispatch and use that for dispatch.
16:40:32
drmeister
But we don't have standard generic functions until bclasp and I need some kind of dispatching to get us there.
16:49:53
Bike
we could maybe come up with some kind of subclass for forbidding add-method, remove-method
16:51:21
drmeister
On that - I do add-method for derivable classes in the static analyzer for example - so it's a bit more subtle.
16:52:19
drmeister
https://github.com/clasp-developers/clasp/blob/master/src/lisp/modules/clang-tool/clang-tool.lisp#L690
16:53:13
drmeister
I've struggled to figure out how this all fits together. I'm hoping we can figure it out now that I'm moving a few steps closer to generic functions.
16:54:41
drmeister
beach's fast generic function feature that you don't need a mutex to update the discriminating function is really, really useful.
16:55:53
drmeister
Right now we have a bit of a problem because we have an entry point and a compiled discriminating function. Once we switch to multiple entry points we will just have a pointer to a function description that we can update with CAS
16:56:46
drmeister
I think it only bites us when we try to upgrade an interpreted discriminating function to a compiled one - or you found a way to get around it.
16:58:34
drmeister
Sorry - I sound all over the place here. I'm a bit out of my element - but I'm trying to move things in the direction of getting to what I think will be the ultimate calling convention.
16:59:11
drmeister
Well, right now it's simple - I'll replace the dispatch-table vector I just added with a call-history updated using CAS.
16:59:52
drmeister
I can compare it side-by-side to the old SingleDispatchGenericFunction implementation using the ECL inspired cache.
17:00:41
drmeister
Then I will update master - which I screwed up somewhat yesterday or the day before. Good thing it's a holiday.
17:13:49
drmeister
We could limit these single dispatch generic functions so that you can't remove methods - that simplifies things because then you can use a list managed using CAS to add methods.
17:15:24
drmeister
I'm thinking we could leave them as a separate from standard generic functions - but use the discriminating function compiler to compile their discriminating functions to speed up dispatch.
17:17:05
drmeister
The discriminating function compiler only needs a call history and a specializer profile (for single dispatch generic functions that contains a single T in the first and sometimes the second position)
17:17:53
drmeister
We would have to add the ability to handle SingleDispatchMethod objects as the outcome - but that's a single function in every case.
17:19:55
drmeister
Yeah - of this: https://github.com/clasp-developers/clasp/blob/master/src/lisp/kernel/clos/hierarchy.lsp#L131
17:32:30
Bike
a-p-o-function is a function that permutes the parameters in order to satisfy the argument precedence order
17:32:48
Bike
since single dispatch functions only specialize on their first parameter (right?) it's probably irrelevant
17:33:35
drmeister
There are a few single dispatch functions that specialize on their second parameter. I'm thinking of replacing them with functions that do their own dispatch.
17:37:06
Bike
https://github.com/clasp-developers/clasp/blob/master/src/lisp/kernel/clos/kernel.lsp#L347-L360
17:38:57
Bike
https://github.com/clasp-developers/clasp/blob/master/src/lisp/kernel/clos/closfastgf.lsp#L499-L520 here's the code that adds a call history entry for a new call
17:40:41
drmeister
Hmm, a special method for generic function call histories won't work here because I'm not using that rack layout. I'm a bit more low level. But low_level_rackSet uses _Slots.store(i, value);