News for hackers. Stuff that matters.
Re:OCaml Multicore merged upstream by tialaramex on Monday January 10, 2022 @11:17AM (#29877066)
Interesting. As I understand it, this lands an approach in which Sequential Consistency is not guaranteed but if you have a data race you get even nicer guarantees than in Java and its authors believe this might be enough that real programmers working on real software can actually debug data races despite loss of sequential consistency.

In many popular languages today (e.g. C++) if you have a data race you're completely screwed, (e.g. the program exits successfully, even though it was supposed to loop forever serving TCP requests - good luck figuring out why). In Java they decided OK, that's not acceptable, so data races are constrained to only the data touched by the race and, importantly, that data is still legal it just might be astonishing (e.g. you were adding several small positive integers together from a shared data structure in parallel, but due to a misunderstanding in your design this was actually a data race, and some time later somehow your total is now zero, but you won't crash or whatever)

OCaml intends to further constrain the consequences in time, if the total was 114 when you stopped adding, it will still be 114 later, it won't mysteriously become zero (or any other value) thanks to a data race which must have happened before you checked.

[I'm sure I have some details wrong, but this is the gist]

What remains to be seen is: Is that enough? There was great hope when Java made its rules that they were enough and programmers could understand what was wrong in a Java program with data races, that did not pan out as I understand it. So, it seems to me that it's possible OCaml ends up in the same situation.

Re:OCaml Multicore merged upstream by tyre on Monday January 10, 2022 @12:21PM (#29878117)
> e.g. you were adding several small positive integers together from a shared data structure in parallel, but due to a misunderstanding in your design this was actually a data race, and some time later somehow your total is now zero

Could you clarify why/how this would happen? Is it because the last process sets it to zero to initialize a variable?

I can’t conceptualize the steps that would end up with this result if all processes are adding. It seems like it would at least equal the result of the final thread’s calculation.

Re:OCaml Multicore merged upstream by zamadatix on Monday January 10, 2022 @12:52PM (#29878634)
Non aligned data structures being written to. E.g. if you're adding 2 nibbles and writing it to the first part of a byte or writing a byte on a packed struct.
Re:OCaml Multicore merged upstream by ackfoobar on Monday January 10, 2022 @11:31AM (#29877305)
I believe the less scary race in Java implies a lower performance upper bound. Does the nicer guarantees in multicore OCaml have the same drawback? I.e. even less than Java?
Re:OCaml Multicore merged upstream by avsm on Monday January 10, 2022 @11:40AM (#29877453)
(co-author of the OCaml memory model paper here)

The details of the 'LDRF' (local data race freedom) property are described in detail here: https://anil.recoil.org/papers/2018-pldi-memorymodel.pdf

The performance numbers are in the paper abstract: "our evaluation demonstrates that it is possible to balance a comprehensible memory model with a reasonable (no overhead on x86, ~0.6% on ARM) sequential performance trade-off in a mainstream programming language". It's a little higher on PowerPC but still very usable, and RISC-V overheads should be roughly comparable to ARM.

Re:OCaml Multicore merged upstream by gadmm on Monday January 10, 2022 @11:46AM (#29877545)
As the paper clarifies, this is for the performance of non-atomic read/writes in sequential setting. The paper left the performance evaluation for atomic read/writes to future work. Is there any indication yet regarding the performance in a parallel setting compared to weaker guarantees?
Re:OCaml Multicore merged upstream by avsm on Monday January 10, 2022 @11:50AM (#29877601)
That's right -- we first wanted to establish that existing OCaml code wouldn't be adversely impacted. There are various efforts ongoing to build interested (locked and lock-free) concurrent data structures, so that will inform the parallel performance results. Nothing published yet.
Re:OCaml Multicore merged upstream by nextaccountic on Monday January 10, 2022 @12:18PM (#29878061)
Does this feature inhibit any kind of optimization that current compilers could perform?
Re:OCaml Multicore merged upstream by gadmm on Monday January 10, 2022 @03:36PM (#29881931)
According to the paper “any compiler optimisation that breaks the load-to-store ordering is disallowed.”
Re:OCaml Multicore merged upstream by Traubenfuchs on Monday January 10, 2022 @12:37PM (#29878377)
If you use Atomic* classes and the available concurrent standard lib datastructures, Java concurrency should not be an issue to any non-junior developer.