libera/#clasp - IRC Chatlog
Search
22:06:27
Bike
the bytecode compiler seems to... totally choke on defmethods? this is confusing. rapidly approaching "how does anything work" status
23:48:42
Bike
i probably should have tried bytecode-compiling slime earlier. this has revealed several problems.
23:49:10
Bike
currently it's at a point where it can compile and load swank, but then it segfaults during swank-loader:init. so that'll probably be annoying to figure out.
1:31:44
Bike
sanity check... can someone do (funcall (cmp:bytecompile '(lambda () (defun my-run-hook (functions &rest arguments) (dolist (function functions) (apply function arguments)))))) (my-run-hook '(list))
2:12:11
Bike
takes uh, ten seconds from M-x slime to the repl popping up. versus about 75s the normal way
3:14:23
Bike
i tried adding a bytecode build mode to koga etc, and _wow_ does it compile everything quickly, but then something dies because it tries to call clang to link stuff together
3:16:09
Bike
to actually use it as a build mode in any sensible way i will need to port the bytecode loader to c++. i am holding off on that until the fasl format has all the kinks worked out
3:16:52
Bike
but i think first i will work on improving the source info and syntax checking in order to make it usable in the normal image for slime/whatever
3:36:16
yitzi
What is the speed difference between bytcode and native code? Unless it is negligible wouldn't we assume the core image is all hot code and should be native compiled?
3:42:01
drmeister
I hope native code is faster - I think it is when I profiled it. Yes, we should assume the core image is all hot code. I'd like to have as much as possible compiled but I'll live with faster startup and faster cando-user-install if bytecode loads faster but runs slower.
3:59:47
Bike
i expect most of the core image isn't hot code, really. there's all kinds of stuff in there that doesn't need to go particularly fast and/or the compiler can't help with much anyway, like macros
4:06:47
Bike
hot code would be stuff like the sequence functions, arithmetic, CLOS runtime, and the compiler and loader. non-hot would be all the macros that support that stuff, the rest of CLOS (like add-method off the top of my head), loop, setf, defstruct, defpackage, disassemble, possibly the optimizers in cmp, MP/atomic macros, pretty printer, condition system
4:07:28
Bike
if we eventually transition to more of a JIT system, the way it would basically work is we bytecompile everything and then only native compile if something is run a lot, so it would be more clear in that sense