freenode/#clasp - IRC Chatlog
Search
21:05:32
Bike
oh, it does have one? maybe defun inline hook is just messed up during build or something.
21:06:35
drmeister
This would explain why sometimes incremental build breaks with errors about inlined-two-arg-+ being missing.
21:07:00
drmeister
I didn't realize that inlined-two-arg-+ was even tied to a function - I thought it was just a symbol.
21:08:09
Bike
https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/clasp-builder.lsp#L573-L576 there's always this crap
21:09:49
drmeister
https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/cleavir/inline-prep.lisp#L130
21:13:32
drmeister
I see - inlined-two-arg-+ HAS to have a definition - at least once otherwise there would be no AST.
21:14:32
drmeister
Or set the fdefinition of inlined-two-arg-+ to a function that generates an error?
21:15:25
drmeister
I don't see a reason why it's broken at the moment. It's clearly being defined and so the AST should be generated - wth?
21:17:03
drmeister
On another topic - karlosz says that he has cleavir compiling cleavir and I have a copy of it.
21:17:56
drmeister
In this microbenchmark - even without inlining clasp generated code is 7x faster.
21:19:40
drmeister
There are a lot of warnings - he squelched most of them - but I'm running in a macOS terminal so that it's hopefully not such a big deal.
21:29:18
drmeister
After that running: (time (let ((sys::*load-compiling* t)) (load "cleavir/load.lisp")))
21:30:45
karlosz
otherwise it would just be loading those files with the clisp interpreter again and again
21:41:30
karlosz
not sure how much is there but that includes stuff like alexandria, eclector, etc...
22:25:11
drmeister
In clasp (asdf:load-system :alexandria :force t) returns immediately after the first time I run it.
22:29:00
karlosz
thats about the time i had for clisp+cleavir before i switched my basic block representation
22:32:58
drmeister
If the "LLVM time" and "clang link time" is accurate (and I'm not sure they are) then 37.3 seconds is spent in llvm/clang
22:35:10
drmeister
So Clasp running cleavir is about 3x slower than clisp running cleavir and it uses about 2.5x the memory.
22:36:45
drmeister
I need to spend some time looking at how llvm time and clang link time are calculated.
22:45:47
drmeister
Would it be interesting to add a facility to TRACE that reports time and memory allocation?
22:46:53
Bike
you mean in the course of the call? that's kind of weird, but i guess it could be interesting
22:48:19
Bike
maybe start with an ability for TIME to do detailed memory breakdowns and use it in trace if we want
22:54:06
drmeister
Sounds like it could use an API for implementation dependent memory allocation tracking.
23:17:49
karlosz
apparently there is also a JIT compiler in clisp that takes bytecode and turns it into machine code on the fly
23:18:04
karlosz
no idea how that works, though it might be worth investigating to compare with clasp more fairly
23:47:40
drmeister
'clang link time' is acurate - it's the time spent in the system call that runs the clang link
23:50:56
Bike
another thing is that clisp cleavir cleavir's 15 seconds for alexandria is still super slow
23:52:56
Bike
karlosz set up cleavir to run in it, so we're comparing how well it does against clasp.
0:16:00
drmeister
I moved the code that keeps track of llvm time out of C++ into Common Lisp - so I'm a bit more certain of what it is tracking.
0:27:40
drmeister
Bike: Can cleavir running in sbcl do this yet? Compile itself and then compile itself again?
0:40:22
drmeister
As we discussed - I added a slot to classes REF_CLASS_ALLOCATION_COUNTER - its for optionally tracking how many instances of that class are allocated.
0:41:41
drmeister
It's a slot that will store a fixnum and be incremented atomically by the allocation machinery.
0:43:40
Bike
though something more functional like atomic incf of specifically a slot would be nice.
1:03:19
drmeister
Hmm, from reading a bit it sounds like a bad idea to try to cast non-atomic values to atomic ones.
1:07:43
drmeister
I think it's possible - but it's dangerous because you might read the slot non-atomically
1:12:01
drmeister
Nevermind the spin lock - I'm just going to be disciplined wrt the allocation counter.
1:41:02
drmeister
There are issues with alignment and aliasing that makes it look like a bad idea to try to cast non atomic data to atomic data.
1:44:42
drmeister
Ideally we want these counters to be thread-local. We don't want counts from other threads adding in - that would wreck it.
1:45:34
drmeister
Yeah - maybe in something like the thread-local bindings for special variables. Indexed by stamp.
1:51:38
drmeister
But every object allocation would also allocate a CONS cell and the CAR would point to the object.
1:52:14
drmeister
Then you can walk the list to figure out what was allocated - you'd have the order as well.
7:22:03
kpoeck
cl-bench-results are in https://gitlab.common-lisp.net/kpoeck/ansi-test/wikis/cl-bench-results-original
7:56:28
scymtym
drmeister: you asked about a CL implementation of the language server protocol. i have a simple one that i use for interfacing parser/compiler things with emacs