mathbench

mathbench is a suite of unit tests and benchmarks comparing the output and performance of a number of different Rust linear algebra libraries for common game and graphics development tasks.

mathbench is written by the author of glam and has been used to compare the performance of glam with other similar 3D math libraries targeting games and graphics development, including:

• cgmath
• euclid
• nalgebra
• pathfinder_geometry
• ultraviolet
• vek

The benchmarks

All benchmarks are performed using Criterion.rs. Benchmarks are logically into the following categories:

• no-op baseline - measures the per-type cost of running an identity operation through the benchmark loop (load + store plus amortized loop overhead). Useful as a floor and a control, not as a library performance comparison.
• single operations - measure the performance of common operations on types, e.g. a matrix inverse, vector normalization or multiplying two matrices.
• throughput operations - measure the performance of common operations on batches of data. These measure operations that would commonly be processing batches of input, for example transforming a number of vectors with the same matrix.
• workload operations - these attempt to recreate common workloads found in game development to try and demonstrate performance on real world tasks.

Operation benchmarks run a batch of operations per timed iteration and report per-element throughput via Criterion's Throughput::Elements, at two sizes by default: 16 (L1-resident) and 1024 (adds cache pressure). Batching amortizes the fixed per-iteration harness cost, so results are directly comparable across libraries and across scalar and wide types. The 16 point still carries a little of that fixed overhead (more so for wider types, which need fewer operations per batch); 1024 is close to pure throughput. Compare libraries at the same size. A single input pool is generated per benchmark and reused across sizes. The matrix/quaternion "multiply vector" and transform benches broadcast one transform across a batch of vectors or points, matching the throughput workload described above. For wide types "one transform" is a single packed value (e.g. the four matrices in a Mat4x4) reused for the whole batch.

Despite best attempts, take the results of micro benchmarks with a pinch of salt.

Operation benchmarks

• matrix benches - performs common matrix operations such as transpose, inverse, determinant and multiply.
• rotation 3d benches - perform common 3D rotation operations.
• transform 2d & 3d benches - bench special purpose 2D and 3D transform types. These can be compared to 3x3 and 4x4 matrix benches to some extent.
• transformations benches - performs affine transformations on vectors - uses the best available type for the job, either matrix or transform types depending on the library.
• vector benches - perform common vector operations.

Workload benchmarks

• euler bench - performs an Euler integration on arrays of 2D and 3D vectors

The benchmarks are currently focused on f32 types as that is all glam currently supports.

Crate differences

Different libraries have different features and different ways of achieving the same goal. For the purpose of trying to get a performance comparison sometimes mathbench compares similar functionality, but sometimes it's not exactly the same. Below is a list of differences between libraries that are notable for performance comparisons.

Matrices versus transforms

The euclid library does not support generic square matrix types like the other libraries tested. Rather it has 2D and 3D transform types which can transform 2D and 3D vector and point types. Each library has different types for supporting transforms but euclid is unique amongst the libraries tested in that is doesn't have generic square matrix types.

The Transform2D is stored as a 3x2 row major matrix that can be used to transform 2D vectors and points.

Similarly Transform3D is used for transforming 3D vectors and points. This is represented as a 4x4 matrix so it is more directly comparable to the other libraries however it doesn't support some operations like transpose.

There is no equivalent to a 2x2 matrix type in euclid.

Matrix inverse

Note that cgmath and nalgebra matrix inverse methods return an Option whereas glam and euclid do not. If a non-invertible matrix is inverted by glam or euclid the result will be invalid (it will contain NaNs).

Quaternions versus rotors

Most libraries provide quaternions for performing rotations except for ultraviolet which provides rotors.

Type representation and ABI

The scalar glam benchmarks use the SIMD-friendly padded types where they exist (Vec3A, Mat3A, Affine3A), while other libraries use unpacked types such as a 12-byte Vec3 or a 36-byte Mat3. The padded types carry an extra lane and 16-byte alignment, so a value is loaded, stored and operated on as a single 128-bit SIMD register, whereas an unpacked value takes several narrower moves. This shows up in the no-op baseline, which measures how a type is moved through the benchmark loop, so differences there reflect type representation rather than library efficiency. The same applies to euclid transform types and to the Option-returning inverse methods noted above.

Wide benchmarks

