note about tail call optimization in relevance to solving problems recursiively
This commit is contained in:
parent
5663e07456
commit
447d7a3971
@ -4,7 +4,7 @@
|
|||||||
> Take a large problem
|
> Take a large problem
|
||||||
> Break it up
|
> Break it up
|
||||||
> Solve the pieces
|
> Solve the pieces
|
||||||
/lecture
|
|
||||||
|
|
||||||
|
|
||||||
# Definitions
|
# Definitions
|
||||||
@ -16,3 +16,38 @@ _Recursive dynamic programming_
|
|||||||
_Tabulation_
|
_Tabulation_
|
||||||
: Bottom up approach
|
: Bottom up approach
|
||||||
: Go from little problems and build up
|
: Go from little problems and build up
|
||||||
|
|
||||||
|
|
||||||
|
# Recursive compiler tricks
|
||||||
|
|
||||||
|
Normal iterative:
|
||||||
|
```
|
||||||
|
start:
|
||||||
|
...
|
||||||
|
jcond start
|
||||||
|
```
|
||||||
|
|
||||||
|
Normal recursion(under non-priveleged procs):
|
||||||
|
|
||||||
|
Each "iteration" creates a new frame of whatever size:
|
||||||
|
hence we approach the hard stack limit
|
||||||
|
|
||||||
|
_Sick guess_:
|
||||||
|
```
|
||||||
|
At compile we should be able to predict an incoming iteration from a
|
||||||
|
recusive endpoint.
|
||||||
|
|
||||||
|
? is it just parameterized jumps ?
|
||||||
|
```
|
||||||
|
|
||||||
|
_Answer:_
|
||||||
|
```
|
||||||
|
Tail recusion optimization
|
||||||
|
|
||||||
|
Takes the last statement of function
|
||||||
|
Assuming its a recursive call, we can replace our current stack frame's arguments
|
||||||
|
The only state that changes between calls then is just the arguments
|
||||||
|
```
|
||||||
|
In this sense we are turning a recusive functino into an iterative one because the whole state is held in one frame & we only ever jump within our routines address space.
|
||||||
|
|
||||||
|
However, this tail optimization can only happen at the tail of a routine.
|
||||||
|
Loading…
Reference in New Issue
Block a user