freenode/#clasp - IRC Chatlog
Search
15:25:41
drmeister
The inner loop would update the call-history. If the outer loop detects that the discriminator function has changed the outer loop starts again. This time the inner loop detects that the call history already includes the specializers and it returns to the outer loop.
15:28:33
beach
Before, did you mean "copy-and-swap" (A C++ idiom apparently) or "compare-and-swap" (an instruction to help with synchronization)?
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>