freenode/#clasp - IRC Chatlog
Search
20:38:37
karlosz
just that, hash table allocation and access have never been a noticeable hotspot, since i think they're rather optimized
20:39:25
karlosz
although it's a bytecode compiler to a stack machine, i think all the runtime functions are actually in C
20:40:06
Bike
maybe we could save repeated work by building a cons to cst mapping at the top, and then just using it repeatedly
20:40:32
Bike
since i think each macroexpansion will build its own cons table, which will be redundant for macro forms with macro forms in them, which is of course common
20:41:54
Bike
i guess this is a reason that some kind of hash table with source information might be preferable to the cst objects sometimes
20:42:01
karlosz
yeah, that might help a lot with the consing, and also i don't think it messes up the code structure too much
20:42:46
Bike
seems like we could just have an optional cons-table argument to reconstruct, and then bind it as a special variable or whatever
20:44:15
karlosz
yeah, i mean most of the functions in reconstruct.lisp seem to already work in that style
20:45:20
karlosz
and also, lambda-list-parsing seems to be bad. i'm going to see if it's doing something particularly wacky there...
20:49:07
karlosz
there's no point in walking the parser rules on every invocation, if i'm reading this right
20:53:15
karlosz
yeah, and in the profile, you clearly see that the rule munging is taking up a ton of time
22:05:59
kpoeck
The clisp manual is very detailed, but can't find anything regarding profiling, strange
22:10:09
kpoeck
looking at the swank clisp code it smells like a clone of metering in the file suspiciously called metering.lisp
22:12:32
kpoeck
So in my humble opinion I believe your answer is wrong for clisp (sbcl seems to have specific profiling code though)
22:13:17
kpoeck
But my main point, since metering work for clasp we could hackup the metering file in slime to support clasp
22:14:25
kpoeck
in swank/clisp the profiling implementation simply uses swank-monitor:monitor and friends
22:57:52
drmeister
yitzi: I can reproduce the crash in the docker image on macOS - that's easier to debug.
23:10:03
drmeister
I'm trying to get some info - but it clobbered the stack and the backtrace is still printing.
23:48:18
drmeister
I mean - I'm not disagreeing, and I'm not looking at your code. I'm trying to develop a tool so that I can figure this out going forward.
23:48:42
drmeister
What I really need to do is protect a page on the stack to catch stack overflows.
23:53:34
yitzi
Yeah, so I just put a format statement at the top of each method. And it looks like it is call the :prefix specialization even though :root is specified.
0:25:21
karlosz
okay, not sure if i can really turn the parser into a parser generator as is, but at least the grammars can be precompute., saving a ton of consing during lambda list parsing
0:26:51
drmeister
For compile-file-parallel reducing consing is good. Reducing consing in the multiple threads that convert AST->HIR->llvm-ir is really good.
0:28:48
karlosz
since an average lambda list is extremely small, i'm not so much concerned about the algorithm, but the huge amount of object creation everytime one is parsed
0:29:19
karlosz
though maybe people use macros in a way that give you large lambda lists, im not sure
1:48:11
Bike
https://github.com/clasp-developers/clasp/blob/master/src/lisp/kernel/cleavir/reader.lisp
2:00:18
Bike
https://github.com/clasp-developers/clasp/blob/master/src/lisp/kernel/cleavir/convert-form.lisp#L22 and bound here
2:36:28
karlosz
OK, seem to have promising results: ocf.io/~karlos/before-preparse.svg and ocf.io/~karlos/after-preparse.svg
2:37:02
karlosz
this is compiling cleavir/convert-special.lisp for 30s, before and after the lambda list parsing change
2:38:12
karlosz
if the flamegraph is accurate, this is saying that preparsing the grammars drop cst->ast time from 38% to 28%
2:42:54
karlosz
yeah, this is supposed to reduce consing, not that much runtime is really spent parsing, i think more so whatever process-parameter-groups is doing
3:09:54
drmeister
I'm adding a stack guard to catch infinite recursion. I'm tired of getting hit by segfaults.
4:27:59
drmeister
I set up a guard page at the bottom of the stack and then I run a recursive function it crashes when the stack pointer hits the guard page - but clasp doesn't catch SIGSEGV at the moment.
4:33:42
drmeister
Did someone turn off signal handling somehow? The signal handling code appears to be installed but it doesn't get triggered.
7:55:56
kpoeck
::notify drmeister regarding signal handling. We made some changes, so that most signals are handeld and can even have handlers written in lisp
7:56:54
kpoeck
::notity drmeister kill -s SIGSEGV <pid> -> Condition of type: SEGMENTATION-VIOLATION in clasp
7:56:54
Colleen
Unknown command. Possible matches: notify, 8, set, mop, get, login, roll, say, uptime, grant,
7:57:30
kpoeck
::notify drmeister kill -s SIGSEGV <pid> -> Condition of type: SEGMENTATION-VIOLATION in clasp