libera/#clasp - IRC Chatlog
Search
18:38:04
drmeister
Do you recall any other details? I thought llvm14 automatically upgrades to dwarf5 - so we didn't choose it. I'm wondering if the problem I'm having with addr2line on the hermes ubuntu system is that addr2line doesn't support dwarf5
18:40:23
yitzi
No, we chose it here https://github.com/clasp-developers/clasp/commit/b94f9f30c4119a2dd706fb4ee3d419a617ee18bc
18:41:37
yitzi
Specifically, in jit-setup.lisp with the (defconstant +debug-dwarf-version+ 5) ... its not a koga option
18:42:07
drmeister
I ran into troubles on bigmac and now I have to drive in to Temple to re-install xcode.
18:42:19
yitzi
You could try changing that to a 4 just for profiling...but we need it to be five for source code info to work
18:43:39
drmeister
It sounds like another rabbit hole. Anything that breaks source code info will probably be bad news for profiling.
18:45:07
yitzi
It won't break source code info for C++...just Lisp since I used one of the dwarf fields to store a reverse lookup on the logical pathname that isn't available in v4.
19:16:05
Zevv
hi folks; clasp utter newbie here, I got build failures on latest ubuntu, clang 13.0.1-3. koga did fine, but ninja build fails: http://ix.io/4msj
19:31:35
drmeister
For jitted code we generate a perf-<pid>.map file like javascript. It will take work to figure out if we can get AMD uprof to use that. I personally doubt it will be able to. AMD uprof looks proprietary and I don't see any support for javascript.
22:56:31
drmeister
yitzi: I use `:jobs xxx` in config.sexp to control how many processes are used when compiling cclasp - correct?
23:16:41
yitzi
drmeister: that controls the number of jobs that clasp-builder uses. If you need to change the number of jobs ninja uses add -j xxx to its command line
0:36:16
drmeister
Bike: Regarding the gprof style profiling you were mentioning. Having the compiler put code before and after every function entry. What is involved in that?
0:41:36
Bike
drmeister: we call a special profiling function before every lisp function call. this is what we do for stepping already.
0:41:59
Bike
the profiling function would presumably dump a compact representation of the stack to a file
0:46:39
Bike
if we just record the function being called and the time, along with calling something on function return that would cover some basic profiling stats,s but wouldn't be enough for a flame graph... well, maybe it would actually, if we processed the data
0:50:46
drmeister
It looks like the bytecode interpreter on macos runs a bit slower than on linux. It appears to spend more time making system calls.
1:00:36
drmeister
I would think that we would write an IP address on entry and a clock and then another clock value on exit. I don't know the details - I don't know how to get access to a high speed clock that could measure time so you could time a function that is just a few instructions.
2:22:38
Bike
one of the reasons i'm thinking of trying this compiler thing is because it would be more under our control. all the jit stuff seems a little unstable
2:46:57
Bike
we could just have a function that checks a thread local flag, and if it's on, sticks __builtin_returnaddress(0) and __builtin_readcyclecounter() in a thread local buffer somewhere, and bumps the buffer pointer
2:47:26
Bike
and then when you're done profiling we use something like the existing backtrace printer to turn the IPs into function names
3:50:37
Bike
course, i think the name resolution taking time is what you were hitting with perf or whatever before. not much we can do about that