| Commit message (Collapse) | Author | Age |
... | |
|
|
|
| |
PiperOrigin-RevId: 199091580
|
|
|
|
| |
PiperOrigin-RevId: 199072157
|
|
|
|
| |
PiperOrigin-RevId: 199071075
|
|
|
|
|
|
|
|
| |
This CL:
- adds `tf.contrib.data.optimize()` transformation that can be used to trigger rewrite-based optimization for the input pipeline.
- adds `tf.data.Dataset._as_serialized_graph()` method that returns the serialized graph representation of the dataset
PiperOrigin-RevId: 199068055
|
|
|
|
|
|
|
|
|
| |
- Make nn_api a delegate in its own directory.
- Use the delegate API to rewrite the graph.
- Use only on static APIs right now.
- This is initial preview of the delegate that only supports add and conv.
PiperOrigin-RevId: 199055747
|
|
|
|
|
|
|
| |
XLA cannot implement the forward-tensor-ref semantic -- there is no guaranteed
aliasing between the input and output of the XLA cluster.
PiperOrigin-RevId: 199005227
|
|
|
|
| |
PiperOrigin-RevId: 199001807
|
|
|
|
| |
PiperOrigin-RevId: 198963930
|
|
|
|
|
|
| |
Finds float weight tensors, quantizes them to 8 bits, and adds Dequantize operations after them.
PiperOrigin-RevId: 198955123
|
|
|
|
|
|
| |
Also forcing reduction order for init to be on lhs for ReduceWindow->Map pass.
PiperOrigin-RevId: 198953817
|
|
|
|
| |
PiperOrigin-RevId: 198953044
|
|
|
|
|
|
| |
absl is not yet ready for use by open source TensorFlow. :-(
PiperOrigin-RevId: 198952953
|
|
|
|
| |
PiperOrigin-RevId: 198949796
|
|
|
|
| |
PiperOrigin-RevId: 198948296
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the InnerMostDimReducer to use a summation tree, which is more numerically stable than the previous approach of sequential addition into an accumulator.
This solves the issue for reduction over all or a trailing subset of dimensions.
This change does not improve the numerical accuracy for MeanReducer, which maintains state.
Benchmarks show a 40% (AVX) to 50% (SSE) slowdown for small row reductions (sum, float). column- and full reductions are unchanged.
Cleaned up TensorFunctors.h a bit by moving the traits to reducer_traits and updating the code that uses the reducers accordingly.
Introduced a new trait "IsExactlyAssociative" and new template specializations of InnerMostDimReducer to ensure that we only invoke the new and slightly more expensive codepath when it is needed, i.e. for sum reduction of non-integer types.
PiperOrigin-RevId: 198946075
|
|
|
|
|
|
| |
TPUEstimator.export_output().
PiperOrigin-RevId: 198944144
|
|
|
|
| |
PiperOrigin-RevId: 198943559
|
|
|
|
| |
PiperOrigin-RevId: 198942995
|
|
|
|
| |
PiperOrigin-RevId: 198941362
|
|
|
|
|
|
|
|
| |
o This has a couple of important advantages over the current implementation:
1. The existing batch-op waits for the batch to be created and then forwards the tensors to the rest of the graph, which causes a lot of batches to be created, because there is no way for the op to know if the other batches are being queued up. A mitigation, which we have seen working in practice, is to actually wait for the graph to finish processing the batch. So there is a sort of flow-control happening, and meanwhile the batches get coalesced, which improves latency and throughput as well. Using functions makes this kind of approach easier.
2. The existing op passes empty tensors around the graph to make the TF executor happy, which has sometimes worked not well with some Ops (like Reshape). Using functions means that we don't need to rely on this mechanism as well.
PiperOrigin-RevId: 198937594
|
|
|
|
|
|
|
| |
Update ecosystem page and dropdown menu.
Remove community/swift page and add redirect.
PiperOrigin-RevId: 198936463
|
|
|
|
|
|
|
|
| |
Now that we're using the parser inside of xla/service, it's awkward for
it to live inside of xla/tools, because everything else in there is a
standalone tool. We've already had one person be confused by this.
PiperOrigin-RevId: 198935921
|
|
|
|
| |
PiperOrigin-RevId: 198935499
|
|
|
|
|
|
| |
the XLA local Python client.
PiperOrigin-RevId: 198930874
|
|
|
|
|
|
| |
function to leverage GEMM optimizations.
PiperOrigin-RevId: 198924313
|
|
|
|
| |
PiperOrigin-RevId: 198922037
|
|
|
|
| |
PiperOrigin-RevId: 198921960
|
|
|
|
|
|
|
|
|
|
| |
accurately reflect the operator?s mathematical properties and make it familiar to TensorFlow users. Currently the deprecation is a warning - when we update tensorflow/swift-models, I'll start another CL to remove it completely.
Previously `dot` was chosen over `matmul` because of naming convention concerns (acronyms aren?t common in Swift) and that we wanted to make it short (so full names like `a.matrixMultiplied(by: b)` isn?t acceptable). Beyond these concerns, `matmul` is really a word of art and thus should be preferred.
The ? operator often denotes outer product and Kronecker product. So it's removed, too.
PiperOrigin-RevId: 198920621
|
|
|
|
| |
PiperOrigin-RevId: 198919964
|
|
|
|
| |
PiperOrigin-RevId: 198913026
|
|
|
|
|
|
| |
computations. Add an additional test.
PiperOrigin-RevId: 198908904
|
|
|
|
| |
PiperOrigin-RevId: 198906281
|
|
|
|
|
|
| |
indpendently.
PiperOrigin-RevId: 198902279
|
|
|
|
| |
PiperOrigin-RevId: 198897530
|
|
|
|
| |
PiperOrigin-RevId: 198894470
|
|
|
|
|
|
| |
compatibility.
PiperOrigin-RevId: 198893078
|
|
|
|
|
|
|
| |
When implementing a custom layer, it's necessary to call the Layer constructor
from the custom layer's constructor.
PiperOrigin-RevId: 198892503
|
|
|
|
|
|
| |
edges to a single node from the same source device. Instead, build an intermediate NoOp node on the source device and use a single cross-device control edge.
PiperOrigin-RevId: 198891614
|
|
|
|
| |
PiperOrigin-RevId: 198887868
|
|
|
|
| |
PiperOrigin-RevId: 198886485
|
|
|
|
| |
PiperOrigin-RevId: 198880096
|
|
|
|
| |
PiperOrigin-RevId: 198878259
|
|
|
|
| |
PiperOrigin-RevId: 198876135
|
|
|
|
|
|
| |
reduce_{sum,prod,etc}
PiperOrigin-RevId: 198874465
|
|
|
|
|
|
| |
include the cuDNN header file.
PiperOrigin-RevId: 198869605
|
|
|
|
| |
PiperOrigin-RevId: 198863091
|
|
|
|
|
|
| |
optonly due to flakiness.
PiperOrigin-RevId: 198862313
|
|
|
|
| |
PiperOrigin-RevId: 198859282
|
|
|
|
| |
PiperOrigin-RevId: 198850955
|
|
|
|
|
|
| |
For large constants, creating an llvm::Constant for each element can get prohibitively large compile times.
PiperOrigin-RevId: 198843141
|