From 45bbcb4bfa30c238114764be25ade5d058a13337 Mon Sep 17 00:00:00 2001 From: "Christopher A. Taylor" Date: Sun, 4 Jun 2017 21:31:32 -0700 Subject: [PATCH] Update README.md --- README.md | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 5ce1962..a04598f 100644 --- a/README.md +++ b/README.md @@ -15,16 +15,6 @@ fastest finite fields (8-bit or 16-bit Galois fields with Cantor basis {2}). It sets new speed records for MDS encoding and decoding of large data, achieving over 1.2 GB/s to encode with the AVX2 instruction set on a single core. -There is another library `FastECC` by Bulat-Ziganshin that should have similar performance: -[https://github.com/Bulat-Ziganshin/FastECC](https://github.com/Bulat-Ziganshin/FastECC). -Both libraries implement the same high-level algorithm in {3}, while Leopard implements the -newer polynomial basis GF(2^r) approach outlined in {1}, and FastECC uses complex finite fields -modulo special primes. There are trade-offs that may make either approach preferable based -on the application: -+ Older processors do not support SSSE3 and FastECC supports these processors better. -+ FastECC supports data sets above 65,536 pieces as it uses 32-bit finite field math. -+ Leopard does not require expanding the input or output data to make it fit in the field, so it can be more space efficient. - Example applications are data recovery software and data center replication. @@ -79,6 +69,19 @@ More benchmark results are available here: [https://github.com/catid/leopard/blob/master/Benchmarks.md](https://github.com/catid/leopard/blob/master/Benchmarks.md) +#### Comparisons: + +There is another library `FastECC` by Bulat-Ziganshin that should have similar performance: +[https://github.com/Bulat-Ziganshin/FastECC](https://github.com/Bulat-Ziganshin/FastECC). +Both libraries implement the same high-level algorithm in {3}, while Leopard implements the +newer polynomial basis GF(2^r) approach outlined in {1}, and FastECC uses complex finite fields +modulo special primes. There are trade-offs that may make either approach preferable based +on the application: ++ Older processors do not support SSSE3 and FastECC supports these processors better. ++ FastECC supports data sets above 65,536 pieces as it uses 32-bit finite field math. ++ Leopard does not require expanding the input or output data to make it fit in the field, so it can be more space efficient. + + #### FFT Data Layout: We pack the data into memory in this order: