Proto commits in facebookresearch/CompilerGym

These 36 commits are when the Protocol Buffers files have changed:

2022-04-14

Create an MLIR environment with matrix multiplication Co-authored-by: kyle <kyle.w.herndon@gmail.com>

The documentation is generated from this commit.

2022-03-31

Add permutation and space sequence spaces

Add dispatching on type_id during action and observation conversion

2022-02-03

gRPC refactoring of actions and observations

2021-09-29

[docs] Document all protocol buffers.

[proto] Add an is_commandline flag for NamedDiscreteSpace. Issue #52.

[proto] Make actions composable. This expands the Action protocol buffer from a scalar integer value to a list of Choice objects, where each choice is either a scalar integer, double, or an enum. This enables multi-dimensional action spaces. Issue #52.

2021-09-23

[datasets] Make Benchmark.from_file() compatible with remote services.

2021-09-17

[proto] Add a new Command message type. This creates a new Command protocol buffer that encapsulates all of the details for running a single command. The Subprocess.h header has been updated with a new class to use this proto buffer.

2021-07-20

Small docstring clarification.

2021-07-16

Add support for variable-length sequences.

[proto] Add a BenchmarkDynamicConfig message type.

2021-07-09

Add a mechanism for sending arbitrary data payloads to the backend. This patch adds a mechanism to the CompilerGym client/service architecture so that the client can send arbitrary data messages to the service, which can then generate a response. This can be used by particular client/service implementations to provide a "back door" for talking to the service in a way that doesn't conform to the normal RL environment communication pattern. github.com/facebookresearch/CompilerGym/issues/312

2021-06-22

Add an always_send_benchmark_on_reset option.

2021-05-27

[rpc] Enable arena codegen.

2021-05-19

Port documentation to Doxygen format.

2021-05-11

[rpc] Add an Action protocol buffer. This wraps the current integer-based 'action index' in an Action protocol buffer. This is to pave the way for adding support for more complex, non-categorical action spaces. Issue #52

2021-04-28

