Switch to actor model about ocaml-seqbox HOT 7 CLOSED

Encode module is now using actor-based concurrency using Lwt, and is ~50% slower...

Maybe I should move to Rust or wait a few years for multicore ocaml.

from ocaml-seqbox.

@darrenldl did you use profiling to discover where the bottleneck is? OCaml can be reasonably fast if tweaked... (sorry, I haven't read through your seqbox code)

from ocaml-seqbox.

@hannesm All good, the code's really rough atm anyway(still looks much better than the old code tho, albeit slower).

I did some testing with different data structures (flipping between Lwt_mvar and Lwt_queue)
(Lwt_queue is just a ring buffer implemented using array and condition variable)
But I didn't do proper profiling with tools, only relied on the progress text printing which reports the rate.

The current arrangement of the encoder internals

---------------               -----------               ---------------
| File reader | --Lwt_mvar--> | Encoder | --Lwt_mvar--> | File writer |
|             |     (1)       |         |     (2)       |             |
---------------               -----------               ---------------

The Lwt_queue variant is just Lwt_mvar with Lwt_queue swapped

Statistics (using defaults, this means data size = 496 bytes, hash = SHA256)

Progress reporting text didn't seem to have any impact on the performance, so just I placed a call next to where the block is created in Lwt implementations.

Description

Sequential

The sequential implementation is just a single chain of tail positioned function calls.

Lwt

For Lwt implementation, each internal component in is made from a generating function (returns a function of type : unit -> something Lwt.t, e.g. gen_encoder at encode.ml, gen_file_reader, gen_file_writer at actors.ml).

The generated threads first wait on a waiter thread, then the waiter thread is woken up to kick start the encoding process.

from ocaml-seqbox.

My original intuition was that using Lwt would speed things up since the encoder doesn't have to wait for file IO, but that wasn't entirely right I suppose.

My guess is that the sequential implementation was better optimized since it's just a statically written chain of tail position function calls, while a lot of anonymous functions are used in Lwt version implementation.

But I have almost zero background on compilers and language and runtimes, so I'm probably very wrong.

Currently I'm still very attached to OCaml rather than Rust mainly due to Coq, and also Rust doesn't support tail call optimization. If only Ada has a much larger FOSS community, hmm...

from ocaml-seqbox.

@hannesm I did more tests today with more useful results, namely disabling some code of encoder

The setup is still the same, with connections (1) and (2) both being Lwt_mvar, may switch back to Lwt_queue later for consistency but doesn't seem to matter

Statistics

I noticed the data packing function(which converts 496 bytes of data to a sbx block) can be optimized, I'll post the results after optimization for both the sequential implementation and Lwt implementation.

The issue with delay in hashing and data packing may still persist since there's no way to run code in parallel yet. The hashing part was previously done in another actor, but it has the same level of performance, probably due to above reason.

from ocaml-seqbox.

After a lot of optimizations, the rate sits at around 90K blocks/sec

I'm gonna leave Reed-Solomon support to a Rust rewrite of osbx, if I am ever going to do that

from ocaml-seqbox.

Development effort now directed towards rsbx.

Osbx is now under maintenance mode.

Closing all issues related to adding features.

from ocaml-seqbox.