All benchmarks are gated as either "wide" or "scalar". This division allows us to more fairly compare these different styles of libraries.

"scalar" benchmarks operate on standard scalar f32 values, doing calculations on one piece of data at a time (or in the case of a "horizontal" SIMD library like glam, one Vec3/Vec4 at a time).

"wide" benchmarks operate in a "vertical" AoSoA (Array-of-Struct-of-Arrays) fashion, which is a programming model that allows the potential to more fully use the advantages of SIMD operations. However, it has the cost of making algorithm design harder, as scalar algorithms cannot be directly used by "wide" architectures. Because of this difference in algorithms, we also can't really directly compare the performance of "scalar" vs "wide" types because they don't quite do the same thing (wide types operate on multiple pieces of data at the same time).

The "wide" benchmarks still include glam, a scalar-only library, as a comparison. Even though the comparison is somewhat apples-to-oranges, in each of these cases, when running "wide" benchmark variants, glam is configured to do the exact same amount of final work, producing the same outputs that the "wide" versions would. The purpose is to give an idea of the possible throughput benefits of "wide" types compared to writing the same algorithms with a scalar type, at the cost of extra care being needed to write the algorithm.

To learn more about AoSoA architecture, see this blog post by the author of nalgebra which goes more in depth to how AoSoA works and its possible benefits. Also take a look at the "Examples" section of ultraviolet's README, which contains a discussion of how to port scalar algorithms to wide ones, with the examples of the Euler integration and ray-sphere intersection benchmarks from mathbench.

Note that the nalgebra wide benchmarks use simba's stable, wide crate backed types (WideF32x4 and WideF32x8), so they build on stable Rust.

Additionally the f32x8 benchmarks will require the AVX2 instruction set, to enable that you will need to build with RUSTFLAGS='-C target-feature=+avx2.

Build settings

The default profile.bench settings are used, these are documented in the cargo reference.

Some math libraries are optimized to use specific instruction sets and may benefit building with settings different to the defaults. Typically a game team will need to decided on a minimum specification that they will target. Deciding on a minimum specifiction dictates the potential audience size for a project. This is an important decision for any game and it will be different for every project. mathbench doesn't want to make assumptions about what build settings any particular project may want to use which is why default settings are used.

I would encourage users who to use build settigs different to the defaults to run the benchmarks themselves and consider publishing their results.

Benchmark results

The following is a table of benchmarks produced by mathbench comparing glam performance to cgmath, nalgebra, euclid, vek, pathfinder_geometry, and ultraviolet on f32 data.

These benchmarks were performed on an AMD Ryzen 7 3800X CPU on Linux. They were compiled with the 1.99.0 (b940084d7 2026-09-28) Rust compiler. Lower (better) numbers are highlighted when the library is within -t percent (default 2.5) of the fastest in the row and the one-sided 95% interval for the difference rules out a slowdown larger than that margin, i.e. when the library is practically equivalent to the best.

The versions of the libraries tested were:

• cgmath - 0.18.0
• euclid - 0.22.14
• glam - 0.34.1
• nalgebra - 0.35.0
• pathfinder_geometry - 0.5.1
• ultraviolet - 0.10.0
• vek - 0.17.2

Scalar benchmarks

Run with the command:

cargo bench --features scalar scalar

