freenode/#clasp - IRC Chatlog
Search
15:32:31
drmeister
There's a problem with my suggestion however. The MOP SET-FUNCALLABLE-INSTANCE-FUNCTION is not useful for this - I need a COMPARE-AND-SWAP-FUNCALLABLE-INSTANCE-FUNCTION
15:34:00
drmeister
That causes me a lot of anxiety - if I can't do something without the MOP - have I gone off the rails?
15:37:24
drmeister
Or - I'm causing problems by compiling a new discriminating function after memoizing an entry in the call history.
15:38:41
drmeister
Perhaps I should just be invalidating the discriminating function and let the invalidated-dispatch-function call compile a new discriminating function (I use dispatch function and discriminating function interchangeably).
15:39:42
beach
That would be my preferred solution. But then, I haven't worked out the scenarios, and I can't, because they depend a lot on the representation of things.
15:40:18
beach
Also, there are different reasons for updating the call history, and they might need to be handled differently.
15:41:17
drmeister
They will need to be handled differently. I'm worrying about the routine updating of the call-history due to dispatch-misses. Changing classes and methods is a whole other can of worms.
15:45:42
beach
For example, in SICL, I have a rack containing both the call history and the discriminating function. I could make the protocol so that it has to allocate a new rack. Then I can use a single CAS to update the entire thing.
15:47:31
beach
Notice that I am not saying it is a GOOD idea. Just that the possibilities depend intimately on the representation.
15:50:10
beach
When I made that decision (representing every object with a header and a rack), I had a hunch that it would help both with synchronization and with memory management. But I fully admit that I didn't work out all the scenarios at that point. I still haven't.
15:59:48
frgo
beach: where in SICL di see the object representation being coded/implemented? (I want to learn how you actually did that header + rack thing)
16:00:59
beach
During the bootstrapping process, the header is represented as a host standard instance, and the rack as a host vector.
16:02:01
beach
Once I have a graph in the host that is isomorphic to the one I want in the executable, I traverse that graph and generate binary code in the form of an executable.
16:53:21
drmeister
beach: Clasp also has a header/rack implementation for CLOS objects. Although there are a few more things in the header to mimic ECL-style objects.
17:53:20
Serenitty[m]
Otherwise, the target triple error messages make it practically unusable. It's hard to see the actual output.
18:01:04
Serenitty[m]
Huh. The issue is that it still lags whenever all a slew of those error messages comes up — they're just invisible.
18:03:16
Serenitty[m]
Oh, so it normally takes a minute to compile whenever you define a function in the REPL?
21:25:37
drmeister
I've converted the fastgf over from using a generic function lock to using compare-and-swap on all updates to the call-history and the specializer-profile.
21:31:16
drmeister
Bike: I learned a new trick that helps immensely with debugging in lldb. C++ functions can be defined with __attribute__((optnone)).
21:32:00
drmeister
I'm starting to use that for C++ error functions so that I can get more info on the error.
22:00:38
drmeister
Does find-class need to be fast? What if I implemented it using an alist - would that be a terrible idea?
22:13:51
drmeister
Unless the object fits in a pointer - from what I read it's no better than a lock.
22:14:23
drmeister
I'm not completely certain about that - but it looks like a bad idea to make a large data structure std::atomic - I'm not even sure what it means to do so.
22:15:29
drmeister
Now, that being said - clasp uses a ribcage hash tables (vector of alists) - it may be possible to make that lockless.
22:18:00
drmeister
Implementing fastgf with CAS instructions has opened my eyes to another way to do multi-threaded programming.
22:28:35
drmeister
Well - actually - it may be that slow - but still -what are you trying to compile?
0:57:27
drmeister
Serenitty[m]: I see what you are talking about wrt the target triple. I'm trying something new - to read the target triple out of an llvm-ir file built by clasp.
1:00:31
drmeister
On OS X it doesn't complain as loudly as it does on Linux - so I didn't notice it.
1:44:18
drmeister
I could never get the target triple that I got from llvm to agree with the ones that clang was generating.
1:46:22
drmeister
Also, even with all the warning that were being generated - 20 min have been shaved off the build time.
3:15:16
drmeister
Well, it's not faster - the next build wasn't faster the next time. I'm still rearranging things.
3:23:09
drmeister
Bike: I'm getting this error occasionally - did we see this recently? !!! Mismatch in irc-store between val type #<TYPE float> and destination type #<TYPE float>