ConfigProto.Builder

 When any filters are present sessions will ignore all devices which do not
 match the filters. Each filter can be partially specified, e.g. "/job:ps"
 "/job:worker/replica:3", etc.
 

 This option is experimental - it may be replaced with a different mechanism
 in the future.
 Configures session thread pools. If this is configured, then RunOptions for
 a Run call can select the thread pool to use.
 The intended use is for when some session invocations need to run in a
 background pool limited to a small number of threads:
 - For example, a session may be configured to have one large pool (for
 regular compute) and one small pool (for periodic, low priority work);
 using the small pool is currently the mechanism for limiting the inter-op
 parallelism of the low priority work.  Note that it does not limit the
 parallelism of work spawned by a single op kernel implementation.
 - Using this setting is normally not needed in training, but may help some
 serving use cases.
 - It is also generally recommended to set the global_name field of this
 proto, to avoid creating multiple large pools. It is typically better to
 run the non-low-priority work, even across sessions, in a single large
 pool.
 

 When any filters are present sessions will ignore all devices which do not
 match the filters. Each filter can be partially specified, e.g. "/job:ps"
 "/job:worker/replica:3", etc.
 

 When any filters are present sessions will ignore all devices which do not
 match the filters. Each filter can be partially specified, e.g. "/job:ps"
 "/job:worker/replica:3", etc.
 

 This option is experimental - it may be replaced with a different mechanism
 in the future.
 Configures session thread pools. If this is configured, then RunOptions for
 a Run call can select the thread pool to use.
 The intended use is for when some session invocations need to run in a
 background pool limited to a small number of threads:
 - For example, a session may be configured to have one large pool (for
 regular compute) and one small pool (for periodic, low priority work);
 using the small pool is currently the mechanism for limiting the inter-op
 parallelism of the low priority work.  Note that it does not limit the
 parallelism of work spawned by a single op kernel implementation.
 - Using this setting is normally not needed in training, but may help some
 serving use cases.
 - It is also generally recommended to set the global_name field of this
 proto, to avoid creating multiple large pools. It is typically better to
 run the non-low-priority work, even across sessions, in a single large
 pool.
 

 This option is experimental - it may be replaced with a different mechanism
 in the future.
 Configures session thread pools. If this is configured, then RunOptions for
 a Run call can select the thread pool to use.
 The intended use is for when some session invocations need to run in a
 background pool limited to a small number of threads:
 - For example, a session may be configured to have one large pool (for
 regular compute) and one small pool (for periodic, low priority work);
 using the small pool is currently the mechanism for limiting the inter-op
 parallelism of the low priority work.  Note that it does not limit the
 parallelism of work spawned by a single op kernel implementation.
 - Using this setting is normally not needed in training, but may help some
 serving use cases.
 - It is also generally recommended to set the global_name field of this
 proto, to avoid creating multiple large pools. It is typically better to
 run the non-low-priority work, even across sessions, in a single large
 pool.
 

 This option is experimental - it may be replaced with a different mechanism
 in the future.
 Configures session thread pools. If this is configured, then RunOptions for
 a Run call can select the thread pool to use.
 The intended use is for when some session invocations need to run in a
 background pool limited to a small number of threads:
 - For example, a session may be configured to have one large pool (for
 regular compute) and one small pool (for periodic, low priority work);
 using the small pool is currently the mechanism for limiting the inter-op
 parallelism of the low priority work.  Note that it does not limit the
 parallelism of work spawned by a single op kernel implementation.
 - Using this setting is normally not needed in training, but may help some
 serving use cases.
 - It is also generally recommended to set the global_name field of this
 proto, to avoid creating multiple large pools. It is typically better to
 run the non-low-priority work, even across sessions, in a single large
 pool.
 

 This option is experimental - it may be replaced with a different mechanism
 in the future.
 Configures session thread pools. If this is configured, then RunOptions for
 a Run call can select the thread pool to use.
 The intended use is for when some session invocations need to run in a
 background pool limited to a small number of threads:
 - For example, a session may be configured to have one large pool (for
 regular compute) and one small pool (for periodic, low priority work);
 using the small pool is currently the mechanism for limiting the inter-op
 parallelism of the low priority work.  Note that it does not limit the
 parallelism of work spawned by a single op kernel implementation.
 - Using this setting is normally not needed in training, but may help some
 serving use cases.
 - It is also generally recommended to set the global_name field of this
 proto, to avoid creating multiple large pools. It is typically better to
 run the non-low-priority work, even across sessions, in a single large
 pool.
 

 This option is experimental - it may be replaced with a different mechanism
 in the future.
 Configures session thread pools. If this is configured, then RunOptions for
 a Run call can select the thread pool to use.
 The intended use is for when some session invocations need to run in a
 background pool limited to a small number of threads:
 - For example, a session may be configured to have one large pool (for
 regular compute) and one small pool (for periodic, low priority work);
 using the small pool is currently the mechanism for limiting the inter-op
 parallelism of the low priority work.  Note that it does not limit the
 parallelism of work spawned by a single op kernel implementation.
 - Using this setting is normally not needed in training, but may help some
 serving use cases.
 - It is also generally recommended to set the global_name field of this
 proto, to avoid creating multiple large pools. It is typically better to
 run the non-low-priority work, even across sessions, in a single large
 pool.
 

 This option is experimental - it may be replaced with a different mechanism
 in the future.
 Configures session thread pools. If this is configured, then RunOptions for
 a Run call can select the thread pool to use.
 The intended use is for when some session invocations need to run in a
 background pool limited to a small number of threads:
 - For example, a session may be configured to have one large pool (for
 regular compute) and one small pool (for periodic, low priority work);
 using the small pool is currently the mechanism for limiting the inter-op
 parallelism of the low priority work.  Note that it does not limit the
 parallelism of work spawned by a single op kernel implementation.
 - Using this setting is normally not needed in training, but may help some
 serving use cases.
 - It is also generally recommended to set the global_name field of this
 proto, to avoid creating multiple large pools. It is typically better to
 run the non-low-priority work, even across sessions, in a single large
 pool.
 

 Whether soft placement is allowed. If allow_soft_placement is true,
 an op will be placed on CPU if
   1. there's no GPU implementation for the OP
 or
   2. no GPU devices are known or registered
 or
   3. need to co-locate with reftype input(s) which are from CPU.
 

 Optional list of all workers to use in this session.
 

 When any filters are present sessions will ignore all devices which do not
 match the filters. Each filter can be partially specified, e.g. "/job:ps"
 "/job:worker/replica:3", etc.
 

 Options that apply to all GPUs.
 

 Options that apply to all graphs.
 

 Nodes that perform blocking operations are enqueued on a pool of
 inter_op_parallelism_threads available in each process.
 0 means the system picks an appropriate number.
 Negative means all operations are performed in caller's thread.
 Note that the first Session created in the process sets the
 number of threads for all future sessions unless use_per_session_threads is
 true or session_inter_op_thread_pool is configured.
 

 The execution of an individual op (for some op types) can be
 parallelized on a pool of intra_op_parallelism_threads.
 0 means the system picks an appropriate number.
 If you create an ordinary session, e.g., from Python or C++,
 then there is exactly one intra op thread pool per process.
 The first session created determines the number of threads in this pool.
 All subsequent sessions reuse/share this one global pool.
 There are notable exceptions to the default behavior describe above:
 1. There is an environment variable  for overriding this thread pool,
    named TF_OVERRIDE_GLOBAL_THREADPOOL.
 2. When connecting to a server, such as a remote `tf.train.Server`
    instance, then this option will be ignored altogether.
 

 If true, any resources such as Variables used in the session will not be
 shared with other sessions. However, when clusterspec propagation is
 enabled, this field is ignored and sessions are always isolated.
 

 Whether device placements should be logged.
 

 Global timeout for all blocking operations in this session.  If non-zero,
 and not overridden on a per-operation basis, this value will be used as the
 deadline for all blocking operations.
 

 Assignment of Nodes to Devices is recomputed every placement_period
 steps until the system warms up (at which point the recomputation
 typically slows down automatically).
 

 Options that apply when this session uses the distributed runtime.
 

 This option is experimental - it may be replaced with a different mechanism
 in the future.
 Configures session thread pools. If this is configured, then RunOptions for
 a Run call can select the thread pool to use.
 The intended use is for when some session invocations need to run in a
 background pool limited to a small number of threads:
 - For example, a session may be configured to have one large pool (for
 regular compute) and one small pool (for periodic, low priority work);
 using the small pool is currently the mechanism for limiting the inter-op
 parallelism of the low priority work.  Note that it does not limit the
 parallelism of work spawned by a single op kernel implementation.
 - Using this setting is normally not needed in training, but may help some
 serving use cases.
 - It is also generally recommended to set the global_name field of this
 proto, to avoid creating multiple large pools. It is typically better to
 run the non-low-priority work, even across sessions, in a single large
 pool.
 

 When true, WorkerSessions are created with device attributes from the
 full cluster.
 This is helpful when a worker wants to partition a graph
 (for example during a PartitionedCallOp).
 

 If true, use a new set of threads for this session rather than the global
 pool of threads. Only supported by direct sessions.
 If false, use the global threads created by the first session, or the
 per-session thread pools configured by session_inter_op_thread_pool.
 This option is deprecated. The same effect can be achieved by setting
 session_inter_op_thread_pool to have one element, whose num_threads equals
 inter_op_parallelism_threads.
 

 Map from device type name (e.g., "CPU" or "GPU" ) to maximum
 number of devices of that type to use.  If a particular device
 type is not found in the map, the system picks an appropriate
 number.
 

 Whether soft placement is allowed. If allow_soft_placement is true,
 an op will be placed on CPU if
   1. there's no GPU implementation for the OP
 or
   2. no GPU devices are known or registered
 or
   3. need to co-locate with reftype input(s) which are from CPU.
 

 Optional list of all workers to use in this session.
 

 Optional list of all workers to use in this session.
 

 Optional list of all workers to use in this session.
 

 Map from device type name (e.g., "CPU" or "GPU" ) to maximum
 number of devices of that type to use.  If a particular device
 type is not found in the map, the system picks an appropriate
 number.
 

 Map from device type name (e.g., "CPU" or "GPU" ) to maximum
 number of devices of that type to use.  If a particular device
 type is not found in the map, the system picks an appropriate
 number.
 

 Map from device type name (e.g., "CPU" or "GPU" ) to maximum
 number of devices of that type to use.  If a particular device
 type is not found in the map, the system picks an appropriate
 number.
 

 Map from device type name (e.g., "CPU" or "GPU" ) to maximum
 number of devices of that type to use.  If a particular device
 type is not found in the map, the system picks an appropriate
 number.
 

 When any filters are present sessions will ignore all devices which do not
 match the filters. Each filter can be partially specified, e.g. "/job:ps"
 "/job:worker/replica:3", etc.
 

 When any filters are present sessions will ignore all devices which do not
 match the filters. Each filter can be partially specified, e.g. "/job:ps"
 "/job:worker/replica:3", etc.
 

 When any filters are present sessions will ignore all devices which do not
 match the filters. Each filter can be partially specified, e.g. "/job:ps"
 "/job:worker/replica:3", etc.
 

 When any filters are present sessions will ignore all devices which do not
 match the filters. Each filter can be partially specified, e.g. "/job:ps"
 "/job:worker/replica:3", etc.
 

 Options that apply to all GPUs.
 

 Options that apply to all GPUs.
 

 Options that apply to all GPUs.
 

 Options that apply to all graphs.
 

 Options that apply to all graphs.
 

 Options that apply to all graphs.
 

 Nodes that perform blocking operations are enqueued on a pool of
 inter_op_parallelism_threads available in each process.
 0 means the system picks an appropriate number.
 Negative means all operations are performed in caller's thread.
 Note that the first Session created in the process sets the
 number of threads for all future sessions unless use_per_session_threads is
 true or session_inter_op_thread_pool is configured.
 

 The execution of an individual op (for some op types) can be
 parallelized on a pool of intra_op_parallelism_threads.
 0 means the system picks an appropriate number.
 If you create an ordinary session, e.g., from Python or C++,
 then there is exactly one intra op thread pool per process.
 The first session created determines the number of threads in this pool.
 All subsequent sessions reuse/share this one global pool.
 There are notable exceptions to the default behavior describe above:
 1. There is an environment variable  for overriding this thread pool,
    named TF_OVERRIDE_GLOBAL_THREADPOOL.
 2. When connecting to a server, such as a remote `tf.train.Server`
    instance, then this option will be ignored altogether.
 

 If true, any resources such as Variables used in the session will not be
 shared with other sessions. However, when clusterspec propagation is
 enabled, this field is ignored and sessions are always isolated.
 

 Whether device placements should be logged.
 

 Global timeout for all blocking operations in this session.  If non-zero,
 and not overridden on a per-operation basis, this value will be used as the
 deadline for all blocking operations.
 

 Assignment of Nodes to Devices is recomputed every placement_period
 steps until the system warms up (at which point the recomputation
 typically slows down automatically).
 

 Options that apply when this session uses the distributed runtime.
 

 Options that apply when this session uses the distributed runtime.
 

 Options that apply when this session uses the distributed runtime.
 

 This option is experimental - it may be replaced with a different mechanism
 in the future.
 Configures session thread pools. If this is configured, then RunOptions for
 a Run call can select the thread pool to use.
 The intended use is for when some session invocations need to run in a
 background pool limited to a small number of threads:
 - For example, a session may be configured to have one large pool (for
 regular compute) and one small pool (for periodic, low priority work);
 using the small pool is currently the mechanism for limiting the inter-op
 parallelism of the low priority work.  Note that it does not limit the
 parallelism of work spawned by a single op kernel implementation.
 - Using this setting is normally not needed in training, but may help some
 serving use cases.
 - It is also generally recommended to set the global_name field of this
 proto, to avoid creating multiple large pools. It is typically better to
 run the non-low-priority work, even across sessions, in a single large
 pool.
 

 This option is experimental - it may be replaced with a different mechanism
 in the future.
 Configures session thread pools. If this is configured, then RunOptions for
 a Run call can select the thread pool to use.
 The intended use is for when some session invocations need to run in a
 background pool limited to a small number of threads:
 - For example, a session may be configured to have one large pool (for
 regular compute) and one small pool (for periodic, low priority work);
 using the small pool is currently the mechanism for limiting the inter-op
 parallelism of the low priority work.  Note that it does not limit the
 parallelism of work spawned by a single op kernel implementation.
 - Using this setting is normally not needed in training, but may help some
 serving use cases.
 - It is also generally recommended to set the global_name field of this
 proto, to avoid creating multiple large pools. It is typically better to
 run the non-low-priority work, even across sessions, in a single large
 pool.
 

 This option is experimental - it may be replaced with a different mechanism
 in the future.
 Configures session thread pools. If this is configured, then RunOptions for
 a Run call can select the thread pool to use.
 The intended use is for when some session invocations need to run in a
 background pool limited to a small number of threads:
 - For example, a session may be configured to have one large pool (for
 regular compute) and one small pool (for periodic, low priority work);
 using the small pool is currently the mechanism for limiting the inter-op
 parallelism of the low priority work.  Note that it does not limit the
 parallelism of work spawned by a single op kernel implementation.
 - Using this setting is normally not needed in training, but may help some
 serving use cases.
 - It is also generally recommended to set the global_name field of this
 proto, to avoid creating multiple large pools. It is typically better to
 run the non-low-priority work, even across sessions, in a single large
 pool.
 

 This option is experimental - it may be replaced with a different mechanism
 in the future.
 Configures session thread pools. If this is configured, then RunOptions for
 a Run call can select the thread pool to use.
 The intended use is for when some session invocations need to run in a
 background pool limited to a small number of threads:
 - For example, a session may be configured to have one large pool (for
 regular compute) and one small pool (for periodic, low priority work);
 using the small pool is currently the mechanism for limiting the inter-op
 parallelism of the low priority work.  Note that it does not limit the
 parallelism of work spawned by a single op kernel implementation.
 - Using this setting is normally not needed in training, but may help some
 serving use cases.
 - It is also generally recommended to set the global_name field of this
 proto, to avoid creating multiple large pools. It is typically better to
 run the non-low-priority work, even across sessions, in a single large
 pool.
 

 This option is experimental - it may be replaced with a different mechanism
 in the future.
 Configures session thread pools. If this is configured, then RunOptions for
 a Run call can select the thread pool to use.
 The intended use is for when some session invocations need to run in a
 background pool limited to a small number of threads:
 - For example, a session may be configured to have one large pool (for
 regular compute) and one small pool (for periodic, low priority work);
 using the small pool is currently the mechanism for limiting the inter-op
 parallelism of the low priority work.  Note that it does not limit the
 parallelism of work spawned by a single op kernel implementation.
 - Using this setting is normally not needed in training, but may help some
 serving use cases.
 - It is also generally recommended to set the global_name field of this
 proto, to avoid creating multiple large pools. It is typically better to
 run the non-low-priority work, even across sessions, in a single large
 pool.
 

 This option is experimental - it may be replaced with a different mechanism
 in the future.
 Configures session thread pools. If this is configured, then RunOptions for
 a Run call can select the thread pool to use.
 The intended use is for when some session invocations need to run in a
 background pool limited to a small number of threads:
 - For example, a session may be configured to have one large pool (for
 regular compute) and one small pool (for periodic, low priority work);
 using the small pool is currently the mechanism for limiting the inter-op
 parallelism of the low priority work.  Note that it does not limit the
 parallelism of work spawned by a single op kernel implementation.
 - Using this setting is normally not needed in training, but may help some
 serving use cases.
 - It is also generally recommended to set the global_name field of this
 proto, to avoid creating multiple large pools. It is typically better to
 run the non-low-priority work, even across sessions, in a single large
 pool.
 

 This option is experimental - it may be replaced with a different mechanism
 in the future.
 Configures session thread pools. If this is configured, then RunOptions for
 a Run call can select the thread pool to use.
 The intended use is for when some session invocations need to run in a
 background pool limited to a small number of threads:
 - For example, a session may be configured to have one large pool (for
 regular compute) and one small pool (for periodic, low priority work);
 using the small pool is currently the mechanism for limiting the inter-op
 parallelism of the low priority work.  Note that it does not limit the
 parallelism of work spawned by a single op kernel implementation.
 - Using this setting is normally not needed in training, but may help some
 serving use cases.
 - It is also generally recommended to set the global_name field of this
 proto, to avoid creating multiple large pools. It is typically better to
 run the non-low-priority work, even across sessions, in a single large
 pool.
 

 When true, WorkerSessions are created with device attributes from the
 full cluster.
 This is helpful when a worker wants to partition a graph
 (for example during a PartitionedCallOp).
 

 If true, use a new set of threads for this session rather than the global
 pool of threads. Only supported by direct sessions.
 If false, use the global threads created by the first session, or the
 per-session thread pools configured by session_inter_op_thread_pool.
 This option is deprecated. The same effect can be achieved by setting
 session_inter_op_thread_pool to have one element, whose num_threads equals
 inter_op_parallelism_threads.
 

 Optional list of all workers to use in this session.
 

 Options that apply to all GPUs.
 

 Options that apply to all graphs.
 

 Options that apply when this session uses the distributed runtime.
 

 Optional list of all workers to use in this session.
 

 Options that apply to all GPUs.
 

 Options that apply to all graphs.
 

 Options that apply when this session uses the distributed runtime.
 

 Map from device type name (e.g., "CPU" or "GPU" ) to maximum
 number of devices of that type to use.  If a particular device
 type is not found in the map, the system picks an appropriate
 number.
 

 Map from device type name (e.g., "CPU" or "GPU" ) to maximum
 number of devices of that type to use.  If a particular device
 type is not found in the map, the system picks an appropriate
 number.
 

 Map from device type name (e.g., "CPU" or "GPU" ) to maximum
 number of devices of that type to use.  If a particular device
 type is not found in the map, the system picks an appropriate
 number.
 

 This option is experimental - it may be replaced with a different mechanism
 in the future.
 Configures session thread pools. If this is configured, then RunOptions for
 a Run call can select the thread pool to use.
 The intended use is for when some session invocations need to run in a
 background pool limited to a small number of threads:
 - For example, a session may be configured to have one large pool (for
 regular compute) and one small pool (for periodic, low priority work);
 using the small pool is currently the mechanism for limiting the inter-op
 parallelism of the low priority work.  Note that it does not limit the
 parallelism of work spawned by a single op kernel implementation.
 - Using this setting is normally not needed in training, but may help some
 serving use cases.
 - It is also generally recommended to set the global_name field of this
 proto, to avoid creating multiple large pools. It is typically better to
 run the non-low-priority work, even across sessions, in a single large
 pool.
 

 Whether soft placement is allowed. If allow_soft_placement is true,
 an op will be placed on CPU if
   1. there's no GPU implementation for the OP
 or
   2. no GPU devices are known or registered
 or
   3. need to co-locate with reftype input(s) which are from CPU.
 

 Optional list of all workers to use in this session.
 

 Optional list of all workers to use in this session.
 

 When any filters are present sessions will ignore all devices which do not
 match the filters. Each filter can be partially specified, e.g. "/job:ps"
 "/job:worker/replica:3", etc.
 

 Options that apply to all GPUs.
 

 Options that apply to all GPUs.
 

 Options that apply to all graphs.
 

 Options that apply to all graphs.
 

 Nodes that perform blocking operations are enqueued on a pool of
 inter_op_parallelism_threads available in each process.
 0 means the system picks an appropriate number.
 Negative means all operations are performed in caller's thread.
 Note that the first Session created in the process sets the
 number of threads for all future sessions unless use_per_session_threads is
 true or session_inter_op_thread_pool is configured.
 

 The execution of an individual op (for some op types) can be
 parallelized on a pool of intra_op_parallelism_threads.
 0 means the system picks an appropriate number.
 If you create an ordinary session, e.g., from Python or C++,
 then there is exactly one intra op thread pool per process.
 The first session created determines the number of threads in this pool.
 All subsequent sessions reuse/share this one global pool.
 There are notable exceptions to the default behavior describe above:
 1. There is an environment variable  for overriding this thread pool,
    named TF_OVERRIDE_GLOBAL_THREADPOOL.
 2. When connecting to a server, such as a remote `tf.train.Server`
    instance, then this option will be ignored altogether.
 

 If true, any resources such as Variables used in the session will not be
 shared with other sessions. However, when clusterspec propagation is
 enabled, this field is ignored and sessions are always isolated.
 

 Whether device placements should be logged.
 

 Global timeout for all blocking operations in this session.  If non-zero,
 and not overridden on a per-operation basis, this value will be used as the
 deadline for all blocking operations.
 

 Assignment of Nodes to Devices is recomputed every placement_period
 steps until the system warms up (at which point the recomputation
 typically slows down automatically).
 

 Options that apply when this session uses the distributed runtime.
 

 Options that apply when this session uses the distributed runtime.
 

 This option is experimental - it may be replaced with a different mechanism
 in the future.
 Configures session thread pools. If this is configured, then RunOptions for
 a Run call can select the thread pool to use.
 The intended use is for when some session invocations need to run in a
 background pool limited to a small number of threads:
 - For example, a session may be configured to have one large pool (for
 regular compute) and one small pool (for periodic, low priority work);
 using the small pool is currently the mechanism for limiting the inter-op
 parallelism of the low priority work.  Note that it does not limit the
 parallelism of work spawned by a single op kernel implementation.
 - Using this setting is normally not needed in training, but may help some
 serving use cases.
 - It is also generally recommended to set the global_name field of this
 proto, to avoid creating multiple large pools. It is typically better to
 run the non-low-priority work, even across sessions, in a single large
 pool.
 

 This option is experimental - it may be replaced with a different mechanism
 in the future.
 Configures session thread pools. If this is configured, then RunOptions for
 a Run call can select the thread pool to use.
 The intended use is for when some session invocations need to run in a
 background pool limited to a small number of threads:
 - For example, a session may be configured to have one large pool (for
 regular compute) and one small pool (for periodic, low priority work);
 using the small pool is currently the mechanism for limiting the inter-op
 parallelism of the low priority work.  Note that it does not limit the
 parallelism of work spawned by a single op kernel implementation.
 - Using this setting is normally not needed in training, but may help some
 serving use cases.
 - It is also generally recommended to set the global_name field of this
 proto, to avoid creating multiple large pools. It is typically better to
 run the non-low-priority work, even across sessions, in a single large
 pool.
 

 When true, WorkerSessions are created with device attributes from the
 full cluster.
 This is helpful when a worker wants to partition a graph
 (for example during a PartitionedCallOp).
 

 If true, use a new set of threads for this session rather than the global
 pool of threads. Only supported by direct sessions.
 If false, use the global threads created by the first session, or the
 per-session thread pools configured by session_inter_op_thread_pool.
 This option is deprecated. The same effect can be achieved by setting
 session_inter_op_thread_pool to have one element, whose num_threads equals
 inter_op_parallelism_threads.