libera/#clasp - IRC Chatlog
Search
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
13:11:51
yitzi
Bike: Do you know how STREAM-LINE-COLUMN, etc are getting exported from GRAY? I found an export statement for the classes in kernel/lsp/packages (its missing the base classes like FUNDAMENTAL-STREAM) byte I can't seem to find the export for the generics.
13:12:53
yitzi
Additionally, why is this needed? https://github.com/clasp-developers/clasp/blob/6397b56a8e27c38b0eac87cf986b7924e05f7168/src/lisp/kernel/clos/streams.lisp#L743-L747
13:17:25
yitzi
Ok...so the export is happening in C code... the second question still stands though.
13:48:39
Bike
https://gitlab.com/embeddable-common-lisp/ecl/-/commit/82aef0f69ed5489f081d533cf93d58b0564588e0 yeah, this doesn't seem like a good idea to me
14:06:12
Bike
in order to get good backtraces with source info for bytecode, i think we need to be able to pick out bytecode_vm frame and find their C++ arguments
14:06:21
Bike
not sure if that's possible without stackmaps, and not sure how we would get stackmaps
14:09:18
yitzi
Yeah, I removed the re-export of the CL symbols. Everything seems fine. I can't imagine anybody using it that way since everybody imports COMMON-LISP themselves.
14:20:52
Bike
alternately, we could rely on bytecode_vm itself not signaling errors, and just look through the VM call stack, maybe. but i'm not sure how it would be combined with the machine call stack.
14:24:10
Bike
because i have a scheme in mind for how to record source info for bytecode, so sldb v would work, but it's useless if we can't get it in the debugger.