Proposal
Vortex project depends on a complex toolchain and gets deployed in a variety of environments (local development, server development, FPGA deployment, CI pipeline, workshop tutorial, containerized, non-conatinerized, etc).
Furthermore, incorporating vortex into other simulation environments can introduce unknown requirements down the road.
AI tools are good enough to resolve these issues in a local context, but have no support for global correctness. Its better to be more explicit about the build requirements, beyond just readme, build scripts, make files.
The Bazel build system introduces the concept of hermeticity in build systems: https://bazel.build/basics/hermeticity
Emphasis on this section of the documentation:
The two important aspects of hermeticity are:
Isolation: Hermetic build systems treat tools as source code. They download copies of tools and manage their storage and use inside managed file trees. This creates isolation between the host machine and local user, including installed versions of languages.
Source identity: Hermetic build systems try to ensure the sameness of inputs. Code repositories, such as Git, identify sets of code mutations with a unique hash code. Hermetic build systems use this hash to identify changes to the build’s input.
Scope and Discussion
This is a relatively large undertaking, but I expect it to scale well into the future with much less "emergency failures" occurring. Prior vortex infra work such as ci, containerization, docs, build scripts, fpga deploy which I have worked on should all be encapsulated by this project. Another benefit of this approach is that the rules are explicitly writen in configuration files so future authors can add, modify, debug, etc without deep rearchitecting. It may increase local repo size since all deps will be kept locally. There might be a method to do a shared cloud env (ie for fpga licenses, NFS, etc). I'm sure this can be tackled in future commits. As such, this first iteration will focus on local build and development. I expect CI to have the same requirements. More specifically, FPGA is not included in the first iteration.
Motivation
Currently vortex has a container, which helps you distribute a standard environment. However, there no automatic method to check when a new dependency is required, but not added to the container. This is because some users may elect not to use the container in the first place!! In other words, the container is only useful if it cannot be side stepped. One goal of this work is to enforce one entry point to build, test, run, etc vortex. This will be a large undertaking, but Bazel is capable of handling all of the hard work, as long as its configured correctly and tested thoroughly. Another goal of this work is to detect when deps are out of date or changed, this is as simple checking their hash before proceeding with compilation or hitting cache. Finally, Bazel encourages good repo structure, teaches good habits, and introduces a topical and highly requested skill for systems developers should be familiar with. Bazel can also automatically parallelize and cache builds to improve performance without compromising fragmented binaries (consider: if you rerun a executable without recompiling latest changes). Finally, you can easily generate shareable binaries. This is particularly relevant to the vortex project for a number of reasons: 1) Distribute executables across multiple nodes to run large scale sims. 2) Compile vortex on a performance node, then just send executable to FPGA node for faster iteration cycles. 3) Data collection on multiple configs or some auto tuning framework
Implementation
I plan to try migrating to Bazel since it exposes all the tools that I need, as well as a familiar command line interface: bazel build ..., bazel test ... to wrap existing ci scripts. Using Bazel strictly enforces the rules of hermetic builds mentioned above. Furthermore it prevents side-stepping these rules with quick convenience scripts (.sh). You can still pass envs and flags to match the expected vortex configs format.
Proposal
Vortex project depends on a complex toolchain and gets deployed in a variety of environments (local development, server development, FPGA deployment, CI pipeline, workshop tutorial, containerized, non-conatinerized, etc).
Furthermore, incorporating vortex into other simulation environments can introduce unknown requirements down the road.
AI tools are good enough to resolve these issues in a local context, but have no support for global correctness. Its better to be more explicit about the build requirements, beyond just readme, build scripts, make files.
The Bazel build system introduces the concept of hermeticity in build systems: https://bazel.build/basics/hermeticity
Emphasis on this section of the documentation:
Scope and Discussion
This is a relatively large undertaking, but I expect it to scale well into the future with much less "emergency failures" occurring. Prior vortex infra work such as ci, containerization, docs, build scripts, fpga deploy which I have worked on should all be encapsulated by this project. Another benefit of this approach is that the rules are explicitly writen in configuration files so future authors can add, modify, debug, etc without deep rearchitecting. It may increase local repo size since all deps will be kept locally. There might be a method to do a shared cloud env (ie for fpga licenses, NFS, etc). I'm sure this can be tackled in future commits. As such, this first iteration will focus on local build and development. I expect CI to have the same requirements. More specifically, FPGA is not included in the first iteration.
Motivation
Currently vortex has a container, which helps you distribute a standard environment. However, there no automatic method to check when a new dependency is required, but not added to the container. This is because some users may elect not to use the container in the first place!! In other words, the container is only useful if it cannot be side stepped. One goal of this work is to enforce one entry point to build, test, run, etc vortex. This will be a large undertaking, but Bazel is capable of handling all of the hard work, as long as its configured correctly and tested thoroughly. Another goal of this work is to detect when deps are out of date or changed, this is as simple checking their hash before proceeding with compilation or hitting cache. Finally, Bazel encourages good repo structure, teaches good habits, and introduces a topical and highly requested skill for systems developers should be familiar with. Bazel can also automatically parallelize and cache builds to improve performance without compromising fragmented binaries (consider: if you rerun a executable without recompiling latest changes). Finally, you can easily generate shareable binaries. This is particularly relevant to the vortex project for a number of reasons: 1) Distribute executables across multiple nodes to run large scale sims. 2) Compile vortex on a performance node, then just send executable to FPGA node for faster iteration cycles. 3) Data collection on multiple configs or some auto tuning framework
Implementation
I plan to try migrating to Bazel since it exposes all the tools that I need, as well as a familiar command line interface:
bazel build ...,bazel test ...to wrap existing ci scripts. Using Bazel strictly enforces the rules of hermetic builds mentioned above. Furthermore it prevents side-stepping these rules with quick convenience scripts (.sh). You can still pass envs and flags to match the expected vortex configs format.