You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary:
C++ bindings make it a lot harder to create a pip-installable version of exir, since it would need to include prebuilt versions of the code for every architecture (or include a build system to build the bindings and flatbuffer library during install).
Instead, use the `flatc` commandline tool, which is a thin wrapper around the API we were already using.
- For internal builds, we embed `flatc` into the python package as a resource, keeping it self-contained. OSS builds could also choose to do this if they wanted to.
- If the binary is not present as a resource (like in the current OSS build), fall back to looking for `flatc` on the PATH.
Upsides:
- Lets OSS users figure out the best way to build and provide the `flatc` tool.
- Still gives us a way to provide a specific `flatc` implementation if desired, both internally and in OSS.
- Since `flatbuffers` is no longer linked into the binary, we won't run into flatbuffer versioning conflicts in bento etc.
Downsides:
- The `flatc` on the PATH may not be the version we use internally. As long as it understands our schema, it should work since the flatbuffers contract should ensure that things stay wire-compatible. But this might be something to watch.
- This now spawns a new process to generate the flatbuffer data instead of running in the python process. But given the typical size of production models, the process spawn/death overhead should be minimal relative to the rest of the export process: `time flatc` on my M1 macbook shows ~11ms wall time.
Reviewed By: mergennachin, tarun292
Differential Revision: D47074772
fbshipit-source-id: 4e0a4f19a7e78f2b9e1778b8f3dffe890119c278
0 commit comments