4 ms·

Isn't OCAML garbage collected, which should be too slow and memory hungry for system drivers.

by alde 8y ago

deleted 8y ago
[deleted]
tom_mellior 8y ago
MirageOS (https://mirage.io/ https://mirage.io/) has everything written in OCaml, and they don't seem to find it too slow.
- qop 8y ago
  But if I understand correctly (I've never used mirage) mirage is a unikernel for ocaml applications. It compiles down to xen system calls, for monitoring and administration. Mirage isn't actually an implementation of an OS in the traditional sense. Ocaml is of course already fast. INRIA has been using ocaml for compiler hacking for several decades. The speed comes as no surprise, but eventually rust will have inline assembly support, it's already nurturing some basic SIMD features, it is already being turned for lower level dominance. I think ocaml could compete, but not the way it is now. With linear types in the future, perhaps ocaml could follow rust's lead and implement a memory model around move semantics. I'm not an expert in this area, but I do perceive a nontrivial gap here. Ocaml is not built for writing system drivers. And a good system driver is written in something that was designed to be used for doing so, imo.
  - pjmlp 8y ago
    Oberon and Blue Bottle drivers written in Oberon and Active Oberon respectively. http://www.projectoberon.com http://www.projectoberon.com https://svn.inf.ethz.ch/svn/lecturers/a2/trunk/ https://svn.inf.ethz.ch/svn/lecturers/a2/trunk/ Mirage TCP/IP drivers https://github.com/mirage/mirage-tcpip https://github.com/mirage/mirage-tcpip
  - steveklabnik 8y ago
    Sounds like you may like https://news.ycombinator.com/item?id=16597329 https://news.ycombinator.com/item?id=16597329
- monocasa 8y ago
  'Slow' is a loaded term with a lot of different definitions. In terms of throughput, there's nothing wrong with a garbage collector, but in terms of latency (particularly 95+ percentile) you're never going to be able touch 'manually' (I'm including Rust here) managing the heap. Even Azul's 'pauseless' gc only guarantees something like 10ms max pauses. That's an eternity for a lot of use cases.
  - tom_mellior 8y ago
    In a lot of use cases, like the drivers mentioned above, you shouldn't allocate on the heap anyway, whether manually or in a managed way. And if you don't allocate, you never need to garbage collect (since you never need to reclaim memory to make it available for new allocations). In that case, the two are even. (The above assumes that GC is only triggered by allocations. Many GCs are like that, but others trigger periodically even if there isn't anything to do. I don't know which group OCaml is in.)
    - monocasa 8y ago
      You heap allocate all the time in drivers. You just shouldn't do it from interrupt context. Source: I write plenty of drivers for a living. And even if the GC is only triggered by allocations, they'll still pause the other contexts in order to scan their stacks for live references. So, in the case of a unikernel, you can end up with critical paths being paused by allocations outside the critical path.
      - wtetzner 8y ago
        > And even if the GC is only triggered by allocations, they'll still pause the other contexts in order to scan their stacks for live references. If the GC is only triggered on allocations when there isn't enough free heap space, then why would stack scans happen at other times?
        monocasa 8y ago
        For a driver, you have many contexts you're running. That's what the windows error "IRQL not less than or equal" blue screen means, that someone called a regular kernel function from within interrupt context. In drivers, you almost always heap allocate in your non interrupt contexts in order to dynamically handle load. This would be even more necessary in a unikernel, where you don't have a user space to defer that kind of work to. What I'm saying is that the necessary heap allocations happening in other contexts will block progress of your non allocating critical path, irq code on a GC based unikernel because of the need to discover liveness information. There are potential schemes to fix this, but they aren't implemented by MirageOS/OCaml, or most other managed unikernel environments I've seen.
pjmlp 8y ago
Just because a language has a GC, it doesn't mean it is the only way to manage memory in the said language. Computing history has lots of examples, all the way back to Mesa/Cedar workstations at Xerox PARC. Android Things user space drivers are mostly written in Java.
toolslive 8y ago
I don't think that 'slow' is the problem here: C++ developers use shared_ptr almost everywhere, which is just reference counting and hence slower than if they were to use a garbage collector (yes, there are garbage collectors for C++). I think the problem is that the cost is unpredictable. They want absolute control over _when_ things happen.
- int_19h 8y ago
  > C++ developers use shared_ptr almost everywhere shared_ptr is rare in idiomatic C++ code, and is only used when you actually have a shared object, or need a cyclic data structure with no clearly identified root. I wrote plenty of modern C++ with not a single shared_ptr in it.
- jcelerier 8y ago
  not only when, but where : a fairly common pattern is to have computations done in one thread, then once the computation is done and the thread starts another, the shared_ptrs (or any other kind of memory owners) are swapped in another thread and cleared there.
wk_end 8y ago
While ocaml is garbage collected, you can always tell exactly when the garbage collector will run - and it's very feasible to write code in a non-allocating, non-garbage collecting style when necessary.

Isn't OCAML garbage collected, which should be too slow and memory hungry for system drivers.

by alde 8y ago

Isn't OCAML garbage collected, which should be too slow and memory hungry for system drivers.

deleted 8y ago

[deleted]

tom_mellior 8y ago

MirageOS (https://mirage.io/ https://mirage.io/) has everything written in OCaml, and they don't seem to find it too slow.

qop 8y ago
But if I understand correctly (I've never used mirage) mirage is a unikernel for ocaml applications. It compiles down to xen system calls, for monitoring and administration. Mirage isn't actually an implementation of an OS in the traditional sense. Ocaml is of course already fast. INRIA has been using ocaml for compiler hacking for several decades. The speed comes as no surprise, but eventually rust will have inline assembly support, it's already nurturing some basic SIMD features, it is already being turned for lower level dominance. I think ocaml could compete, but not the way it is now. With linear types in the future, perhaps ocaml could follow rust's lead and implement a memory model around move semantics. I'm not an expert in this area, but I do perceive a nontrivial gap here. Ocaml is not built for writing system drivers. And a good system driver is written in something that was designed to be used for doing so, imo.
- pjmlp 8y ago
  Oberon and Blue Bottle drivers written in Oberon and Active Oberon respectively. http://www.projectoberon.com http://www.projectoberon.com https://svn.inf.ethz.ch/svn/lecturers/a2/trunk/ https://svn.inf.ethz.ch/svn/lecturers/a2/trunk/ Mirage TCP/IP drivers https://github.com/mirage/mirage-tcpip https://github.com/mirage/mirage-tcpip
- steveklabnik 8y ago
  Sounds like you may like https://news.ycombinator.com/item?id=16597329 https://news.ycombinator.com/item?id=16597329
monocasa 8y ago
'Slow' is a loaded term with a lot of different definitions. In terms of throughput, there's nothing wrong with a garbage collector, but in terms of latency (particularly 95+ percentile) you're never going to be able touch 'manually' (I'm including Rust here) managing the heap. Even Azul's 'pauseless' gc only guarantees something like 10ms max pauses. That's an eternity for a lot of use cases.
- tom_mellior 8y ago
  In a lot of use cases, like the drivers mentioned above, you shouldn't allocate on the heap anyway, whether manually or in a managed way. And if you don't allocate, you never need to garbage collect (since you never need to reclaim memory to make it available for new allocations). In that case, the two are even. (The above assumes that GC is only triggered by allocations. Many GCs are like that, but others trigger periodically even if there isn't anything to do. I don't know which group OCaml is in.)
  - monocasa 8y ago
    You heap allocate all the time in drivers. You just shouldn't do it from interrupt context. Source: I write plenty of drivers for a living. And even if the GC is only triggered by allocations, they'll still pause the other contexts in order to scan their stacks for live references. So, in the case of a unikernel, you can end up with critical paths being paused by allocations outside the critical path.
    - wtetzner 8y ago
      > And even if the GC is only triggered by allocations, they'll still pause the other contexts in order to scan their stacks for live references. If the GC is only triggered on allocations when there isn't enough free heap space, then why would stack scans happen at other times?
      - monocasa 8y ago
        For a driver, you have many contexts you're running. That's what the windows error "IRQL not less than or equal" blue screen means, that someone called a regular kernel function from within interrupt context. In drivers, you almost always heap allocate in your non interrupt contexts in order to dynamically handle load. This would be even more necessary in a unikernel, where you don't have a user space to defer that kind of work to. What I'm saying is that the necessary heap allocations happening in other contexts will block progress of your non allocating critical path, irq code on a GC based unikernel because of the need to discover liveness information. There are potential schemes to fix this, but they aren't implemented by MirageOS/OCaml, or most other managed unikernel environments I've seen.

pjmlp 8y ago

Just because a language has a GC, it doesn't mean it is the only way to manage memory in the said language. Computing history has lots of examples, all the way back to Mesa/Cedar workstations at Xerox PARC. Android Things user space drivers are mostly written in Java.

toolslive 8y ago

I don't think that 'slow' is the problem here: C++ developers use shared_ptr almost everywhere, which is just reference counting and hence slower than if they were to use a garbage collector (yes, there are garbage collectors for C++). I think the problem is that the cost is unpredictable. They want absolute control over _when_ things happen.

int_19h 8y ago
> C++ developers use shared_ptr almost everywhere shared_ptr is rare in idiomatic C++ code, and is only used when you actually have a shared object, or need a cyclic data structure with no clearly identified root. I wrote plenty of modern C++ with not a single shared_ptr in it.
jcelerier 8y ago
not only when, but where : a fairly common pattern is to have computations done in one thread, then once the computation is done and the thread starts another, the shared_ptrs (or any other kind of memory owners) are swapped in another thread and cleared there.

wk_end 8y ago

While ocaml is garbage collected, you can always tell exactly when the garbage collector will run - and it's very feasible to write code in a non-allocating, non-garbage collecting style when necessary.