d6c57eb957
This replaces the OpCode enum with a new Op enum which is guaranteed to fit in a
single byte. Instead of carrying enum variants with data, every variant that has
runtime data encodes it into the `Vec<u8>` that a `Chunk` now carries.
This has several advantages:
* Less stack space is required at runtime, and fewer allocations are required
while compiling.
* The OpCode doesn't need to carry "weird" special-cased data variants anymore.
* It is faster (albeit, not by much). On my laptop, results consistently look
approximately like this:
Benchmark 1: ./before -E '(import <nixpkgs> {}).firefox.outPath' --log-level ERROR --no-warnings
Time (mean ± σ): 8.224 s ± 0.272 s [User: 7.149 s, System: 0.688 s]
Range (min … max): 7.759 s … 8.583 s 10 runs
Benchmark 2: ./after -E '(import <nixpkgs> {}).firefox.outPath' --log-level ERROR --no-warnings
Time (mean ± σ): 8.000 s ± 0.198 s [User: 7.036 s, System: 0.633 s]
Range (min … max): 7.718 s … 8.334 s 10 runs
See notes below for why the performance impact might be less than expected.
* It is faster while at the same time dropping some optimisations we previously
performed.
This has several disadvantages:
* The code is closer to how one would write it in C or Go.
* Bit shifting!
* There is (for now) slightly more code than before.
On performance I have the following thoughts at the moment:
In order to prepare for adding GC, there's a couple of places in Tvix where I'd
like to fence off certain kinds of complexity (such as mutating bytecode, which,
for various reaons, also has to be part of data that is subject to GC). With
this change, we can drop optimisations like retroactively modifying existing
bytecode and *still* achieve better performance than before.
I believe that this is currently worth it to pave the way for changes that are
more significant for performance.
In general this also opens other avenues of optimisation: For example, we can
profile which argument sizes actually exist and remove the copy overhead of
varint decoding (which does show up in profiles) by using more adequately sized
types for, e.g., constant indices.
Known regressions:
* Op::Constant is no longer printing its values in disassembly (this can be
fixed, I just didn't get around to it, will do separately).
Change-Id: Id9b3a4254623a45de03069dbdb70b8349e976743
Reviewed-on: https://cl.tvl.fyi/c/depot/+/12191
Tested-by: BuildkiteCI
Reviewed-by: flokli <flokli@flokli.de>
|
||
|---|---|---|
| .. | ||
| benches | ||
| builtin-macros | ||
| proptest-regressions/value | ||
| src | ||
| tests | ||
| .skip-subtree | ||
| build.rs | ||
| Cargo.toml | ||
| clippy.toml | ||
| default.nix | ||
| README.md | ||
Tvix Evaluator
This project implements an interpreter for the Nix programming language. You can experiment with an online version of the evaluator: tvixbolt.
The interpreter aims to be compatible with nixpkgs, on the
foundation of Nix 2.3.
Important note: The evaluator is not yet feature-complete, and while the core mechanisms (compiler, runtime, ...) have stabilised somewhat, a lot of components are still changing rapidly.
Please contact TVL with any questions you might have.
Building tvix-eval
Please check the README.md one level up for instructions on how to build this.
The evaluator itself can also be built with standard Rust tooling (i.e. cargo build).
If you would like to clone only the evaluator and build it directly with Rust tooling, you can do:
git clone https://code.tvl.fyi/depot.git:/tvix/eval.git tvix-eval
cd tvix-eval && cargo build
Tests
Tvix currently has three language test suites for tvix-eval:
-
nix_testsandtvix_testsare based on the same mechanism borrowed from the C++ Nix implementation. They consist of Nix files as well as expected output (if applicable). The test cases are split into four categories:eval-okay(evaluates successfully with the expected output),eval-fail(fails to evaluate, no expected output),parse-okay(expression parses successfully, no expected output) andparse-fail(expression fails to parse, no expected output). Tvix currently ignores the last two types of test cases, since it doesn't implement its own parser.Both test suites have a
notyetpassingdirectory. All test cases in here test behavior that is not yet supported by Tvix. They are considered to be expected failures, so you can't forget to move them into the test suite proper when fixing the incompatibility.Additionally, separate targets in the depot pipeline, under
//tvix/verify-lang-tests, check both test suites (includingnotyetpassingdirectories) against C++ Nix 2.3 and the default C++ Nix version in nixpkgs. This way we can prevent accidentally introducing test cases for behavior that C++ Nix doesn't exhibit.-
nix_testshas the test cases from C++ Nix's language test suite and is sporadically updated by manually syncing the directories. Thenotyetpassingdirectory shows how far it is until we pass it completely. -
tvix_testscontains test cases written by the Tvix contributors. Some more or less duplicate test cases contained innix_tests, but many cover relevant behavior that isn't bynix_tests. Consequently, it'd be nice to eventually merge the two test suites into a jointly maintained, common Nix language test suite.It also has a
notyetpassingdirectory for missing behavior that is discovered while working on Tvix and isn't covered by thenix_testssuite.
-
-
nix_oraclecan evaluate Nix expressions in Tvix and compare the result against C++ Nix (2.3) directly. Eventually it should gain the ability to property test generated Nix expressions. An additional feature is that it can evaluate expressions without--strict, so thunking behavior can be verified more easily.
rnix-parser
Tvix is written in memory of jD91mZM2, the author of rnix-parser who sadly passed away.
Tvix makes heavy use of rnix-parser in its bytecode compiler. The parser is now maintained by Nix community members.