tfp.experimental.auto_batching.allocation_strategy.optimize
Stay organized with collections
Save and categorize content based on your preferences.
Optimizes a Program
's variable allocation strategy.
tfp.experimental.auto_batching.allocation_strategy.optimize(
program
)
The variable allocation strategies determine how much memory the Program
consumes, and how costly its memory access operations are (see
instructions.VariableAllocation
). In general, a variable holding data with
a longer or more complex lifetime will need a more expensive storage strategy.
This analysis examines variables' liveness and opportunistically selects
inexpensive sound allocation strategies.
Specifically, the algorithm is to:
- Run liveness analysis to determine the lifespan of each variable.
- Assume optimistically that no variable needs to be stored at all
(
instructions.VariableAllocation.NULL
).
- Traverse the instructions and pattern-match conditions that require
some storage:
- If a variable is read by an instruction, it must be at least
instructions.VariableAllocation.TEMPORARY
.
- If a variable is live out of some block (i.e., crosses a block boundary),
it must be at least
instructions.VariableAllocation.REGISTER
. This is
because temporaries do not appear in the loop state in execute
.
- If a variable is alive across a call to an autobatched
Function
, it must
be instructions.VariableAllocation.FULL
, because that Function
may
push values to it that must not overwrite the value present at the call
point. (This can be improved by examining the call graph to see whether
the callee really does push values to this variable, but that's future
work.)
Args |
program
|
Program to optimize.
|
Returns |
program
|
A newly allocated Program with the same semantics but possibly
different allocation strategies for some (or all) variables. Each new
strategy may be more efficient than the input Program 's allocation
strategy for that variable (if the analysis can prove it safe), but will
not be less efficient.
|
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2023-11-21 UTC.
[null,null,["Last updated 2023-11-21 UTC."],[],[],null,["# tfp.experimental.auto_batching.allocation_strategy.optimize\n\n\u003cbr /\u003e\n\n|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| [View source on GitHub](https://github.com/tensorflow/probability/blob/v0.23.0/tensorflow_probability/python/experimental/auto_batching/allocation_strategy.py#L36-L91) |\n\nOptimizes a `Program`'s variable allocation strategy.\n\n#### View aliases\n\n\n**Main aliases**\n\n[`tfp.experimental.auto_batching.frontend.allocation_strategy.optimize`](https://www.tensorflow.org/probability/api_docs/python/tfp/experimental/auto_batching/allocation_strategy/optimize)\n\n\u003cbr /\u003e\n\n tfp.experimental.auto_batching.allocation_strategy.optimize(\n program\n )\n\nThe variable allocation strategies determine how much memory the `Program`\nconsumes, and how costly its memory access operations are (see\n[`instructions.VariableAllocation`](../../../../tfp/experimental/auto_batching/instructions/VariableAllocation)). In general, a variable holding data with\na longer or more complex lifetime will need a more expensive storage strategy.\nThis analysis examines variables' liveness and opportunistically selects\ninexpensive sound allocation strategies.\n\nSpecifically, the algorithm is to:\n\n- Run liveness analysis to determine the lifespan of each variable.\n- Assume optimistically that no variable needs to be stored at all ([`instructions.VariableAllocation.NULL`](../../../../tfp/experimental/auto_batching/instructions/VariableAllocation#NULL)).\n- Traverse the instructions and pattern-match conditions that require some storage:\n - If a variable is read by an instruction, it must be at least [`instructions.VariableAllocation.TEMPORARY`](../../../../tfp/experimental/auto_batching/instructions/VariableAllocation#TEMPORARY).\n - If a variable is live out of some block (i.e., crosses a block boundary), it must be at least [`instructions.VariableAllocation.REGISTER`](../../../../tfp/experimental/auto_batching/instructions/VariableAllocation#REGISTER). This is because temporaries do not appear in the loop state in `execute`.\n - If a variable is alive across a call to an autobatched `Function`, it must be [`instructions.VariableAllocation.FULL`](../../../../tfp/experimental/auto_batching/instructions/VariableAllocation#FULL), because that `Function` may push values to it that must not overwrite the value present at the call point. (This can be improved by examining the call graph to see whether the callee really does push values to this variable, but that's future work.)\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n| Args ---- ||\n|-----------|------------------------|\n| `program` | `Program` to optimize. |\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n| Returns ------- ||\n|-----------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `program` | A newly allocated `Program` with the same semantics but possibly different allocation strategies for some (or all) variables. Each new strategy may be more efficient than the input `Program`'s allocation strategy for that variable (if the analysis can prove it safe), but will not be less efficient. |\n\n\u003cbr /\u003e"]]