mdebray/tvl-depot
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
tvl-depot/tvix
History
Adam Joseph c92d06271d feat(tvix/eval): drop LightSpan::Delayed 
LightSpan::Delayed was introduced in commit
bf286a54bc which claimed that "This
reduces the eval time for `builtins.length (builtins.attrNames
(import <nixpkgs> {}))` by *one third*!"

I am unable to reproduce this result.  In fact, dropping the
LightSpan::Delayed variant of the enum makes eval of the same
expression slightly faster!  I also tried a large evaluation
(pkgsCross...hello) and got similar results: slightly faster,
slightly less memory.  See git footers.

I suspect that there was some unrelated horrific inefficiency that
has since been fixed.  The avoided computation in `get_span()` is
nothing more than a binary search!  If this were in fact a major
performance issue we could simply precompute the mapping from
CodeIdx to Span when the Chunk becomes immutable (i.e. at the end of
the compilation process, when compiler backtracking is no longer a
concern).  Since a Span is just 64 bits this is not a space issue,
and since binary search is much simpler than compiling Nix
expressions it isn't a performance issue either.

Technically there is no longer any reason to have LightSpan since it
is now a single-variant enum.  However there is no rush to remove
it, since Rust will optimize its representation into the same thing
you'd get if you replaced LightSpan by Span.

Prev-Benchmark: {"nixpkgs-attrnames":{"kbytes":"233824","system":"0.32","user":"2.02"}}
This-Benchmark: {"nixpkgs-attrnames":{"kbytes":"230192","system":"0.29","user":"2.00"}}
Prev-Benchmark: {"pkgsCross.aarch64-multiplatform.hello.outPath":{"kbytes":"458936","system":"0.73","user":"5.36"}}
This-Benchmark: {"pkgsCross.aarch64-multiplatform.hello.outPath":{"kbytes":"451808","system":"0.53","user":"5.10"}}

