freenode/#clasp - IRC Chatlog
Search
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
14:50:55
Bike
for asts it occurs to me that the parallel build is probably going to interact badly with our side effectual setup about inlining
16:06:38
Bike
side effects during load other than definitions are like, a few things in the compiler, and clos
16:08:04
Bike
i'd like to isolate the standard library (i.e. lsp) from the compiler. right now there are a few files that should basically be with the compiler (fli, direct-calls, backtrace) and then only some tiny things
16:15:21
beach
Did you find an explanation for the big performance difference between Clasp and CLISP?
16:16:18
Bike
no, but i figure a lot of it is that clisp is compiling to a cl-friendly bytecode, whereas clasp compiles to machine code.
16:16:55
Bike
and both of them are much slower than say sbcl, so cleavir generating poor code for itself is probably still a central issue
16:19:50
karlosz
i dont think generating poor code makes the compiler run slow. it seems much more like a microoptimization compared to genuine algorithmic slowness in the algorithms cleavir uses
16:21:11
Bike
the result you got with basic blocks is pretty interesting, so i'll probably give that a shot
16:21:51
Bike
the thing about bad code is that it's hard to see how cleavir would be generating code sufficiently horrible to be that slow, compared to compilers that don't optimize a ton anyway like ccl or clisp
16:23:36
karlosz
or when you can use basic blocks instead of instructions, since you typically have way less basic blocks than instructions
16:24:12
Bike
mapping instructions could inherently use basic blocks, since as is it records every instruction it's hit in a hash set to avoid doing things more than once
16:24:37
beach
karlosz: I don't follow your argument that the generation of poor code does not slow down the compiler. After all, the compiled compiler would then run slowly, no?
16:25:43
Bike
so it's hard to imagine how adding type inference would improve the speed of the compiler
16:26:50
karlosz
i may add new bytecode instructions that dont do type checking so i can leverge type inference tho
16:27:36
Bike
i mostly would just like cleavir to be like, at most half as slow as sbcl, so this would stop being an overriding concern
16:31:43
beach
I guess I could use the SBCL statistical profiler when I create an extrinsic environment for SICL. That way I could find out whether there are any bottlenecks in AST or HIR creation. But I am not running the type inferencer I think, so that one should then be added.
16:32:19
beach
Isn't there some library that helps with the interpretation of the output of the profiler? Maybe even producing flame graphs?
16:33:27
Bike
since ast generation and ast-to-hir are very recursive, the flames have a bunch of spires
16:34:01
Bike
additionally, ast generation calls the entire compiler recursively (for eval-when etc), so, it's just tricky overall.
16:34:32
Bike
a few times i've done profiling and ended up concluding that the compiler is slow because the compiler is slow, which was frustrating
16:41:51
Bike
what's the procedure now? i can try it locally and fix the problems that are probably my fault
16:42:41
beach
It looks like I have an instruction where I used to have a list when HIR is translated, presumably to Common Lisp.
16:45:24
Bike
basically there's a few (destructuring-bind (first last owner) basic-block ...) that need to be changed into with-accessors. i can do it if you'd like.
16:49:17
beach
I don't follow what you are saying. But there is a call to REMOVE that expects a list of lists where the inner lists have three elements. But now, instead, it is called with a list of basic blocks.
16:50:12
Bike
Right, those too... in that case there's like ":key #'third". that needs to be :key #'cleavir-basic-blocks:owner now