freenode/#clasp - IRC Chatlog
Search
12:27:52
drmeister
We defer cleanup of c++ classes on a per thread basis. And these are llvm classes.
12:33:12
kpoeck
There is some serious slowdown in some cl-bench benchmarks compared to last time i run them. Did check on my eclector integration branch. Am now recompiling on dev w/o my changes to see whether I introduced the slowdown
12:33:12
Colleen
kpoeck: drmeister said 12 hours, 11 minutes ago: Thanks for pointing out that slow backtrace problem - I came up with a solution that is much much faster. I'll push tonight.
12:38:42
kpoeck
https://gitlab.common-lisp.net/ansi-test/cl-bench/blob/master/files/gabriel.lisp#L729
13:32:13
kpoeck
I have a cl-bench run from the 4th of january that was still fast (apart from the bignums, they were slower), Version says it is 1797-g4b3abbd7e if that helps
13:59:17
Colleen
Bike: drmeister said at 2020.02.17 12:47:57: On linux 70-90% of the time is spent in Unwind_Find_FDE
14:04:42
Bike
also, i flipped through the logs - there's something to make backtraces faster? yes please
14:36:34
selwyn
i haven't had time yet to look at the flamegraphs - could the slow backtraces have been responsible for the poor flamegraph output? how do they look now?
14:55:41
Bike
drmeister: https://github.com/slime/slime/blob/master/swank/clasp.lisp#L710 do you remember why the swank/clasp locks are recursive? things seem to work fine with non recursive locks
15:15:49
Bike
there's an entire other thing for working atomically that i didn't know about. AtomicTHolder. cool
15:28:43
Bike
if i do (nth-value 1 (ignore-errors (funcall (block nil (lambda () (return)))))) clasp still dies aaaaagh
16:12:46
Bike
drmeister: https://github.com/slime/slime/blob/master/swank/clasp.lisp#L710 do you remember why the swank/clasp locks are recursive? things seem to work fine with non recursive locks
16:19:57
drmeister
I don't recall - I think since I didn't have good data at the time I just played it safe.
16:21:15
drmeister
I've got to tell you about our new compiler memory management scheme. We were leaking llvm compiler objects. We aren't leaking them now - but there is some danger that hasn't presented itself yet.
16:21:30
Bike
I ask because while I'm doing this I'm normalizing some interfaces and removed the `:recursive` keyword.
16:21:50
Bike
so if i merge it will break slime, which is bad, unless we remove that from swank/clasp.lisp
16:23:03
Bike
i mean what i did is look at the other implementation's swanks, and they're not recursive locks
16:24:24
drmeister
Hmm, I just realized our llvm C++ object cleanup scheme is more robust than I feared.
16:25:16
drmeister
Nothing can get collected until we run (gctools:thread-local-cleanup) and then only if the GC collected its wrapper.
16:27:34
drmeister
We have some quicklisp systems for which compile-file-parallel is pathologically slow. I'm trying to figure out which ones.
16:32:00
Bike
also things like run-dsymutil that i'm skeptical of the use of for programmers. but i can just not put those in the manual for now
17:51:50
kpoeck
in https://kpoeck.github.io/report.html are cl-bench results of different lisps/clasp-releases
17:53:21
kpoeck
The two one from the left are clasp as of 3rd of january with the bignum gc fix and without
17:56:45
kpoeck
Will try to bisect to find out where that started, will first go back to monday morning last week, since a lot was merged that day
19:03:33
Bike
(char-name (code-char 161)) => "UA1". sbcl gives "INVERTED_EXCLAMATION_MARK", which I'd say is better. Of course that would mean including a couple kilobytes of UnicodeData.txt or whatnot
19:53:47
Bike
drmeister: https://pastebin.com/L3NgX0Ck manual sketch. Mostly just wanna see if it has all the extensions Clasp has - I can't think of more. You can throw it at https://markdownlivepreview.com/ or something to see it rendered
20:28:00
kpoeck
Perhaps add profiling with flamegraphs? Debugging with (core:btcl), (core:safe-backtrace) & (CORE:BT-ARGUMENT <frame> <index>)
20:29:54
Bike
we ought to have an actual backtrace interface, like a backtrace object and navigating frames
20:31:46
kpoeck
I was starting to implement Shinmera dissect , but got distracted. He also has this nice overview table with capabilities of the different cl implementations
20:39:32
kpoeck
in revision b4c487592b91cd3ef1a24908320d893148dc8311 ctak is still fast, but CLOS/methodcalls either are really slow or hang
20:50:29
Shinmera
kpoeck: Oh, I was going to do dissect at some point myself, but I'd be very happy if I didn't have to! :)
22:14:16
drmeister
I've got this Unwind_Find_FDE issue under a microscope - if you are still here for a few min - could you drop by and take a look at it with me?
22:15:01
drmeister
Backtraces are truncated. flame graphs don't work. Functions I can figure out are all called LAMBDA