benchmark	glam	cgmath	nalgebra	euclid	vek	pathfinder	ultraviolet
euler 2d x10000	5.163 us	5.116 us	7.093 us	5.124 us	5.158 us	5.894 us	5.121 us
euler 3d x10000	5.864 us	16.56 us	16.5 us	16.48 us	16.46 us	5.852 us	16.6 us
matrix2 determinant	1.0262 ns	1.1390 ns	1.1387 ns	N/A	1.1361 ns	1.1469 ns	1.1384 ns
matrix2 inverse	1.4776 ns	2.0499 ns	2.0399 ns	N/A	N/A	1.6476 ns	1.7388 ns
matrix2 mul matrix2	1.1531 ns	1.1030 ns	1.2088 ns	N/A	8.8631 ns	1.1403 ns	1.1052 ns
matrix2 mul vector2 x1	0.9283 ns	1.1561 ns	1.1906 ns	N/A	4.6570 ns	0.9584 ns	1.1698 ns
matrix2 mul vector2 x100	171.1991 ns	179.7413 ns	178.3703 ns	N/A	463.2815 ns	171.7605 ns	178.8623 ns
matrix2 no-op baseline	1.1184 ns	1.6710 ns	1.6165 ns	N/A	1.7853 ns	1.6190 ns	1.7241 ns
matrix2 transpose	1.2241 ns	1.3370 ns	1.3974 ns	N/A	0.9063 ns	N/A	0.8504 ns
matrix3 determinant	2.1892 ns	2.2352 ns	2.1973 ns	N/A	2.1650 ns	N/A	10.4218 ns
matrix3 inverse	5.3608 ns	9.0642 ns	5.6807 ns	N/A	N/A	N/A	12.2288 ns
matrix3 mul matrix3	4.6602 ns	5.6509 ns	4.4501 ns	N/A	36.7220 ns	N/A	4.5589 ns
matrix3 mul vector3 x1	2.1895 ns	3.4878 ns	2.1900 ns	N/A	12.7325 ns	N/A	2.3641 ns
matrix3 mul vector3 x100	0.3649 us	0.4132 us	0.3661 us	N/A	1.276 us	N/A	0.3659 us
matrix3 no-op baseline	2.9568 ns	2.9042 ns	2.8369 ns	N/A	2.8971 ns	N/A	2.9001 ns
matrix3 transpose	2.1894 ns	2.1891 ns	1.9596 ns	N/A	2.1792 ns	N/A	1.9453 ns
matrix4 determinant	4.3934 ns	7.1764 ns	40.9609 ns	11.2154 ns	12.2779 ns	N/A	4.6378 ns
matrix4 inverse	12.1455 ns	30.8124 ns	40.8410 ns	54.4792 ns	27.3142 ns	N/A	20.0627 ns
matrix4 mul matrix4	4.4589 ns	6.2970 ns	4.7309 ns	6.4629 ns	103.4461 ns	N/A	5.0440 ns
matrix4 mul vector4 x1	2.1002 ns	1.9625 ns	1.9185 ns	N/A	24.5601 ns	N/A	2.2970 ns
matrix4 mul vector4 x100	0.5092 us	0.5362 us	0.5379 us	N/A	2.491 us	N/A	0.5361 us
matrix4 no-op baseline	3.3286 ns	3.3602 ns	3.3612 ns	N/A	3.3757 ns	N/A	3.3850 ns
matrix4 transpose	2.7248 ns	7.6718 ns	7.7156 ns	N/A	7.6853 ns	N/A	7.6577 ns
ray-sphere intersection x10000	13.37 us	13.3 us	13.37 us	13.31 us	13.37 us	N/A	13.3 us
rotation3 inverse	1.6893 ns	2.5085 ns	2.5737 ns	2.5909 ns	2.4670 ns	N/A	2.5312 ns
rotation3 mul rotation3	1.8869 ns	2.6284 ns	2.4297 ns	3.4803 ns	3.0026 ns	N/A	3.2824 ns
rotation3 mul vector3 x1	3.1971 ns	2.9104 ns	3.3983 ns	3.1297 ns	5.1255 ns	N/A	4.3788 ns
rotation3 mul vector3 x100	347.7257 ns	307.8286 ns	349.4552 ns	346.2632 ns	506.3045 ns	N/A	431.1647 ns
rotation3 no-op baseline	1.4740 ns	1.7942 ns	1.8652 ns	N/A	1.7913 ns	N/A	1.8121 ns
transform point2 x1	1.0489 ns	2.0296 ns	2.4919 ns	1.3207 ns	4.4160 ns	1.0863 ns	1.8828 ns
transform point2 x100	268.6793 ns	335.3824 ns	357.9078 ns	233.8814 ns	501.7938 ns	268.9675 ns	331.0402 ns
transform point3 x1	1.9061 ns	15.0678 ns	4.0615 ns	3.3012 ns	12.3817 ns	2.0046 ns	3.5482 ns
transform point3 x100	0.4933 us	1.552 us	0.5895 us	0.5714 us	1.301 us	0.5015 us	0.5653 us
transform vector2 x1	0.9408 ns	N/A	2.0241 ns	1.2064 ns	8.6210 ns	N/A	1.3573 ns
transform vector2 x100	259.8743 ns	N/A	330.1703 ns	230.7005 ns	862.0694 ns	N/A	306.3204 ns
transform vector3 x1	1.9841 ns	11.6743 ns	2.7202 ns	2.2886 ns	18.1540 ns	N/A	2.7037 ns
transform vector3 x100	0.4938 us	1.19 us	0.5509 us	0.5109 us	1.906 us	N/A	0.522 us
transform2 inverse	2.2689 ns	N/A	5.6429 ns	2.9631 ns	N/A	2.5809 ns	N/A
transform2 mul transform2	2.1811 ns	N/A	4.3640 ns	1.9851 ns	N/A	2.1966 ns	N/A
transform2 no-op baseline	2.2848 ns	N/A	2.9137 ns	2.4864 ns	N/A	2.2808 ns	N/A
transform3 inverse	6.6932 ns	N/A	40.6221 ns	38.0707 ns	N/A	20.7270 ns	N/A
transform3 mul transform3d	3.5545 ns	N/A	4.8629 ns	6.3285 ns	N/A	4.4894 ns	N/A
transform3 no-op baseline	3.3643 ns	N/A	3.3640 ns	3.3515 ns	N/A	3.3487 ns	N/A
vector3 cross	1.0511 ns	1.5374 ns	1.5364 ns	1.5369 ns	1.5453 ns	N/A	1.5370 ns
vector3 dot	0.9757 ns	1.2293 ns	1.2324 ns	1.2385 ns	1.2313 ns	N/A	1.2214 ns
vector3 length	1.3147 ns	1.3128 ns	1.3205 ns	1.3079 ns	1.3108 ns	N/A	1.3091 ns
vector3 normalize	2.1971 ns	2.5868 ns	3.0146 ns	3.0183 ns	2.9928 ns	N/A	2.6405 ns
vector3 no-op baseline	1.0859 ns	1.9663 ns	1.9419 ns	N/A	1.9943 ns	N/A	2.1768 ns