[datasets] Switch CompilerEnv to the new dataset API. This switches over the `CompilerEnv` environment to use the new dataset API, dropping the `LegacyDataset` class. Background ---------- Since the very first prototype of CompilerGym, a `Benchmark` protocol buffer has been used to provide a serializable representation of benchmarks that can be passed back and forth between the service and the frontend. Initially, it was up to the compiler service to maintain the set of available benchmarks, exposing the available benchmarks with a `GetBenchmarks()` RPC method, and allowing new benchmarks to be added using an `AddBenchmarks()` method. This was fine for the initial use case of shipping a handful of benchmarks and allowing ad-hoc new benchmarks to be added, but for managing larger sets of benchmarks, a *datasets* abstraction was added. Initial Datasets abstraction ---------------------------- To add support for managing large sets of programs, a [Dataset](https://github.com/facebookresearch/CompilerGym/blob/49c10d77d1c1b1297a1269604584a13c10434cbb/compiler_gym/datasets/dataset.py#L20) tuple was added that describes a set of programs, and a link to the a tarball containing those programs. The tarball is required to have a JSON file containing metadata, and a directory containing the benchmarks, one file per benchmark. A set of operations were added to the frontend command line to make downloading and unpacking these tarballs easier: https://github.com/facebookresearch/CompilerGym/blob/49c10d77d1c1b1297a1269604584a13c10434cbb/compiler_gym/bin/datasets.py#L5-L133 Problems with this approach --------------------------- (1) **Leaky abstraction** Both the environment and backend service have to know about datasets. This means redundant duplicated logic, and adds a maintenance burden of keeping the C++/python logic in sync. (2) **Inflexible** Only supports environments in which a single file represents a benchmark. No support for multi-file benchmarks, benchmarks that are compiled on-demand, etc. (3) **O(n) space and time overhead** on each service instance, where *n* is the total number of benchmarks. At init time, each service needs to recursively scan a directory tree to build a list of available benchmarks. This list must be kept in memory. This adds startup time, and also causes cache invalidation issues when multiple environment instances are modifying the underlying filesystem. New Dataset API --------------- This commit changes the ownership model so that the *Environment* owns the benchmarks and datasets, not the service. This uses the new `Dataset` class hierarchy that has been added in previous pull requests: #190, #191, #192, #200, #201. Now, the backend has no knowledge of "datasets". Instead the service simply keeps a small cache of benchmarks that it has seen. If a session request has a benchmark URI that is not in this cache, the service returns a "resource not found" error and the frontend logic can then respond by sending it a copy of the benchmark as a `Benchmark` proto. The service is free to cache this for future use, and can empty the cache whenever it wants. This new approach has a few key benefits: (1) By moving all of the datasets logic into the frontend, it becomes much easier for users to define their own datasets. (2) Reduces compiler service startup time as it removes the need for each service to do a recursive filesystem sweep. (3) Removes the requirement that the set of benchmarks is fully enumerable, allow for program generators that can produce a theoretically infinite number of benchmarks. (4) Adds support for lazily-compiled datasets of programs that are generated on-demand. (5) Removes the need to download datasets ahead of time. Datasets can now be installed on-demand. Summary of changes ------------------ (1) Changes the type of `env.benchmark` from a string to a `Benchmark` instance. (2) Makes `env.benchmark` a mandatory attribute. If no benchmark is provided at init time, one is chosen deterministically. If you wish to select a random benchmark, use `env.datasets.benchmark()`. (3) `env.fork()` no longer requires `env.reset()` to have been called first. It will call `env.reset()` if required. (4) `env.benchmark = None` is no longer a valid way of requesting a random benchmark. If you would like a random benchmark, you must now roll your own random picker using `env.datasets.benchmark_uris()` and similar. (5) Deprecates all `LegacyDataset` operations, changing their behavior to no-ops, and removing the class. (6) Renames `cBench` to `cbench` to be consistent with the lower-case naming convention of gym. The old `cBench` datasets are kept around but are marked deprecated to encourage migration. Migrating to the new interface ------------------------------ To migrate existing code to the new interface: (1) Update references to `cBench-v[01]` to `cbench-v1`. (2) Review code that accesses the `env.benchmark` property and update to `env.benchmark.uri` if a string name is required. (3) Review code that calls `env.reset()` without first setting a benchmark. Previously, calling `env.reset()` would select a random benchmark. Now, `env.reset()` always selects the last used benchmark, or a predetermined default if none is specified. (4) Review code that relies on `env.benchmark` being `None` to select benchmarks randomly. Now, `env.benchmark` is always set to the previously used benchmark, or a predetermined default benchmark if none has been provided. (5) Remove calls to `env.require_dataset()`. Issue #45.

2021-04-21

[env] Add initial observations to StartSession calls. This patch modifies the StartSessionRequest RPC call to add a list of observations to compute. This means that env.reset() requires only a single RPC roundtrip, rather than needing to call StartSession() followed by Step(). The result is a 15%-21% speedup in env.reset() runtime, depending on the size of the benchmark (slower benchmarks benefit more): ---------------------------------------------------------------------------- benchmark 'test_reset[fast_benchmark]': 2 tests ---------------------------------------------------------------------------- Name (time in ms) Min Max Mean StdDev Median IQR Outliers OPS Rounds Iterations --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- test_reset[fast_benchmark] (development) 1.8736 (1.26) 2.0939 (1.17) 1.9388 (1.15) 0.0411 (1.25) 1.9368 (1.15) 0.0583 (1.0) 181;1 515.7798 (0.87) 500 200 test_reset[fast_benchmark] (reset) 1.4903 (1.0) 1.7889 (1.0) 1.6839 (1.0) 0.0330 (1.0) 1.6773 (1.0) 0.0596 (1.02) 151;1 593.8650 (1.0) 500 200 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------ benchmark 'test_reset[slow_benchmark]': 2 tests ------------------------------------------------------------------------------ Name (time in ms) Min Max Mean StdDev Median IQR Outliers OPS Rounds Iterations ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- test_reset[slow_benchmark] (development) 83.2942 (1.21) 108.7450 (1.24) 93.9165 (1.21) 3.5005 (1.11) 93.7544 (1.21) 3.4142 (1.0) 128;38 10.6478 (0.83) 500 1 test_reset[slow_benchmark] (reset) 69.0844 (1.0) 87.8784 (1.0) 77.7085 (1.0) 3.1453 (1.0) 77.4392 (1.0) 3.5923 (1.05) 163;18 12.8686 (1.0) 500 1 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

2021-04-08

Update deprecation warning versions. Issue #45.

2021-03-18

[rpc] Add a deprecation notice for GetBenchmarks(). github.com/facebookresearch/CompilerGym/issues/45

2021-03-15

[rpc] Fix a typo in protobuf field name.

2021-02-22

[rpc] Remove unused field.

2021-02-19

Implement fork() on service side. Move the fork() operator into the service API, allowing a single service to share multiple connections to frontends. This removes the service startup cost, producing between a 44x and 77x speedup over the current implementation, depending on the size of the benchmark being forked. This also changes the service implementation to be thread safe wrt session creation/destruction to prevent races with competing forks. This also fixes a bug wherein scaled rewards on forked environments would use the wrong scaling factor.

[backend] Rename 'Episode' to 'Session' in service interface. This change is to gradually decouple the RL interface from the services. A service supports "sessions". These sessions are used by the python frontend to create environments/episodes.

[rpc] Add proto definitions for a Fork() operator.

Add support for scalar observation spaces.

Move reward calculation out of service backend. Instead of calculating reward in the service backend, a new Reward class is added to the python frontend and user to compute rewards based on observation values generated by the service. The goal of this change is twofold: (1) to simplify the backend service API by merging the GetObservation(), GetReward(), and TakeAction() operators into a single Step() call. This in turn enables more efficient usage as multiple calls can be replaced by a single Step() invocation. (2) to make it easier for users to define their own reward spaces. Like with observation spaces, learning techniques are sensitive to the reward space design decisions and so experimenting with reward shaping/scaling/design is a common use case. By implementing rewards in Python that simplifies the experimentation. The new RPC Step() interface accepts a list of actions and a list of observations. The service first applies the actions and then generates the observations. The frontend python code then uses those observations to compute a reward value. One downside of this approach is that it means it is no longer to add support for a new compiler without writing any Python, but this seems like a reasonable tradeoff for the benefits.

2021-02-11

Fix minor typo in docstring.

2021-01-02

Add a default observation value. ... and overhaul the client-side observation space implementation to tidy it up.

Add a default reward mechanism.

2020-12-28

Add a CompilerEnv.compiler_version property.

2020-12-27

Add specifications for observation spaces.

Add specifications for reward spaces.

2020-12-21

Initial release. This commit combines contributions from: Chris Cummins <cummins@fb.com> Soumith Chintala <soumith@fb.com> Horace He <chilli@fb.com> Hugh Leather <hleather@fb.com> Benoit Steiner <benoitsteiner@fb.com>

2020-12-18

Initial release. This commit combines contributions from: Chris Cummins <cummins@fb.com> Soumith Chintala <soumith@fb.com> Horace He <chilli@fb.com> Hugh Leather <hleather@fb.com> Benoit Steiner <benoitsteiner@fb.com>