Change-Id: Ib9e04806850aa1fc4e66e2a042703986440a7b4e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/10254
Reviewed-by: tazjin <tazjin@tvl.su>
Autosubmit: Adam Joseph <adam@westernsemico.com>
Tested-by: BuildkiteCI
2023-12-12 14:34:28 +00:00
..
.vscode chore(tvix): fix vscode rust-analyzer recommendation 2022-10-15 16:54:28 +00:00
boot refactor(tvix/nar-bridge): mv nar-bridge{,-http} 2023-10-05 06:17:10 +00:00
build refactor(tvix/*/protos): separate lint target 2023-12-11 22:35:39 +00:00
build-go feat(tvix/build-go): init 2023-12-11 21:43:38 +00:00
castore refactor(tvix/*store/sled): make ::new() more generic 2023-12-11 22:46:50 +00:00
castore-go docs(tvix/*store-go): fix README invocation 2023-12-11 21:47:43 +00:00
cli feat(tvix/cli): add benchmark for bf286a54bc 2023-12-12 14:28:53 +00:00
docs docs(tvix/docs): add document about drvPath differences 2023-08-20 22:08:02 +00:00
eval feat(tvix/eval): drop LightSpan::Delayed 2023-12-12 14:34:28 +00:00
glue refactor(tvix): use io::Result for EvalIO 2023-12-12 14:28:50 +00:00
nar-bridge fix(tvix/nar-bridge): fix FOD hash 2023-12-09 09:24:53 +00:00
nix-compat chore(tvix): bump criterion to 0.5 2023-12-11 03:59:30 +00:00
scripts fix(tvix): Fix cwd in benchmark script 2023-12-11 04:13:41 +00:00
serde fix(tvix/eval): fix b/281 by adding Value::Catchable 2023-09-24 21:54:10 +00:00
store refactor(tvix/*store/sled): make ::new() more generic 2023-12-11 22:46:50 +00:00
store-go docs(tvix/*store-go): fix README invocation 2023-12-11 21:47:43 +00:00
tools chore(3p/sources): bump channels & overlays (2023-11-27) 2023-11-27 21:16:46 +00:00
verify-lang-tests test(tvix/eval): add test case for b/339 2023-12-12 14:26:46 +00:00
website feat(tvix/website): add structured data for search engines 2023-10-05 17:14:13 +00:00
.gitignore chore(tvix): add /*.sled to .gitignore 2023-09-24 17:05:48 +00:00
buildkite.yml chore(tvix): move buildkite.yml from views/tvix to tvix/ 2023-10-25 08:22:57 +00:00
Cargo.lock feat(tvix/glue): add nixpkgs eval benchmark 2023-12-12 10:27:51 +00:00
Cargo.nix feat(tvix/glue): add nixpkgs eval benchmark 2023-12-12 10:27:51 +00:00
Cargo.toml feat(tvix/build): init 2023-12-11 21:43:38 +00:00
clippy.toml chore(tvix): add missing clippy attributes & config 2023-11-05 20:28:38 +00:00
crate-hashes.json fix(tvix): patch futures::AsyncBufReadExt::fill_buf 2023-11-19 08:35:38 +00:00
default.nix refactor(tvix): use granular proto files 2023-12-11 22:35:39 +00:00
LICENSE chore(tvix): Bootstrap Tvix folder 2021-03-27 00:09:49 +00:00
logo.webp refactor(tvix): move logo to //tvix:logo 2023-09-10 13:13:14 +00:00
OWNERS chore(gerrit): migrate OWNERS files to code-owners style 2022-09-19 11:13:28 +00:00
README.md docs(tvix): fix crate2nix-generate invocation 2023-12-11 03:59:28 +00:00
shell.nix feat(tvix/glue): add nixpkgs eval benchmark 2023-12-12 10:27:51 +00:00

README.md

Tvix is a new implementation of the Nix language and package manager. See the announcement post for information about the background of this project.

Tvix is developed by TVL in our monorepo, the depot, at //tvix. Code reviews take place on Gerrit, bugs are filed in our issue tracker.

For more information about Tvix, feel free to reach out. We are interested in people who would like to help us review designs, brainstorm and describe requirements that we may not yet have considered.

Most of the discussion around development happens on our IRC channel, which you can join in several ways documented on tvl.fyi, or on our mailing list.

Contributions to Tvix follow the TVL review flow and contribution guidelines.

WARNING: Tvix is not ready for use in production. None of our current APIs should be considered stable in any way.

WARNING: Any other instances of this project or repository are josh-mirrors. We do not accept code contributions or issues outside of the tooling and communication methods outlined above.

Components

This folder contains the following components:

  • //tvix/castore - subtree storage/transfer in a content-addressed fashion
  • //tvix/cli - preliminary REPL & CLI implementation for Tvix
  • //tvix/eval - an implementation of the Nix programming language
  • //tvix/nar-bridge
    • nar-bridge-http: A HTTP webserver providing a Nix HTTP Binary Cache interface in front of a tvix-store
  • //tvix/nix-compat - a Rust library for compatibility with C++ Nix, features like encodings and hashing schemes and formats
  • //tvix/serde - a Rust library for using the Nix language for app configuration
  • //tvix/store - a "filesystem" linking Nix store paths and metadata with the content-addressed layer

Some additional folders with auxiliary things exist and can be explored at your leisure.

Building the CLI

The CLI can also be built with standard Rust tooling (i.e. cargo build), as long as you are in a shell with the right dependencies.

  • If you cloned the full monorepo, it can be provided by mg shell //tvix:shell.
  • If you cloned the tvix workspace only (git clone https://code.tvl.fyi/depot.git:workspace=views/tvix.git), nix-shell provides it.

If you're in the TVL monorepo, you can also run mg build //tvix/cli (or mg build from inside that folder) for a more incremental build.

Please follow the depot-wide instructions on how to get mg and use the depot tooling.

Compatibility

Important note: We only use and test Nix builds of our software against Nix 2.3. There are a variety of bugs and subtle problems in newer Nix versions which we do not have the bandwidth to address, builds in newer Nix versions may or may not work.

Rust projects, crate2nix

Some parts of Tvix are written in Rust. To simplify the dependency management on the Nix side of these builds, we use crate2nix in a single Rust workspace in //tvix to maintain the Nix build configuration.

When making changes to Cargo dependency configuration in any of the Rust projects under //tvix, be sure to run mg run //tvix:crate2nix-generate in //tvix itself and commit the changes to the generated Cargo.nix file. This only applies to the full TVL checkout.

License structure

All code implemented for Tvix is licensed under the GPL-3.0, with the exception of the protocol buffer definitions used for communication between services which are available under a more permissive license (MIT).

The idea behind this structure is that any direct usage of our code (e.g. linking to it, embedding the evaluator, etc.) will fall under the terms of the GPL3, but users are free to implement their own components speaking these protocols under the terms of the MIT license.