O(x)Caml in Space
gazagnaire.org
O(x)Caml in Space
1–10 of 57 posts
Re: O(x)Caml in Space
#2[flagged]
Re: O(x)Caml in Space
#3The big win here is having a GC by default, with the ability to reduce heap allocations (via stack) just by adding in more typing annotations.
Switching to OxCaml with exclave_ stack_ annotations drops
p99.9 latency from 29 ns to 9 ns per packet on the dispatch
hot path, and removes GC pressure entirely (394 minor GCs to
zero over 25 million packets). Throughput is comparable [...]
Re: O(x)Caml in Space
#4nice
Re: O(x)Caml in Space
#5nice
Re: O(x)Caml in Space
#6CCSDS guides you to reinvent everything from scratch, I doubt memory safety is the biggest attack surface when you implement this stack. I dont know how big players implement networking for their satellites, but personally I would choose to fit something existing and battle-tested like TLS instead of reinventing data encryption, just look at those documents: https://www.google.com/search?client=firefox-b-lm&q=ccsds+en...
Re: O(x)Caml in Space
#7CCSDS guides you to reinvent everything from scratch, I doubt memory safety is the biggest attack surface when you implement this stack. I dont know how big players implement networking for their satellites, but personally I would choose to fit something existing and battle-tested like TLS instead of reinventing data encryption, just look at those documents: https://www.google.com/search?client=firefox-b-lm&q=ccsds+e…
The TL;DR here (https://ccsds.org/Pubs/350x9g2.pdf) seems to be "AES GCM", but with lots of lots of legacy protocols due to older birds in the sky. DTLS or HTTP3 would seem to be a better choice these days...
Re: O(x)Caml in Space
#8The big win here is having a GC by default, with the ability to reduce heap allocations (via stack) just by adding in more typing annotations. Switching to OxCaml with exclave_ stack_ annotations drops p99.9 latency from 29 ns to 9 ns per packet on the dispatch hot path, and removes GC pressure entirely (394 minor GCs to zero over 25 million packets). Throughput is comparable [...] I got a similar result with my 'htt…
I think robustness is helped a lot by the fact that it’s the production compiler used at Jane Street
Re: O(x)Caml in Space
#9The big win here is having a GC by default, with the ability to reduce heap allocations (via stack) just by adding in more typing annotations. Switching to OxCaml with exclave_ stack_ annotations drops p99.9 latency from 29 ns to 9 ns per packet on the dispatch hot path, and removes GC pressure entirely (394 minor GCs to zero over 25 million packets). Throughput is comparable [...] I got a similar result with my 'htt…
Nim does much the same. It prefers the stack, wraps dynamic heap types in value-semantic unique pointers by default, and avoids implicit copies wherever it can. I could see compiled languages trending in the stack-managed direction long term.
Re: O(x)Caml in Space
#10The big win here is having a GC by default, with the ability to reduce heap allocations (via stack) just by adding in more typing annotations. Switching to OxCaml with exclave_ stack_ annotations drops p99.9 latency from 29 ns to 9 ns per packet on the dispatch hot path, and removes GC pressure entirely (394 minor GCs to zero over 25 million packets). Throughput is comparable [...] I got a similar result with my 'htt…
I think robustness is helped a lot by the fact that it’s the production compiler used at Jane Street
Yeah; all the really dangerous extensions are gated behind flags. But there's still a very significant number of optimisations available by default that just work well. I've taken to compiling my normal OCaml code with OxCaml these days to get a free speed boost (but buyer beware: the dependency management can be tricky; I have a giant monorepo to help out https://github.com/avsm/oxmono)