freenode/#clasp - IRC Chatlog
Search
0:18:47
drmeister
Bike: You understand the unwinding stuff better than I do - do you have an idea for how to fix this?
0:19:36
Bike
doesn't this just indicate that whatever unwind.cc is isn't doing unwinding in the same way clasp is?
0:22:01
drmeister
There doesn't appear to be a difference between libstdc++ and libc++ with this demo - not a significant one.
0:22:24
Bike
right. so i'm saying it seems likely to me that this means the demo isn't an accurate reflection of clasp.
0:23:11
drmeister
Yes - I'm with you there . That's where my vague "But I’m wondering if we are doing even worse than that" came from.
0:23:11
Bike
unless there's some other reason for there to be this gulf between linux and mac performance
0:23:34
Bike
like mac performance seems okay to me. it's not amazing or anything but there hasn't been this botteleneck, yeah?
0:24:22
drmeister
I can't link libc++ with clasp on linux - it throws up all kinds of missing symbols - I'm not ssure why.
0:25:42
Bike
and like, i've been talking about writing our own unwinder - and i still think that has some advantages - but Unwind_Find_FDE, the big offender, is called by Unwind_RaiseException, isn't it?
0:25:55
Bike
Unwind_RaiseException is exactly the underlying function our unwinder would still be calling
0:30:42
Bike
https://github.com/gcc-mirror/gcc/blob/master/libgcc/unwind-seh.c#L328-L330 and here's the source
0:33:24
drmeister
https://gcc.gnu.org/onlinedocs/gccint/Exception-handling-routines.html#Exception-handling-routines
0:33:58
drmeister
Right - but any stack unwinding has to call these - are they the reason for the slow down.
0:36:24
Bike
there are two problems with unwinding. one is general slowness, independent of OS or implementation. that is what i have in mind when i talk about writing an unwinder.
0:36:54
Bike
then there's this Mac/Linux thing, which is apparently due to Linux's implementation having this stupid linear search in it. Writing our own unwinder wouldn't help with that, probably.
0:40:13
drmeister
(defun foo (num) (dotimes (i num) (block hhh (funcall (lambda () (return-from hhh))))))
0:58:35
drmeister
(defun foo (num) (dotimes (i num) (block hhh (funcall (lambda () (declare (core:lambda-name inner-foo)) (return-from hhh))))))
1:06:33
drmeister
Question though - the consing - are we allocating a closure on the heap or on the stack in this case?
1:08:27
drmeister
Here's a thought - we are doing a lot of unwinding. Unwinding is allocating closures on the heap. Allocating on the heap involves a mutex in the GC.
1:09:54
drmeister
Unwinding requires a closure to pass the closed over handle for the the unwind target?
1:10:28
Bike
ok like, this is all deep and confusing stuff and we need to be exact. when you say "unwinding" i think like, what happens, at runtime, when you hit a return-from
1:12:08
Bike
anyway, although the underlying "unwind tag" has dynamic extent, the closure itself can still have unlimited extent, so we can't stack allocate it.
1:12:21
Bike
we could stack allocate the particular cell for the "unwind tag", but we shouldn't even have a cell anyway really
1:45:34
drmeister
On macOS (time (foo 10000)) -> Time real(3.058 secs) run(3.057 secs) consed(0 bytes)