freenode/#clasp - IRC Chatlog
Search
3:41:06
drmeister
You will have to ask Bike - I hoped it would be clear from the context - I don't follow the details.
3:42:18
beach
I thought we first wanted to work out whether inlining is a problem and, if so, how to improve it.
3:43:34
beach
And his proposal seems to be similar to that of karlosz in that it makes a special case for LET that makes inlining unnecessary for most LETs.
3:44:18
beach
1. Make special code for LET so that we can leave the problematic inlining code in there while still compiling Clasp fast enough.
3:51:43
drmeister
I'm not sure what to say - I don't understand well enough what he is planning to discuss it - I'm trying to not have my finger in everything.
12:27:40
Bike
well, first off inlining is certainly a bottleneck. there's no question. cst-to-ast results in major, major slowdown.
12:28:28
Bike
but i believe the slowdown is pretty much entirely due to LET. LET functions have unique characteristics, like having deep nesting (causing the multiple copies)
12:29:28
Bike
if we're inlining global functions, we can skip a lot of the analysis partial inlining does now- that's a major inefficiency- since we can just determine things ahead of time
12:30:24
Bike
we only need the full analysis for the comparatively rarer cases of local and anonymous functions, and i think the code we have now is acceptably performant for that anyway
12:33:06
Bike
i also don't think characterizing "pre-inlining" LET as special is fair. we'd be marking where variables are created, which we probably want to do for various reasons anyway, and then letting segregate-lexicals use that information.
12:33:23
Bike
it's letting segregate-lexicals consider multiple kinds of instructions as creating bindings, instead of just ENTER.
13:10:47
Bike
I guess it's like, we COULD compile (foo ...) for function foo as a call to FUNCALL, and then rely on general mechanisms to reduce it, but why bother? is that really a "special case" or just basic semantics?
13:27:33
beach
So here is what I think. Inlining has a performance problem. It might be that we are using a quadratic algorithm where a linear one is available.
13:28:21
beach
It is entirely possible that, when this problem is fixed, things will be fast enough.
13:28:55
beach
If that is the case, working on what I still consider a special case for LET will be wasted work, and will leave us with more code to maintain.
13:29:31
beach
In the meantime, inlining for other situations than LET still has a performance problem.
13:30:30
Bike
Okay, I don't mind looking at that first. Though I don't think I understand what quadratic performance you mean. From what I could tell, nested lets resulted in a linear amount of copying.
13:31:40
beach
Well, quadratic is not quite true, M*N rather, where M is the nesting depth and N the number of instructions on the average at each level.
13:34:38
Bike
I'm not sure I understand. One thing is that, as far as I can tell, if we inline a function that ENCLOSEs other functions, those other functions have to be copied as well, so that they close over the correct variables.
13:36:20
Bike
For example if we have (let ((x ...)) (let ((y ...)) (+ x y))), inlining outer first results in like (progn (setq xprime ...) (let ((y ...)) (+ xprime y)))
13:38:15
Bike
That going outermost in doesn't reduce the amount of copying since we still have to copy the inner parts.