Issues with multithreaded code and CPU dispatching. about base64 HOT 3 OPEN

Hi, thanks for raising this issue. Always interesting to get some perspective from a library user. I'll address your points specifically below, but first I want to clarify the design philosophy behind this library. It runs a bit counter to the way you intend to use it.

The concept behind this library is "compile once, run anywhere". It was intended to be compiled for all the SIMD architectures that the compiler will support, and then at runtime, use CPU feature detection to decide which codecs to actually use. This should make the library portable across all similar architectures, and make it distributable as part of a package system or binary distribution. This benefit trickles down to the user if they also distribute their software through a centralized repo.

The optimization focus in this library is not multithreaded, but multicore. It supports OpenMP, which greatly accelerates encoding and decoding of large pieces of data. (But I think you raise a valid point here. The library should assume that it can be called from multiple threads, and not share common state.)

Are these good design principles? Perhaps not, and I'm personally a bit unhappy with the early decision to implement my own CPU dispatcher, but that's the way things currently stand. I do have some future plans to allow the user to do their own CPU dispatching and call architecture-specific codecs directly, but they won't be finished in the short term.

There is indeed a user flags option to force a codec, but this is a bit of a misfeature. The flags are mainly there as a testing tool so that I can run a specific individual codec for testing and benchmarking. The idea was that end users should not be using the flags, they should be using runtime CPU detection. I recognize that it's not the best choice in hindsight, and intend to fix it, but here we are.

As to the specific points:

1. Indeed, if you are passing flags to the codecs, they will be forced to re-evaluate the current codec. I suppose this could be fixed by storing the previous flags value in a static variable and seeing if it changed. The functions always need to check the flags on the off chance that the user changed them, so the branch can't be avoided. Unless the library gets a separate init function, which I tried to avoid because it's not ergonomic. (Maybe there's a way to get the best of both worlds with some sort of optional init function?)

2. If it's silly but it works, it's not silly. The library does not have a separate init method, because it's not needed for the nominal use case. Codecs are initialized on the first run. For the multithreaded case, I think it should be enough to change this line to:

static __thread struct codec codec = { NULL, NULL };

This will make codec thread-local. You can apply this trick for point 1 too if you want to get rid of global state. I'll think about adding it to the library directly, if there's a portable way to do so.

3. Indeed, you'll need to patch the library to make that work. It's not optimized for super short inputs and outputs. You'd probably be better off with a simple table-based approach in those cases anyway. (Btw, I just resolved #64, which speeds up the encoder for short inputs.)

I think this library could be made to fit your use-case, but as you see there are some different tradeoffs in play which would require either some redesign on my end (slow, unfortunately), or patching from your end. I'm open to suggestions on how and where to improve.

from base64.

Thank you for the answer! The question is resolved.

from base64.

To be honest I wouldn't mind if you got rid of the mutex and would use thread local for the codec. In a HPC environment you can have 200 cores doing the same thing, which in this case would cause a huge perf hit because of false sharing, and I'm not keen on maintaining a separate fork. This also why I hope that eventually you'll merge the CMake build, we'll probably use it as a library, one other thing I'm not keen about maintaining :).

from base64.