freenode/#clasp - IRC Chatlog
Search
4:48:13
drmeister
1. Schafmeister CE. CANDO - A Common Lisp based Programming Language for Computer-Aided Nanomaterial Design and Optimization. European Lisp Symposium. Krakow Poland; 2016 Sep 9;9th:75–82.
4:48:35
drmeister
1. Schafmeister CE. CANDO - A Compiled Programming Language for Computer-Aided Nanomaterial Design and Optimization Based on Clasp Common Lisp. Krakow Poland; 2016. pp. 75–82. Available from: https://www.european-lisp-symposium.org/static/proceedings/2016.pdf
4:51:52
drmeister
1. Schafmeister CE. Clasp - A Common Lisp that Interoperates with C++ and Uses the LLVM Backend. New York, New York, USA: ACM Press; 2015. pp. 90–1. Available from: https://www.european-lisp-symposium.org/static/proceedings/2015.pdf
4:55:14
beach
Darn. The one I want to cite is not in dl.acm.org. I guess I need to create my own Bibtex entry for it.
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