freenode/#clasp - IRC Chatlog
Search
22:39:53
drmeister
::notify bike Could you take a look at the log - I'd like to talk about REDUCING our linking options which would allow us to remove code from debug_unixes.cc/debug_macos.cc . It would also mean turning agh
22:40:44
Colleen
Bike: drmeister said 50 seconds ago: Could you take a look at the log - I'd like to talk about REDUCING our linking options which would allow us to remove code from debug_unixes.cc/debug_macos.cc . It would also mean turning agh
22:41:31
drmeister
I've been keeping shared object/library linking alive because it's very similar to LTO.
22:44:11
drmeister
I implemented faso/fasp files a year ago because I wanted to try this experiment where we load object files into the JIT and link at load time.
22:44:48
drmeister
I think the result is that this works very well. It's fast and it looks like we can do it multicore and make it almost imperceptibly fast.
22:45:10
drmeister
Previous to this we were linking JITted code into .so/.dylib files and those were our .fasl files.
22:46:47
drmeister
Ah - we will still be able to load those - we just get their return address symbols using backtrace_symbols(...)
22:48:22
drmeister
Now that I think about it - I don't know why we are calling: add_dynamic_library_using_handle(...) from core__load_binary(...)
22:50:39
drmeister
For some reason we call add_dynamic_library_using_handle(...) from core__load_binary(...) and I'm thinking of completely removing core__load_binary(...), which would remove the call to add_dynamic_library_using_handle(...), which would start tear out some code from both debug_unixes.cc and debug_macos.cc
22:51:37
drmeister
If I remove core__load_binary(...) then I can remove all the clasp and wscript code that links .fasl (.so/.dylib) files.
22:52:50
drmeister
It would remove the CLASP_BUILD_MODE="fasl", which we haven't used in about a year.
22:53:48
drmeister
That would close off the idea of using LTO for optimization - but it doesn't work properly without a lot more work.
22:54:25
drmeister
I'm thinking for optimization we go in a different direction - we implement beach's call site optimization. That works with the faso/fasp files fine.
22:56:03
drmeister
We could do call site optimization to have Common Lisp code call C++ code that takes doubles directly.
22:57:20
drmeister
If we know a C++ function takes a double and we call it from CL and we have the value in an unboxed double - then we can create a call-site that takes it from wherever it is in the CL function and put it in whatever double register the callee needs.
23:07:22
drmeister
My basic point is I think with faso files and call site optimization we can get the kind of performance that we could get with LTO and in a much more flexible/lispy way.
23:22:52
Bike
the c++ functions are static, so i would think we can do that without the call site optimization? just generate calls with the unboxed parameters