mirror of https://github.com/status-im/leopard.git
Update README.md
This commit is contained in:
parent
48bb280858
commit
45bbcb4bfa
23
README.md
23
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,
|
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.
|
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.
|
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)
|
[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:
|
#### FFT Data Layout:
|
||||||
|
|
||||||
We pack the data into memory in this order:
|
We pack the data into memory in this order:
|
||||||
|
|
Loading…
Reference in New Issue