freenode/#clasp - IRC Chatlog
Search
12:44:24
drmeister
Bike: Is it possible to have call-with-variable-bound lambdas named as such? using (declare (core:lambda-name call-with-variable-bound.lambda))? By changing Clasp code - without adding implementation specific declares?
13:12:23
Bike
on t he other hand, i made it so that the call runs through convert, so there could be a compiler macro on c-w-v-b to annotate it
13:13:19
Bike
on the third hand, it might not be unreasonable for cleavir to have a named-lambda extension, since it's common and useful, and i think it could maybe be done while allowing ignorant code walkers
13:13:30
drmeister
It appears that nothing that I've done over the past several months has moved the build time by even one minute. I am supremely frustrated.
13:16:14
drmeister
Since profiling and backtraces are useless without JITted code symbols - I'm writing a 'symbolicator'.
13:16:51
drmeister
Clasp now writes out JITted symbol info to a file like... /tmp/clasp-symbols-20942-Qix1CS
13:17:44
Bike
also, you said you added direct calls, but did you add LTO earlier in build? if not, it would only affect the final image, right?
13:18:52
drmeister
You are correct - you can't get full benefit of direct-calls without LTO linking all of the C++ bitcode to whatever calls it.
14:00:11
drmeister
(symbolicate-buffer "hello there 0x10DC13211 this is a test" *standard-output* *s*) -->
14:01:32
drmeister
Anything containing multiple 0xYYY strings will have those 0xYYY strings converted to symbol names if they exist in the symbol table.
14:23:24
drmeister
I define these three methods that call each other - and the last signals an error
14:28:08
drmeister
The core::FuncallableInstance_O::entry_point(...) is mine - that's a level of indirection that we can remove.
14:28:56
drmeister
The #<POINTER ...> I'm not sure where those are coming from. They aren't in the symbol table obviously.
14:36:08
drmeister
It should be cc_dispatch_effective_method but I don't understand why it doesn't have a symbol.
15:45:33
drmeister
If I compile-file this... (defmethod foo () (bar)) (defmethod bar () (baz)) (defmethod baz () (error "in baz"))
15:49:44
drmeister
It doesn't look too bad after that. I can single step instructions from the start of FOO to BAR and it's not too bad, if a bit difficult to follow (probably because of optimization).
15:59:23
drmeister
I think the APPLY is coming from here https://github.com/drmeister/clasp/blob/dev/src/lisp/kernel/clos/closfastgf.lsp#L481
16:31:00
drmeister
Generic function dispatch isn't the source of our slowness - but now it looks really streamlined.
17:39:09
drmeister
Everything is pushed through to testing (1) fastgf is now fully operational and (2) backtraces look great once dispatchers are fully compiled.
18:02:09
drmeister
Once we find it, and kill it, and dance on its grave - fastgf will live up to its name.
18:04:40
drmeister
The problem has been that the backtraces gathered from tracing have been unmanageable.
18:05:01
drmeister
They are full of return addresses with no symbol information (due to the JIT) and C++ frames.
18:06:53
drmeister
I'm capturing JIT events now and generating a symbol table and now I'm writing a symbolicator program that will text swap addresses of the form 0xYYY to symbol names. symbolicator -s symbol-table-file <file-full-of-0xYY >file-with-symbol-names
18:07:56
drmeister
I did your single step through instructions to look at the fastgf call sequence - it's very short now.
18:08:56
drmeister
Profiling fastgf calls relative to regular calls in sbcl - generic function calls are about 3x slower than regular calls.
18:09:46
beach
Good luck. I am off to spend time with my (admittedly small) family. I'll be back tomorrow morning (UTC+2).
18:09:55
drmeister
Don't worry about responding - I'm dumping this into this channel for the log so that Bike and I can take it apart tomorrow.