commit | d35e45995db03cd361fd0e82a3ee62f93b33e49d | [log] [tgz] |
---|---|---|
author | George Karpenkov <cheshire@google.com> | Tue Jul 14 12:11:56 2020 -0700 |
committer | TensorFlower Gardener <gardener@tensorflow.org> | Tue Jul 14 12:16:14 2020 -0700 |
tree | c3f475206b00b0a1a14705bb5d7e31baf4d2a02a | |
parent | 452b4d88d929daba8f0610af7fc3b3c14b8be496 [diff] |
[TF/XLA] Enable input/output aliasing in the TF2XLA bridge The change required multiple components: 1) Switching to a different client API which takes a span of `ExecutionInput`s (so that the buffer donation can be specified at runtime). 2) Propagating the flag to set up aliasing for resource variables. 3) Checking the reference count of updated resource variables, and transferring the ownership at runtime if the count is one, and the aliasing specified in the compiled module. In order to do (3), we've needed to transfer from the model where we take a snapshot of reference variables before the execution (and locking only for the duration of the snapshotting) to locking the reference variables for the entire compile+run cycle (only doable from XlaLocalLaunchBase) and instead of taking the snapshot (requiring a copy) propagating the map to the pointers of tensors associated with reference variables. Testing: currently, testing was only done by inspecting the log traces manually, and checking that the buffer was donated, the aliasing was specified at the compile time, and the copy-protection only kicked in in cases where it needed to. In the future, we need to: 1) Test HLO generated from `tf.function(experimental_compile=True)` 2) Find a way to test the exact number of allocations generated during the test. PiperOrigin-RevId: 321207626 Change-Id: I1003f90479d0f8d3cffb8aaf48b746aa1526535d
Documentation |
---|
TensorFlow is an end-to-end open source platform for machine learning. It has a comprehensive, flexible ecosystem of tools, libraries, and community resources that lets researchers push the state-of-the-art in ML and developers easily build and deploy ML-powered applications.
TensorFlow was originally developed by researchers and engineers working on the Google Brain team within Google's Machine Intelligence Research organization to conduct machine learning and deep neural networks research. The system is general enough to be applicable in a wide variety of other domains, as well.
TensorFlow provides stable Python and C++ APIs, as well as non-guaranteed backward compatible API for other languages.
Keep up-to-date with release announcements and security updates by subscribing to announce@tensorflow.org. See all the mailing lists.
See the TensorFlow install guide for the pip package, to enable GPU support, use a Docker container, and build from source.
To install the current release, which includes support for CUDA-enabled GPU cards (Ubuntu and Windows):
$ pip install tensorflow
A smaller CPU-only package is also available:
$ pip install tensorflow-cpu
To update TensorFlow to the latest version, add --upgrade
flag to the above commands.
Nightly binaries are available for testing using the tf-nightly and tf-nightly-cpu packages on PyPi.
$ python
>>> import tensorflow as tf >>> tf.add(1, 2).numpy() 3 >>> hello = tf.constant('Hello, TensorFlow!') >>> hello.numpy() b'Hello, TensorFlow!'
For more examples, see the TensorFlow tutorials.
If you want to contribute to TensorFlow, be sure to review the contribution guidelines. This project adheres to TensorFlow's code of conduct. By participating, you are expected to uphold this code.
We use GitHub issues for tracking requests and bugs, please see TensorFlow Discuss for general questions and discussion, and please direct specific questions to Stack Overflow.
The TensorFlow project strives to abide by generally accepted best practices in open-source software development:
Build Type | Status | Artifacts |
---|---|---|
Linux CPU | PyPI | |
Linux GPU | PyPI | |
Linux XLA | TBA | |
macOS | PyPI | |
Windows CPU | PyPI | |
Windows GPU | PyPI | |
Android | ||
Raspberry Pi 0 and 1 | Py3 | |
Raspberry Pi 2 and 3 | Py3 | |
Libtensorflow MacOS CPU | GCS | |
Libtensorflow Linux CPU | GCS | |
Libtensorflow Linux GPU | GCS | |
Libtensorflow Windows CPU | GCS | |
Libtensorflow Windows GPU | GCS |
Build Type | Status | Artifacts |
---|---|---|
Linux AMD ROCm GPU Nightly | Nightly | |
Linux AMD ROCm GPU Stable Release | Release 1.15 / 2.x | |
Linux s390x Nightly | Nightly | |
Linux s390x CPU Stable Release | Release | |
Linux ppc64le CPU Nightly | Nightly | |
Linux ppc64le CPU Stable Release | Release 1.15 / 2.x | |
Linux ppc64le GPU Nightly | Nightly | |
Linux ppc64le GPU Stable Release | Release 1.15 / 2.x | |
Linux aarch64 CPU Nightly Python 3.6 | Nightly | |
Linux CPU with Intel oneAPI Deep Neural Network Library (oneDNN) Nightly | Nightly | |
Linux CPU with Intel oneAPI Deep Neural Network Library (oneDNN) Stable Release | Release 1.15 / 2.x | |
Red Hat® Enterprise Linux® 7.6 CPU & GPU Python 2.7, 3.6 | 1.13.1 PyPI |
Learn more about the TensorFlow community and how to contribute.