gadmm

5 ms·

1.
Safety in an Unsafe World(lwn.net)
3 points by gadmm 2y ago|0 comments
2.
by gadmm 3y ago
#9 (downgrading mut refs to shared refs) is a big one. It makes things quite a bit more complicated in the context of our work on the OCaml-Rust interface (more precisely the safe interface for the GC). As I understand it, this is not a sac
3.
by gadmm 3y ago
The question is whether the user replacing `f(value)` with `if value == expected then f(expected) else f(value)` preserves program semantics. Look for Address dependency in Arm: see e.g. https://developer.arm.com/documentati
4.
by gadmm 3y ago
This is about the classic trick of speculating on values using branch prediction (if value == expected then f(expected) else f(value)), which is always fun to see. But be careful in OCaml, as the memory model relies on the memory ordering o
5.
by gadmm 4y ago
To clear up any misconception, out of the box OCaml will behave like OCaml 4 with a single domain and a "domain lock". Programs currently using multiple threads for concurrency will remain single-core for the time being, as they w
6.
by gadmm 4y ago
The development of the OCaml-Rust interface is a bit organic. `ocaml-interop` aims to be a low-level but safe interface. At Inria we worked with the author to integrate ideas about using Rust's type system to safely work with a GC. We
7.
by gadmm 5y ago
Baker's paper is visionary in that it announces a link between linear logic and move semantics for resources more than a decade in advance. As we know this was put into practice by C++ and Rust. Compared to linear types, it amounts to
8.
by gadmm 5y ago
According to the paper “any compiler optimisation that breaks the load-to-store ordering is disallowed.”
9.
by gadmm 5y ago
The "huge performance gains" refers to the prefetching optimisation, which is already in OCaml (the old OCaml 4 branch, not in multicore yet).
10.
by gadmm 5y ago
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 perfor
11.
Memory Management with Stephen Dolan (OCaml)(signalsandthreads.com)
3 points by gadmm 5y ago|0 comments
12.
Does the Bronze GC Make Rust Easier to Use? A Controlled Experiment(arxiv.org)
3 points by gadmm 5y ago|2 comments
13.
A program for the full axiom of choice(lmcs.episciences.org)
3 points by gadmm 5y ago|0 comments
14.
by gadmm 5y ago
We taught Rust at Masters-level as part of a course meant to show engineering students a variety of concepts from innovative programming language (there was also Haskell and Scala). Learning Rust is a must (at least for our kind of students
15.
by gadmm 6y ago
Indeed, OCaml multicore preserves the sequential low-latency setting, and this is important. Generalising this style is indeed a challenge, and I believe that there is something to learn from those expert cases. I do not find realistic the
16.
by gadmm 6y ago
Regarding latency, beyond the kind of benchmarks proposed in the paper (from which this performance claim comes), keep in mind that the behaviour is qualitatively different between the two alternatives. Systems programmers in OCaml can appl
17.
Featherweight Go (A generics design for Go)(arxiv.org)
4 points by gadmm 6y ago|0 comments