Wide benchmarks

These benchmarks were performed on an AMD Ryzen 7 3800X CPU on Linux. They were compiled with the 1.99.0 (b940084d7 2026-09-28) Rust compiler. Lower (better) numbers are highlighted when the library is within -t percent (default 2.5) of the fastest in the row and the one-sided 95% interval for the difference rules out a slowdown larger than that margin, i.e. when the library is practically equivalent to the best.

The versions of the libraries tested were:

• glam - 0.34.1
• nalgebra - 0.35.0
• ultraviolet - 0.10.0

Run with the command:

RUSTFLAGS='-C target-feature=+avx2' cargo bench --features wide wide

benchmark	glam_f32x1	ultraviolet_f32x4	nalgebra_f32x4	ultraviolet_f32x8	nalgebra_f32x8
euler 2d x80000	41.87 us	25.65 us	25.59 us	18.94 us	18.57 us
euler 3d x80000	58.97 us	40.25 us	39.78 us	28.54 us	28.73 us
matrix2 determinant x16	12.3683 ns	5.0255 ns	N/A	3.6438 ns	N/A
matrix2 inverse x16	18.2726 ns	10.2942 ns	N/A	7.4352 ns	N/A
matrix2 mul matrix2 x16	16.4108 ns	10.9767 ns	11.0702 ns	9.2553 ns	9.3122 ns
matrix2 mul matrix2 x256	688.8713 ns	844.2290 ns	851.0381 ns	678.6878 ns	675.6790 ns
matrix2 mul vector2 x16	12.8488 ns	7.3729 ns	7.4172 ns	5.9231 ns	6.0974 ns
matrix2 mul vector2 x256	482.0150 ns	423.7576 ns	423.9817 ns	425.9341 ns	426.8713 ns
matrix2 transpose x16	9.8868 ns	40.2972 ns	34.4561 ns	11.6302 ns	9.0992 ns
matrix3 determinant x16	28.6072 ns	10.9073 ns	N/A	7.8069 ns	N/A
matrix3 inverse x16	96.2555 ns	38.6667 ns	N/A	22.0202 ns	N/A
matrix3 mul matrix3 x16	81.2391 ns	41.5798 ns	42.1062 ns	33.2499 ns	35.2442 ns
matrix3 mul matrix3 x256	1.619 us	1.615 us	1.656 us	1.551 us	1.582 us
matrix3 mul vector3 x16	34.1728 ns	13.8191 ns	13.7320 ns	9.7462 ns	10.6091 ns
matrix3 mul vector3 x256	954.4842 ns	789.3333 ns	792.1095 ns	779.5657 ns	776.0663 ns
matrix3 transpose x16	52.7683 ns	83.7157 ns	62.4901 ns	35.9252 ns	31.9769 ns
matrix4 determinant x16	62.0342 ns	20.9124 ns	N/A	14.6545 ns	N/A
matrix4 inverse x16	198.0560 ns	104.5414 ns	N/A	120.0865 ns	N/A
matrix4 mul matrix4 x16	163.5378 ns	207.9730 ns	198.9647 ns	167.0614 ns	204.1703 ns
matrix4 mul matrix4 x256	3.414 us	2.978 us	3.131 us	2.892 us	3.857 us
matrix4 mul vector4 x16	34.5807 ns	29.2073 ns	29.1650 ns	22.6779 ns	21.6758 ns
matrix4 mul vector4 x256	1.312 us	1.257 us	1.261 us	1.242 us	1.234 us
matrix4 transpose x16	73.5089 ns	93.7827 ns	89.3917 ns	96.3356 ns	87.0057 ns
ray-sphere intersection x80000	497.6 us	49.65 us	50.09 us	25.26 us	25.42 us
rotation3 inverse x16	9.8997 ns	9.4487 ns	9.4114 ns	7.3071 ns	6.9988 ns
rotation3 mul rotation3 x16	26.5663 ns	13.1697 ns	13.1350 ns	9.4821 ns	9.7145 ns
rotation3 mul vector3 x16	53.2221 ns	17.5765 ns	14.6217 ns	9.5778 ns	8.5011 ns
transform point2 x16	15.6934 ns	12.4223 ns	N/A	9.3164 ns	N/A
transform point2 x256	691.7836 ns	676.6860 ns	N/A	683.5775 ns	N/A
transform point3 x16	31.7974 ns	24.2547 ns	N/A	18.1546 ns	N/A
transform point3 x256	1.278 us	1.144 us	N/A	1.131 us	N/A
transform vector2 x16	13.4952 ns	10.1578 ns	N/A	9.0737 ns	N/A
transform vector2 x256	669.8862 ns	649.1890 ns	N/A	690.8455 ns	N/A
transform vector3 x16	30.0967 ns	21.6747 ns	N/A	18.1976 ns	N/A
transform vector3 x256	1.267 us	1.107 us	N/A	1.174 us	N/A
vector3 cross x16	15.2375 ns	8.9911 ns	8.8311 ns	7.6224 ns	7.4720 ns
vector3 dot x16	12.9763 ns	6.5773 ns	6.5842 ns	4.7245 ns	4.5946 ns
vector3 length x16	20.5391 ns	5.5195 ns	5.5261 ns	3.9270 ns	3.8417 ns
vector3 normalize x16	35.2002 ns	10.3503 ns	15.2167 ns	7.3365 ns	8.5396 ns

