freenode/#clasp - IRC Chatlog
Search
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