Use one read thread and one write thread

[dzamlo]

On my machine, when benchmarking withe the provided docker image (make build && make run) show a significant speed improvement. Other small benchmarking seems to show a very small improvement.

[mre]

To know if this change improves performance, it would be nice to have automated benchmarks. @vbrandl is working on the travis setup. Once he's done, we could add pv to travis, create a large file (e.g. 2GB of /dev/urandom using dd) and read it a few times with cat and fcat. (I would also use cat in order to have a baseline, because measurements could be flaky depending on how busy travis is.)

[ArniDagur]

@mre I recall testing this and seeing a performance increase. What is the state of this PR?

[mre]

Hey @ArniDagur,

this PR was lying dormant for a while. Thanks for the ping. I haven't gotten around to testing it, but if you like you could provide some benchmark data to show that it's faster. The simplest way would be using time fcat on a big file and comparing the times. A more sophisticated way would be adding a benchmark test to the project and posting the results.

Would you be willing to work on that? 😊

[ArniDagur]

Multithreaded seems to actually be slower on my laptop for a 2 gigabyte file:

[arni@arni-pc][/tmp]% time ./fcat largefile > /dev/null
./fcat largefile > /dev/null  0.06s user 0.23s system 99% cpu 0.290 total
[arni@arni-pc][/tmp]% time ./fcat largefile > /dev/null
./fcat largefile > /dev/null  0.04s user 0.18s system 99% cpu 0.215 total
[arni@arni-pc][/tmp]% time ./fcat largefile > /dev/null
./fcat largefile > /dev/null  0.04s user 0.25s system 99% cpu 0.295 total
[arni@arni-pc][/tmp]% time ./fcat-multithreaded largefile > /dev/null
./fcat-multithreaded largefile > /dev/null  0.05s user 0.70s system 198% cpu 0.381 total
[arni@arni-pc][/tmp]% time ./fcat-multithreaded largefile > /dev/null
./fcat-multithreaded largefile > /dev/null  0.06s user 0.70s system 197% cpu 0.383 total
[arni@arni-pc][/tmp]% time ./fcat-multithreaded largefile > /dev/null
./fcat-multithreaded largefile > /dev/null  0.07s user 0.69s system 197% cpu 0.385 total
[arni@arni-pc][/tmp]% time ./fcat largefile > /dev/null
./fcat largefile > /dev/null  0.05s user 0.25s system 99% cpu 0.305 total
[arni@arni-pc][/tmp]% time ./fcat largefile > /dev/null
./fcat largefile > /dev/null  0.06s user 0.24s system 99% cpu 0.300 total
[arni@arni-pc][/tmp]% time ./fcat largefile > /dev/null
./fcat largefile > /dev/null  0.07s user 0.23s system 99% cpu 0.301 total
[arni@arni-pc][/tmp]% time ./fcat-multithreaded largefile > /dev/null
./fcat-multithreaded largefile > /dev/null  0.07s user 0.59s system 196% cpu 0.337 total
[arni@arni-pc][/tmp]% time ./fcat-multithreaded largefile > /dev/null
./fcat-multithreaded largefile > /dev/null  0.08s user 0.68s system 197% cpu 0.387 total
[arni@arni-pc][/tmp]% time ./fcat-multithreaded largefile > /dev/null
./fcat-multithreaded largefile > /dev/null  0.08s user 0.68s system 197% cpu 0.388 total

[vbrandl]

Maybe using lightweight threads (e.g. rayon) over full blown OS threads might help improve the performance?