Running the benchmarks

The benchmarks use the criterion crate which works on stable Rust, they can be run with:

cargo bench

For the best results close other applications on the machine you are using to benchmark!

When running "wide" benchmarks, be sure you compile with with the appropriate target-features enabled, e.g. +avx2, for best results.

There is a script in scripts/summary.sh to summarize the results in a nice fashion. It prints the scalar benchmarks by default; pass -w for the wide benchmarks, or -w -s / -a to include both. -t sets the equivalence margin in percent used for highlighting (default 2.5). e.g. to include all libraries and both row kinds and generate an ASCII table:

./scripts/summary.sh -a

The wrapper creates a .venv in the repository root and installs the prettytable module into it on first use, so your system Python and its packages are left alone. Pass --help for the other options. If you would rather manage the environment yourself, scripts/summary.py is the script being run and only needs Python 3 and prettytable.

Before running the benchmarks, clear any previous results with rm -rf target/criterion.

Default and optional features

All libraries except for glam are optional for running benchmarks. The default features include cgmath, ultraviolet and nalgebra. These can be disabled with:

cargo bench --no-default-features

To selectively enable a specific default feature again use:

cargo bench --no-default-features --features nalgebra

Note that you can filter which benchmarks to run at runtime by using Criterion's filtering feature. For example, to only run scalar benchmarks and not wide ones, use:

