| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
* use nullptr
* converting integer literal to bool, use bool literal instead
* annotate this function with 'override' or (rarely) 'final'
* prefer using 'override' or (rarely) 'final' instead of 'virtual'
PiperOrigin-RevId: 196441181
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A recent change modified the behavior of `FunctionLibraryRuntimeImpl::ReleaseHandle()`
so that it no longer freed the memory associated with an instantiated function. Since
we rely on instantiating and releasing a potentially large number of instances of the
same function in tf.data to isolate the (e.g. random number generator) state in each
instance, this change meant that the memory consumption could grow without bound in
a simple program like:
```python
ds = tf.data.Dataset.from_tensors(0).repeat(None)
# The function `lambda y: y + 1` would be instantiated for each element in the input.
ds = ds.flat_map(lambda x: tf.data.Dataset.from_tensors(x).map(
lambda y: y + tf.random_uniform([], minval=0, maxval=10, dtype=tf.int32)))
iterator = ds.make_one_shot_iterator()
next_elem = iterator.get_next()
with tf.Session() as sess:
while True:
sess.run(next_elem)
```
PiperOrigin-RevId: 195983977
|
|
|
|
| |
PiperOrigin-RevId: 193843055
|
|
|
|
|
|
|
|
| |
tensorflow::str_util equivalents.
This will allow the deprecated methods to be removed.
PiperOrigin-RevId: 191316903
|
|
|
|
|
|
|
|
| |
runner to execute kernels with. In that case, it defaults to using the threadpool provided by the device.
Also makes sure each device has a default threadpool to fall back on.
PiperOrigin-RevId: 188520648
|
|
|
|
|
|
|
| |
distributed (ClusterFLR) case. As a result multiple instantiations for the same
function were happening.
PiperOrigin-RevId: 188411978
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This option makes it possible to instantiate functions from a library
that has been loaded separately from the runtime's own library. We
plan to use this as part of the `tf.data` checkpoint restore process,
which might load an iterator whose state includes functions that
aren't present in the original graph. (This is currently achieved by
creating an isolated `FunctionLibraryRuntime` for each function-using
`Dataset`, but that is inefficient and prevents using features of the
main runtime, such as cross-device function calls.)
PiperOrigin-RevId: 181352217
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new struct allows optional arguments to be passed to the
`FunctionLibraryRuntime::Instantiate()` API. The new struct is now
used to configure the target device for a function instantiation
(instead of an attr).
This version fixes an issue in the previous attempt whereby identical
functions instantiated on different devices in the same task would be
canonicalized to the same key and hence receive the same handle in the
ProcFLR, but they would only be instantiated locally in one per-device
FLR. The fix ensures that the device name is part of the canonicalized
form. A test is added to function_test.py that failed with the old
version and passed in the new version.
END_PUBLIC
BEGIN_PUBLIC
Automated g4 rollback of changelist 180979141
PiperOrigin-RevId: 181003413
|
|
|
|
| |
PiperOrigin-RevId: 180979141
|
|
|
|
|
|
|
|
|
| |
This new struct allows optional arguments to be passed to the
`FunctionLibraryRuntime::Instantiate()` API. The new struct is now
used to configure the target device for a function instantiation
(instead of an attr).
PiperOrigin-RevId: 180848930
|
|
|
|
|
|
|
|
| |
allows for releasing the state associated with the handle.
Also simplifies the state owned by the FunctionLibraryRuntimeImpl. Instead of having a vector of ref counted Item objects and a separate vector of function bodies, we merge it into one object that holds the entire instantiated state for the function.
PiperOrigin-RevId: 177639560
|
|
|
|
|
|
| |
remote target as /device:CPU:0 or /device:GPU:0 etc.
PiperOrigin-RevId: 174252575
|
|
|
|
|
|
|
|
| |
making all the device factories produce the new device names.
The python API would still support the legacy /<type>:<index> format so the C++ layer would accept both legacy and standardized names but the C++ layer would produce only new device names now.
PiperOrigin-RevId: 170758313
|
|
|
|
|
|
| |
only works for processes running on CPU's only.
PiperOrigin-RevId: 170725482
|
|
|
|
|
|
| |
Recv's is set correctly.
PiperOrigin-RevId: 168635306
|
|
|
|
|
|
| |
remote execution. This enables CPU->GPU remote device executions now.
PiperOrigin-RevId: 168038285
|
|
|
|
|
|
|
|
| |
ProcessFunctionLibraryRuntime library to Instantiate and Run functions on different devices. When a FunctionLibraryRuntime encounters a function with a target that is another device, it delegates Instantiate() and Run() calls to the ProcessFunctionLibraryRuntime.
This change also moves the table_ containing all function instantiations to the PFLR instead of the FunctionLibraryRuntime.
PiperOrigin-RevId: 165651194
|
|
|
|
| |
PiperOrigin-RevId: 165604864
|
|
|
|
|
|
|
|
| |
ProcessFunctionLibraryRuntime library to Instantiate and Run functions on different devices. When a FunctionLibraryRuntime encounters a function with a target that is another device, it delegates Instantiate() and Run() calls to the ProcessFunctionLibraryRuntime.
This change also moves the table_ containing all function instantiations to the PFLR instead of the FunctionLibraryRuntime.
PiperOrigin-RevId: 165521057
|
|
FunctionLibraryRuntime (FLR) objects, one per device.
This change makes sure that we create FLR objects for each device, regardless of whether we have that device in the pruned graph. This is necessary for cross device (intra-process) function execution in which its possible to have a graph only present on one device (post-pruning) that wants to execute a function on another device.
PiperOrigin-RevId: 164180464
|