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