cargo bench "scalar"

You can also get more granular. For example to only run wide matrix2 benchmarks, use:

cargo bench --features wide "wide matrix2"

or to only run the scalar "vec3 length" benchmark for glam, use:

cargo bench "scalar vec3 length/glam"

Crate features

There are a few extra features in addition to the direct features referring to each benchmarked library.

• ultraviolet_f32x4, ultraviolet_f32x8, nalgebra_f32x4, nalgebra_f32x8 - these each enable benchmarking specific wide types from each of ultraviolet or nalgebra.
• ultraviolet_wide, nalgebra_wide - these enable benchmarking all wide types from ultraviolet or nalgebra respectively.
• wide - enables all "wide" type benchmarks, these build on stable Rust.
• all - enables all supported libraries, including wide and scalar ones.

The ray-sphere intersection benchmark calls the per-element inner operation through a #[inline(never)] function. This keeps the autovectorizer from inlining it into the benchmark loop, so the benchmark measures the scalar, non-vectorized case, which is common in real code where the vectorizer cannot prove that vectorizing is safe.

Running the tests

The tests can be run using:

cargo test

Publishing results

When publishing benchmark results it is important to document the details of how the benchmarks were run, including:

• The version of mathbench used
• The versions of all libraries benched
• The Rust version
• The build settings used, especially when they differ from the defaults
• The specification of the hardware that was used
• The output of scripts/summary.sh
• The full Criterion output from target/criterion

Adding a new library

There are different steps involved for adding unit tests and benchmarks for a new library.

Benchmarks require an implementation of the mathbench::BenchValue trait for the types you want to benchmark. If a function returning your type (or a type convertible into it, such as a mint type) is available then you can use the impl_bench_value! macro in src/lib.rs, e.g. impl_bench_value!(glam::Vec3, random_mint_vec3). Otherwise implement BenchValue::random_value by hand.

To add the new library type to a benchmark, add a bench! arm for it in the relevant benches/*.rs file and call one of the bench_* macros from benches/support/macros.rs (for example bench_unop! for a single-operand operation or bench_binop! for a two-operand one). The bench! macro gates the benchmark on the library's Cargo feature.

Increment the version number of mathbench in Cargo.toml.

Update CHANGELOG.md.

Build times

mathbench also includes a tool for comparing full build times in tools/buildbench. Incremental build times are not measured as it would be non trivial to create a meaningful test across different math crates.

The buildbench tool uses the -Z timings feature of the nightly build of cargo, thus you need a nightly build to run it.

buildbench generates a Cargo.toml and empty src/lib.rs in a temporary directory for each library, recording some build time information which is included in the summary table below. The temporary directory is created every time the tool is run so this is a full build from a clean state.

Each library is only built once so you may wish to run buildbench multiple times to ensure results are consistent.

By default crates are built using the release profile with default features enabled. There are options for building the dev profile or without default features, see buildbench --help for more information.

The columns outputted include the total build time, the self build time which is the time it took to build the crate on it's own excluding dependencies, and the number of units which is the number of dependencies (this will be 2 at minimum).

When comparing build times keep in mind that each library has different feature sets and that naturally larger libraries will take longer to build. For many crates tested the dependencies take longer than the math crate. Also keep in mind if you are already building one of the dependencies in your project you won't pay the build cost twice (unless it's a different version).

crate	version	total (s)	self (s)	units
cgmath	0.17.0	6.8	3.0	17
euclid	0.22.1	3.4	1.0	4
glam	0.9.4	1.1	0.6	2
nalgebra	0.22.0	24.2	18.0	24
pathfinder_geometry	0.5.1	3.0	0.3	8
ultraviolet	0.5.1	2.5	1.3	4
vek	0.12.0	34.4	10.1	16

These benchmarks were performed on an AMD Ryzen 7 3800X CPU with 32GB RAM on Linux.

License

Licensed under either of

• Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Contribution

Contributions in any form (issues, pull requests, etc.) to this project must adhere to Rust's Code of Conduct.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Support

If you are interested in contributing or have a request or suggestion create an issue on github.