Skip to content

v0.2.2

Choose a tag to compare

@gbletr42 gbletr42 released this 17 Mar 08:53
· 167 commits to master since this release
afa5434

This version is mostly the same as before, as I haven't felt bothered to add new features to the format. Main differences are vastly improved performance, due to a couple optimizations in both the internal library and the stolen zfec code. For both the liberasurecode and zfec backends, throughput has roughly doubled, though mind you that is with AVX2 optimizations. Also added in a verbosity flag.

Current benchmarks (from my terrible laptop CPU) roughly are (from bef -c -p $preset -P $parity -i /dev/zero | pv >/dev/null), not including cauchy ones as they're roughly equal in performance anyways

  • fec-vand: 870MiB/s
  • fec-vand (paranoid preset): 470MiB/s
  • jerasure-vand: 700MiB/s
  • jerasure-vand (paranoid preset): 300MiB/s
  • liberasurecode-vand: 600MiB/s
  • liberasurecode-vand (paranoid preset): 70MiB/s
  • intel-vand: 670MiB/s
  • intel-vand (paranoid preset): 500MiB/s

Ideas for future release v0.3 would be to look back into the concept of convolutional code support, see if I can make a wrapper around GNU Radio or AFF3CT or something like that, and add full convolutional code support as the first extension to the format. This would provide protection against random noise (say every other byte has a bit flip) at the cost of a vastly larger file size, so it would be a good option for some folks.

Outside of that, I don't have many ideas for improvement, it's a pretty simple protocol and its supposed to be simple. The next best thing would be to add an optional seekable mode that acts more like PAR2 rather than what it acts like now, but I feel like par2cmdline-turbo is good enough at that and I should expand more into being a good unix-style pipe program instead.

Benchmarks in the future will come from a container on a Xeon machine, as I'm fairly convinced this laptop is on its way out...