kcsrk

6 ms·

1.
by kcsrk 3mo ago
We don't even have the capability to build a _32-bit_ Unikernel now! That said, we _can_ boot 64-bit MirageOS unikernels on baremetal platforms. We use this capability in FIDES, which boots MirageOS unikernels on a bare-metal, security
2.
by kcsrk 3mo ago
Super interesting. Thanks for sharing. I have used Jupyter notebooks with a Docker deployment in my prior courses for OCaml and Prolog, with support for auto grading (using nbgrader). Jupyter notebooks aren’t great for version control. Othe
3.
by kcsrk 3mo ago
Author of the post here. I need a Linux VM to illustrate a couple of things in the last few lectures. Showing C undefined behaviour, memory safety issues and how that becomes security issues, compiling OCaml program to show test coverage, a
4.
by kcsrk 4mo ago
What’s surprised me in the last few months is that agents are great at producing OCaml 5+ and OxCaml code, not much of which is out there in the training data. OxCaml’s strong types and modes seem to serve as great testable oracles to guide
5.
by kcsrk 10mo ago
Not necessarily. You can implement them using a monad. See https://dl.acm.org/doi/10.1145/2804302.2804319 . That said, in GHC Haskell the implementation on top of stack switching seems to outperform other implement
6.
by kcsrk 1y ago
It was overlooked because I didn't know! Great to hear about virt-v2v. I will reach out to you by email.
7.
by kcsrk 1y ago
It is often hard to see the shape of these things before a serious PR attempt is made. Each of the PRs reveals more of the shape of the problem being solved. Hard to skip them in practice, especially for new contributors.
8.
by kcsrk 1y ago
You are right that the dynamic arrays story does not read like a straightforward “how to inspire contributions.” But part of what I wanted to do in the talk was to show things as they actually unfolded. In OCaml compiler development, there
9.
by kcsrk 1y ago
I am the author of the talk here o/. This talk is a _subjective_ take on how the OCaml programming language evolves, based on my observations over the last 10 years I've been involved with it. My aim/hope is to demystify the
10.
by kcsrk 1y ago
Kcas is the Haskell STM analogue in OCaml https://github.com/ocaml-multicore/kcas/
11.
Data Race Free OCaml(github.com)
2 points by kcsrk 3y ago|0 comments
12.
by kcsrk 4y ago
Right. It is hard in general to compare performance or generated code across languages as they make different trade offs. Table 3 and 5 show compilation of our memory model to X86 and ARMv7. The compilation and the related work section disc
13.
by kcsrk 4y ago
See examples in the second section and the results in the paper: https://kcsrk.info/papers/pldi18-memory.pdf
14.
by kcsrk 4y ago
Still early days, but I had done some exploratory work in the past on Reagents, a composable lock-free library [1]. Now that OCaml 5 is released, we're reviving this work. It's semantics is weaker than STM -- unlike STM, it doesn&
15.
by kcsrk 4y ago
The local types are less invasive than the full support for typed effects. In particular, they are opt-in and associated complexity is pay-as-you-go. In my initial experiments, they seemed pretty nice to program with.
16.
by kcsrk 4y ago
Here are some parallel benchmarks from the Sandmark continuous benchmarking service: https://sandmark.tarides.com/?app=Parallel+Benchmarks&parall...
17.
by kcsrk 4y ago
Rather than a full effect system, we're very likely to have lexically scoped "checked" effects with the help of modal types. I briefly talked about it at the end of my ICFP keynote: https://icfp22.sigplan.org/
18.
by kcsrk 4y ago
For nested parallel computations (think Scientific Programming, where one would use OpenMP, Rust Rayon, etc), we have domainslib [1]. Eio, a direct-style, effect-based IO library is pretty competitive against Rust Tokio [2]. The performance
19.
by kcsrk 4y ago
Parallelism [1] and native-support for concurrency through effect handlers [2]. [1] https://kcsrk.info/webman/manual/parallelism.html [2] https://kcsrk.info/webman/manual/effects.html
20.
by kcsrk 4y ago
I would also recommend reading the effect handlers tutorial in OCaml 5.0 manual: https://kcsrk.info/webman/manual/effects.html .
21.
by kcsrk 5y ago
> it seems it provides sequential consistency when using atomics and acquire/release semantics when not. (author of the said paper here) This is wrong. I suggest reading the paper closely. If not, the morning paper has a good summar
22.
by kcsrk 5y ago
Effect handlers are a foundation of all non-local control flow abstractions. Anything that requires fancy control-flow can be implemented with effect handlers. This includes green threads, async/await, generators (or iterators as some
23.
by kcsrk 5y ago
We don't compare against Go pervasively. Benchmarking across languages is hard generally, but here is a result on a specific benchmark comparing several versions of OCaml benchmarks against Go and Rust on a Http server benchmark: http
24.
by kcsrk 5y ago
Yes, exactly. The reason why monadic concurrency libraries such as Lwt and Async is that the OCaml language does not support concurrency natively. If it did, we would have built something similar to the `ocaml-aeio` library. Btw there is a
25.
by kcsrk 5y ago
Abandoned is perhaps too strong a term :-). Effect handlers in the language are supported by fibers, lightweight stacklets managed by the runtime. The details of the implementation can be found in the upcoming research paper in PLDI'21
26.
by kcsrk 5y ago
(One of the Multicore OCaml devs here) We have prototyped offloading CPU intensive computations in Lwt programs using Multicore OCaml [1]. We're currently working with Lwt maintainers to upstream it. [1] https://sudha247.git
27.
by kcsrk 5y ago
(One of the authors of the mentioned paper [1]) Firstly, if you are using high-level synchronisation mechanisms such as mutexes and condition variables, or higher-level concurreny libraries such as java.util.concurrent, you shouldn't w
28.
by kcsrk 6y ago
Having optimised the Multicore OCaml implementation, this benchmark benefits heavily from inlining and unboxing. MLton style aggressive inlining and unboxing is the way to go here. MPL builds on MLton and it works out great! Multicore OCaml
29.
by kcsrk 6y ago
> but these are unlikely to scale as well under ParMinor To be clear, the said systems programs are not going to see slowdown when run in a sequential setting (which is what I expect the majority of use cases will be). It is unlikely tha
30.
by kcsrk 6y ago
No breaking changes with the parallel minor collector (ParMinor). This is the design which will be upstreamed. See https://arxiv.org/pdf/2004.11663.pdf for details.

More ›