Reorganize modes -safe, -fast, -faster about bisect_ppx HOT 4 CLOSED

Without quoting...

1. As far as I've tested it, yes, -fast is much faster than -safe. Around an order of magnitude (minutes -> seconds) on Oml and Ketrew. I think the -safe is mostly legacy, I've kept it around for backward compatibility. I've never found an instance where they diverged, but I've only spot checked the test suite and the projects where I've applied the switch. If you want to just have one mode that is canonical and "just works", I am all in favor of jettisoning -safe and changing -faster.
2. A performance test is a good idea, but not required. The improvement is noticeable.
3. A race condition test is probably a good idea, we had a bug dealing with OUnit threads a couple of months ago.
4. I don't know how people use the Bisect_ppx counts. I think of this as a library to help in testing infrastructure, so I don't think of it as being that performance critical, but having accurate counts as being more valuable. One certainly would want to know if a count is not what you expect (which just might be zero). My preference would be for just one mode that does the counting correctly and get rid of the different modes entirely, ie your -numeric. Perhaps we can keep the -fast mode but with separate arrays (that are created as needed) per thread, to avoid the blocking. I don't know too much about ocaml.ppx.context

from bisect_ppx.

I agree with your preference.

The one mode should be the current -faster, i.e. per-module arrays and no locks. We can maintain the other flags and just ignore them. Here is why:

Relative to current OCaml:

• There is no pre-emption AFAICT in bytecode or native code unless you allocate or do I/O, so -faster and -fast are inherently thread-safe. Ironically, -safe is the only mode that was ever unsafe, but only if you have a large number of points and have to resize arrays (haven't verified this).
• I think this is true no matter what libraries or configurations you are using.

Relative to future OCaml:

• I need to read up on this, but I think multicore will allow concurrent execution of our counting code, but still will not allow pre-emption of a thread that is already running on a core during count update. Then, as long as multicore also provides atomic compare-and-exchange, we should be able to wrap counts in spin locks, or find another method of fast mutual exclusion. Then, we should be able to make the code always thread-safe in one mode without a significant performance hit.
• In any case, we don't know exactly what there will be so I think we shouldn't try to solve this now.
• On the other hand, we are well prepared to solve it quickly when it's time, since we will have this experience and the thread safety test.

from bisect_ppx.

Reasonable.

from bisect_ppx.

Actually, it occurs to me that running on ocamljava probably requires the locks, though I am not sure if it worked there, since BisectThread required Mutex, and I don't see Mutex in any of the docs. Thoughts?

from bisect_ppx.