Fixes#40758. Go map iteration order is random. If we send randomly ordered lists of inputs to the C core it will create a key in the session executors_ cache for each of the random orderings. With more than a handful of inputs this can get big very quickly.
I pull the logic to convert a *C.TF_DeviceList to a []Device into its own function `deviceSliceFromDeviceList`. This is so I can reuse it when wrapping the Eager C API.
PiperOrigin-RevId: 225344064
A Session is configured using the ConfigProto protocol buffer.
For now, continuing with attempts to keep the 'tensorflow' go package
free of any protocol buffer dependencies, SessionOptions uses a serialized
representation of this message. This choice might make sense to revisit.
Change: 148750535
Prior to this change, TF_*Run, TF_SetAttrTensor and TF_SetAttrTensorList
took ownership of the TF_Tensor*s of the feeds. This can make performance
client languages bothersome when the same Tensor is repeatedly fed into
multiple session executions as the memory for the feed tensor would need
to be re-allocated and filled in every time.
With this change, these functions no longer take ownership of the
TF_Tensor*.
The changes to the Go API implementation reflect the claimed benefits.
(Another step towards #10)
Change: 139169388
This makes the preferred API for graph construction and
execution have the simpler, more sensible names (TF_Session,
TF_NewSession etc.) and the older one which we hope to
eventually remove have the more awkward ones (TF_DeprecatedSession,
TF_NewDeprecatedSession etc.)
Change: 138641615
Add an example (that will appear in Go doc) for a real use of the Go TensorFlow
APIs - using a pre-defined image recognition model for inference.
While at it a couple of minor tweaks:
- NewSession now accepts 'nil' for options as the documentation says it does
- Convenience accessors for the Outputs of an Operation
- Ability to extract (possibly partial) shapes from an Output
Another step towards #10
Change: 134560938
