freenode/#clasp - IRC Chatlog
Search
18:54:15
drmeister
Whoops - I did it again. Writers arguments are ( value instance ) and readers are (instance)
20:43:07
Bicyclidine
the sandbox environment doesn't know keywords are constants bound to themselves. that's something
21:06:18
Bicyclidine
if you put :foo in the normal repl you get :foo back, because all keywords are constants bound to themselves
21:06:28
Bicyclidine
but the sandbox isn't clued into that, so if you put :foo in its repl it says unbound variable
21:16:48
drmeister
And black is white and up is down - it seems perfectly fitting for the times we find ourselves within.
22:09:41
drmeister
The only thing that's not working is multithreaded slime - and I'm working on that.
22:12:49
drmeister
fastgf lets me do this because it has an ancillary benefit, it recognizes invalid objects in a very, very inexpensive way.
22:13:40
drmeister
ECL needs to check if an object is invalid with every access - that spoils efficiency.
22:14:28
drmeister
Don't run profiling on the compiler. That's like trying to figure out inefficiencies in the US economy by looking down from the ISS.
22:30:23
drmeister
More constructively - do run profiling on small test cases that run a lot slower than sbcl and figure out where they are spending their time.
23:08:15
Bike
i have some ideas about effective methods that i think can shave generic function dispatch down more, though that might not be a bottleneck now
23:21:40
drmeister
I have a simple test case. I can't compile anything in a separate thread - it locks up.
23:22:02
drmeister
(mp:process-run-function 'foo #'(lambda () (funcall (compile 'nil '(lambda () (dotimes (i 100) (format t "Hello ~a~%" i)))))))
0:22:22
specbot
compute-discriminating-function: http://metamodular.com/CLOS-MOP/compute-discriminating-function.html
0:34:46
drmeister
Bike: I'm wracking my brain - trying to figure out how to identify what llvm value might be leaking across threads and causing this problem (if indeed this is the problem).
0:36:58
drmeister
On another tack - a DEFPARAMETER or DEFVAR in the main thread as Clasp is starting up would write into the value slot of the symbol - right?
0:37:28
drmeister
What if I put a check in symbol-value that checked if the value slot is read and an LLVM value was read out?
0:39:04
Bike
it was a few weeks ago... i'd start when the llvm5 stabilized and binary search up from there
0:49:35
drmeister
I'm looking for a DEFVAR or DEFPARAMETER in the cmp directory that would contain an LLVM value.
0:56:09
drmeister
The target-triple and the data-layout are calculated at startup and put into global variables.
0:57:16
drmeister
I don't know. They have string representations and I think llvm internal representations. The former should be fine to share, the latter - probably not.
1:01:10
drmeister
cmp::*default-target-triple* -> "x86_64-apple-macosx10.12.0" cmp::*default-data-layout* -> #<DATA-LAYOUT >
1:06:50
drmeister
I was a busy boy - destroying all of Clasp's multithreaded compilation capabilities.
1:35:15
drmeister
Rather, I'm making the *thread-local-builtins-module* special variable thread local and initialized to NIL and then loading it lazily.
2:23:41
drmeister
Also - I realized I'd left debugging in bclasp on - turning that off for timing...
2:33:45
drmeister
I think this will fix the problem with multithreaded slime - but I haven't tested it yet with cclasp.
3:13:56
drmeister
(defclass foo () ((arga :initarg :arga :accessor arga) (argb :initarg :argb :accessor argb)))
4:25:25
drmeister
::notify Bike We aren't taking full advantage of these new fastgf optimized slot accessors. ECL's std-class-optimized-accessors are still using hash tables. This is revealed by profiling allocation of CLOS objects.