freenode/#clasp - IRC Chatlog
Search
14:56:55
kpoeck
I hope I have fixed this annoying "Warning: compiled-function-file expected a function as argument " in the debugger
15:14:48
drmeister
kpoeck: So what was the conclusion of that benchmark - was all the slowdown eliminated by switching back to "object" mode?
15:15:28
drmeister
So that's like a 400x slowdown because of "large" code model vs "small" code model?
15:17:39
drmeister
(1) stack unwinding on linux has a mutex and that seriously slows down compile-file-parallel.
15:18:02
drmeister
(2) We need to use the "large" code model for compile-file-parallel - and that slows down everything.
15:18:47
drmeister
POIU doesn't appear to work - blocking us from using it to do more than single core quicklisp compilation.
15:19:16
drmeister
(3) POIU doesn't appear to work - blocking us from using it to do more than single core quicklisp compilation.
15:22:06
kpoeck
Generally clasp is much faster than it used to be, the ansi-tests now run in 40 minutes on my 8 year old machine and require much less memory
15:27:16
kpoeck
I have 54 benchmarks result for clasp from the last 20 months, perhaps I can make a graph showing the evolution
15:45:31
Bike
i talked with beach a bit about call with variable bound and stuff last night. he's working on the sicl lowering of the new instructions about now, but told me i should still hold off on using cleavir2
15:45:41
Bike
i mean, i'll still look at how things go with the new instructions, like we talked about
15:48:21
drmeister
Ok, thank you - I think there is a major breakthrough to be had there once we can get rid of call-with-variable-bound.
15:52:09
drmeister
(5) Our memory managers both have mutexes in their allocators. MPS currently worse than Boehm.
16:04:45
drmeister
I'm going to extract the ctak example into a single C++ file and create a github project to test libgcc and unix implementations.
16:08:48
Bike
mm, well, he kind of has a parallel stack for special bindings and stuff, whereas we mostly use the regular control stack
16:09:01
Bike
i think it ought to work out, though, it's the same difference as we have in the current iteration of unwinding
16:12:03
Bike
it's just another way to do it... i mean, we don't push and pop, but we still need to perform operations at the same times to keep everything coherent
16:12:21
Bike
one advantage is that the popping can be done explicitly instead of only when exiting the function
16:12:58
Bike
like, if we have (tagbody loop (multiple-value-prog1 (form) ... (go loop) ...)), we'll keep allocating more space for the multiple values, and not freeing anything until the function exits
16:14:34
drmeister
I see, because the point is to do more of this control flow within functions and not just at the level of functions.
16:42:47
beach
While it is currently a parallel "stack" it is a stack allocated as a list of dynamic-environment entries on the heap. But the ultimate idea is to allocate those entries on the ordinary control stack.
16:45:45
beach
I think it will be easier to debug things if I don't introduce yet another allocation mechanism at first.
16:54:43
drmeister
There was a weird post that said that Ubuntu 14 server did not show the terrible multithreaded performance I see on the latest debian.
16:55:56
drmeister
Its a small test that tests the multithreaded unwinding performance that seems to be causing us problems.