(bugfix) We thought the previous CL ensured this, but looks like there
were some missing pieces in the genrule & MANIFEST files.
PiperOrigin-RevId: 298715688
Change-Id: Ib0a20cb10fb3b36686419b02c2f8ab6afd438d57
[r2.2:Cherrypick] Reject code containing the for/else pattern, which is not being faithfully converted at the moment. This replaces silently incorrect behavior with a warning. Also whitelist known urllib module.
passed.
For Datasets of unknown sizes, the first epoch will still block on each batch.
However, after the first epoch, the number of steps to run will be known, and
therefore these Datasets will be able to take advantage
of async eager as well.
Also fixes issue where the "steps" argument was not always passed correctly to
Callbacks (tested now in data_adapter_test)
PiperOrigin-RevId: 298728965
Change-Id: I430a6935ffc19718dab1be992f03a637d3ff4584
Also:
* look for xla sources under org_tensorflow
* don't include absl strings:cord since the older version of absl lacks it.
PiperOrigin-RevId: 298638795
Change-Id: Ic85d55240aaa353db60bebea0f0919cbfc5208f1
Also cleans up the LossesContainer and MetricsContainer class to use shared
logic.
PiperOrigin-RevId: 298674749
Change-Id: Iaac04d1038c41b1098c0af711c696350a8d7906f
The separation between ready and non-ready TensorHandleData classes
caused a lot of mirroring logic to get quite messy, especially when
considering the waiting logic, which was duplicated in the main
TensorHandle class and the various TensorHandleData classes. In
addition, having these classes expose the same API was a bit cumbersome
since most APIs were not supported by the various types.
We instead keep simply two different types, a local and remote one.
Further, we move all the waiting logic out of the TensorHandle and have
it in the TensorHandleData. Since we no longer need to swap out the
tensor_handle_data_ pointer when moving to a ready state, we can replace
it with a variant and save ourselves a heap allocation.
The LocalTensorHandleData is optimized such that if a tensor is provided
it does not require mutex synchronization, for any of the member
operations.
The RemoteTensorHandleData no longer needs to support the delicate dance
of calling ReleaseRemoteTensorHandle(). However, for lazy remotes we set
the EagerContext to nullptr to indicate no deletion upon class
destruction is needed.
Along the way we also do the following performance optimizations:
* Change tensor handle construct to use move semantics. This avoids
unnecessary Ref counts on the TensorBuffer.
* In sync, do not allocate empty TensorHandle and later call SetTensor.
Instead, we allocate the return TensorHandles once the kernel has
executed. This avoid the overhead synchronization when there is no
need for it.
* Switch mirror maps to store tensor data direct vs using a unique_ptr.
Also switch to unordered_map.
Additional clean-ups:
* Make TensorHandle APIs consistently take Device pointer as first
argument.
* Remove CreateLocalTensorHandle function which could be confused with
the one used for CustomDevice.
* Remove many unused includes.
PiperOrigin-RevId: 298423283
Change-Id: I838736396e9ef81b2de665d6d9a3ad2062070b0c
The primary changes are:
1. Use the >>> format for code samples. But I couldn't change the code in mixed_precision.py to use the >>> format, since an error is thrown if both the Keras mixed precision API and the graph rewrite API are used in the same process.
2. In the enable_mixed_precision_graph_rewrite docstring, compare the graph rewrite API with the Keras mixed precision API.
3. In the error message that occurs if you try to use both the graph rewrite and the Keras MP API, recommend the Keras API instead of the graph rewrite.
4. Add new sections to Policy docstring: "How a layer users its policy's variable dtype" and "How to write a layer that supports mixed precision and float64". The latter section might be more appropriate for the mixed precision guide, but the guide is already very long and its hard to fit in.
PiperOrigin-RevId: 298419101
Change-Id: I1936e1bcce401d02d4fdeb36b9866eb9cd40c421
Do not store the address of a `const T&`. Storing the address of a `const T&`
means add_argument(42) does not work, which very counter-intuitive.
PiperOrigin-RevId: 298405422
Change-Id: I769dfa8d7dad92b1e73b1a4f591768b4536cca39
