Re: [fluid-dev] parallel loading of soundfont samples

[Tom M.]

> So in my opinion, doing the work to make the sample cache and maybe
even the whole soundfont loading mechanism work in parallel seems like
a good idea and worth the effort.

We need to be careful, as the soundfont loading is exposed via the API.
Breaking changes should be avoided. Also, we could easily run into
premature optimization: I don't think it would be worth to parallelize
the loading of SF2 files, as they are IO-bound.

That's why I vote to concentrate on SF3 in a first step. That is, before
rewriting everything, find out how we can use the existing architecture.
As we saw, the problem currently is the shared sffd file pointer. What
we need is a way to store the read/write file pointers directly in the
sfvio_data_t struct.

To do this, I suggest we drop the idea of using fopen() and friends, and
directly mmap() the file. (We'll surely find an equivalent
implementation for Win32).

Using pure char* under the hood allows us to keep track of their seek
offsets (given by sfvio_seek()) individually for each thread.

And ofc, the public sfloader API would remain unchanged by this.


Also, we need to clarify the parallelization framework to use. I vote
for using OpenMP Tasks. This requires an OpenMP 3.0 compliant compiler.
All modern compilers fulfill that... except Visual Studio, whose support
for C and OpenMP dates back 20 years ago.

As alternative we have hand-written thread handling stuff provided by
glib or C++11. Frankly, I don't think this is worth the effort.


Tom