| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The calculation of a spatial coordinate in the kernel and activations is not
dependent on which part of the contracted dimension (input feature) we are in.
Rather than nesting the loops, the loops can be siblings:
- One loop over spatial dimensions
- One loop over the input feature group
This reduces the nesting depth which makes the code a little more readable and
might be slightly faster due work invariant in the spatial loop getting hoisted
out.
PiperOrigin-RevId: 216255839
|
|
|
|
|
|
|
|
| |
was created
with an input_signature.
PiperOrigin-RevId: 216253122
|
|\
| |
| |
| | |
PiperOrigin-RevId: 216253115
|
| |
| |
| |
| | |
PiperOrigin-RevId: 216252980
|
| |
| |
| |
| |
| |
| | |
Add a variant of CustomCall which specifies arbitrary layout constraints on the operands and result. The existing non-layout-constrained CustomCall is changed to have no layout preference and can now be assigned arbitrary layouts by layout assignment.
PiperOrigin-RevId: 216249615
|
| |
| |
| |
| | |
PiperOrigin-RevId: 216248418
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This changes the behavior of randomness-introducing datasets (`tf.data.Dataset.shuffle()`, `tf.data.experimental.shuffle_and_repeat()`, and `tf.data.experimental.RandomDataset`). Previously, when you used the same `tf.data.Dataset` object multiple times in a pipeline (e.g. by zipping two datasets derived from the same randomness-introducing dataset) *and* you did not specify an explicit `seed`, the implementation would choose different non-deterministic seeds for each use of the `Dataset` object.
With this change, the seed will be chosen once per `Dataset` (technically, once per `Dataset`-`Graph` combination, due to the vagaries of capturing state in `Dataset.make_one_shot_iterator()`), which means that all uses of the same dataset object will observe the same sequence of values.
This change also revealed a small bug in how `Dataset.shuffle(..., reshuffle_each_iteration=False)` is serialized when an explicit seed is specified. The op-level seed was dropped, which could lead to non-deterministic behavior. This change fixes that issue by forwarding the op-level seed to the appropriate place.
PiperOrigin-RevId: 216248013
|
| |
| |
| |
| | |
PiperOrigin-RevId: 216247929
|
|\ \
| | |
| | |
| | | |
PiperOrigin-RevId: 216245934
|
|\ \ \
| | | |
| | | |
| | | | |
PiperOrigin-RevId: 216245301
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Doesn't attempt to deal with cases where we might have already generated
the functiondef for the parent function as in that case we cannot easily
modify the forward pass.
PiperOrigin-RevId: 216243224
|
| | | |
| | | |
| | | |
| | | | |
PiperOrigin-RevId: 216242862
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
benchmarking. At the moment, it returns a default config with only Grappler dependency optimizer disabled. Many benchmarks wrap the subgraph they want to time in control_flow_ops.group() to avoid including the overhead of copying the output back to the Python client in the measurement. In the graph, this only adds a control dependency between the subgraph output and the fetch node, which in turn (often) causes the dependency optimizer to turn all nodes in the graph into no-ops.
PiperOrigin-RevId: 216242463
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
sqrt(v + epsilon**2) and changed flag name accordingly.
PiperOrigin-RevId: 216240045
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
mechanism, since the meta optimizer only checks if it has been cancelled before running each sub-optimizer. We can add cancellation to each sub-optimizer if necessary.
PiperOrigin-RevId: 216234262
|
| | | |
| | | |
| | | |
| | | | |
PiperOrigin-RevId: 216230391
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
PiperOrigin-RevId: 216228494
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
must be on axis 0, and can only be on 1 or 2-d inputs.
PiperOrigin-RevId: 216226776
|
| | | | |
| | | | |
| | | | |
| | | | | |
PiperOrigin-RevId: 216225505
|
| | | | |
| | | | |
| | | | |
| | | | | |
PiperOrigin-RevId: 216224026
|
| | | | |
| | | | |
| | | | |
| | | | | |
PiperOrigin-RevId: 216217887
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
PiperOrigin-RevId: 216217509
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
PiperOrigin-RevId: 216212953
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
PiperOrigin-RevId: 216211467
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
existing namespace.
PiperOrigin-RevId: 216211286
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
PiperOrigin-RevId: 216211279
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
PiperOrigin-RevId: 216210141
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
shared resources are very similar to global variables functionally and they are initialized at the same time but since workers are only waiting for global variables being initialized, there is a race condition that sometimes the shared resource is not ready.
PiperOrigin-RevId: 216208679
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Will be helpful for specifying serving signatures when exporting SavedModels
PiperOrigin-RevId: 216207284
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
`MapAndBatchDataset` whose user-provided functions have the property that each output argument take its value directly from an input argument (e.g. `lambda x, y: y, x`). This specialization can produce the result without having to schedule the function using the executor.
PiperOrigin-RevId: 216206232
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
PiperOrigin-RevId: 216205396
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
PiperOrigin-RevId: 216203408
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This benchmark creates many intermediates values, so we can make sure there's no performance overhead (it looks like there might be currently, or it might be from some other difference). It also runs in a defun and in legacy graph mode.
Results from my machine:
entry {
name: "CondWithManyIntermediatesBenchmark.benchmark_cond_v1_defun"
iters: 500
wall_time: 1.25822591782
}
entry {
name: "CondWithManyIntermediatesBenchmark.benchmark_cond_v2_defun"
iters: 500
wall_time: 5.99376106262
}
entry {
name: "CondWithManyIntermediatesBenchmark.benchmark_cond_v1_graph"
iters: 500
wall_time: 2.05277585983
}
entry {
name: "CondWithManyIntermediatesBenchmark.benchmark_cond_v2_graph"
iters: 500
wall_time: 2.84808516502
}
Clearly we have some work to do! I haven't looked into the time differences at all yet.
PiperOrigin-RevId: 216202325
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
PiperOrigin-RevId: 216201732
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
PiperOrigin-RevId: 216201714
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Prior to this change, tf.colocate_with(v) would insert spurious operations (a ReadVariableOp and an Identity) in the graph when v is a resource variable, and then
colocate the operations within the block with those newly added, otherwise disconnected, operations.
This commit avoids adding the unnecessary ReadVariableOp/Identity nodes and colocates
operations within the block with the VarHandleOp.
PiperOrigin-RevId: 216201638
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
PiperOrigin-RevId: 216200439
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
benchmarks.
original runtime: 4.83492736816 secs
w/ cache runtime: 2.19033999443 secs
PiperOrigin-RevId: 216195286
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
PiperOrigin-RevId: 216191084
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
PiperOrigin-RevId: 216189458
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
PiperOrigin-RevId: 216187878
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
PiperOrigin-RevId: 216185979
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
PiperOrigin-RevId: 216151605
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
PiperOrigin-RevId: 216079665
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
PiperOrigin-RevId: 216066634
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
It fails 1/1000 runs in OSS builds.
PiperOrigin-RevId: 216050192
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | | |
PiperOrigin-RevId: 216046506
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
PiperOrigin-RevId: 216041507
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
PiperOrigin-RevId: 216040541
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
PiperOrigin-RevId: 216021117
|