6 ms·

Note that the focus here is to make it safe to have mutable data around, not to have manual memory management. Next up I hope: - https://www.youtube.com/wat

Note that the focus here is to make it safe to have mutable data around, not to have manual memory management. Next up I hope: - https://www.youtube.com/watch?v=0jI-AlWEwYI https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md

whateveracct 6y ago
You can build safe abstractions for manual memory management in userspace with LinearTypes. In fact Haskell already has plenty of manual memory management modules in its stdlib - it's just that they live in IO. You can do the unsafePerformIO internally and expose a pure API made safe by some combination of LinearTypes and the ST trick.
- cryptonector 6y ago
  To use linear types for everything will require new libraries, no?
  - whateveracct 6y ago
    Depends in your definition of "everything" If you want to manually manage all memory, then yes you'll have to not use `base` and any pure functional data structure. There's been a lot of "this feature is going to ruin the ecosystem" FUD but it's not much more that that imo
    - xvilka 6y ago
      There is `linear-base`[1] for this. [1] https://github.com/tweag/linear-base https://github.com/tweag/linear-base
    - cryptonector 6y ago
      I wasn't suggesting this would "ruin the ecosystem". Rather, I was suggesting we might end up with two ecosystems.
- Tarean 6y ago
  LinearTypes guarantee that all values are used exactly once if the result is used exactly once. If an exception is thrown, the result won't be used once and the memory would leak. One cheap way is to also track the memory with the GC. This is similar to using GC finalizers on file handles - closing handles via GC is inefficient and slow but it's only the last resort. Another option is to use exception handlers to guarantee that the Ressource is freed. Either one handler per Ressource which destroys all advantages of linear types, or one handler in total and some mutable memory to track the still open resources.
kccqzy 6y ago
I think for people who need absolute performance, manual memory management seems inevitable. No amount of GC tuning or hacks (such as the wonderful compact regions) would be satisfactory. This enables more kinds of programs to be written in Haskell, whereas your day-to-day typical server programs can just use GC as they currently do.
- pjmlp 6y ago
  If one needs absolute performance, then their only option is bare metal, as the OS can also induce every kind of delay, including RTOS, so manual == performance goes a long way until it is actually true.
  - AlotOfReading 6y ago
    There's a pretty wide area between the current situation and completely bare metal, a gap wide enough to fit the vast majority of performance sensitive applications today. It's not like you have to stop at bare metal either in a world as the hardware can introduce some latency on its own. You really need an FPGA or ASIC to take this to its logical conclusion.
    - pjmlp 6y ago
      Just like exists a gap between allocating memory like crazy, and taking care where it is allocated from, and what kind of data structures are used before assuming that malloc()/free() are faster than the alternatives without taking into consideration what happens between calling them and the kernel round-trip that takes place. So, while Haskell isn't D or Nim, there also also more than just one way to allocate memory when performance fine tuning is called for. And yes, in Fintech that is exactly what they do, reach out for FPGAs and measure cable lengths as well, while on high integrity computing all allocations are static, either at compile time or as part of the application startup, nothing else is allowed.
  - nine_k 6y ago
    A unikernel library could put your key process front and center, only providing a unified way to access the hardware. Things become more interesting when you start to need concurrency. You can of course do it manually, too, controlling every fiber switch (I've seen this done in an engine controller, where all the computatios should complete within one rotation of the shaft.)

whateveracct 6y ago

You can build safe abstractions for manual memory management in userspace with LinearTypes. In fact Haskell already has plenty of manual memory management modules in its stdlib - it's just that they live in IO. You can do the unsafePerformIO internally and expose a pure API made safe by some combination of LinearTypes and the ST trick.

cryptonector 6y ago
To use linear types for everything will require new libraries, no?
- whateveracct 6y ago
  Depends in your definition of "everything" If you want to manually manage all memory, then yes you'll have to not use `base` and any pure functional data structure. There's been a lot of "this feature is going to ruin the ecosystem" FUD but it's not much more that that imo
  - xvilka 6y ago
    There is `linear-base`[1] for this. [1] https://github.com/tweag/linear-base https://github.com/tweag/linear-base
  - cryptonector 6y ago
    I wasn't suggesting this would "ruin the ecosystem". Rather, I was suggesting we might end up with two ecosystems.
Tarean 6y ago
LinearTypes guarantee that all values are used exactly once if the result is used exactly once. If an exception is thrown, the result won't be used once and the memory would leak. One cheap way is to also track the memory with the GC. This is similar to using GC finalizers on file handles - closing handles via GC is inefficient and slow but it's only the last resort. Another option is to use exception handlers to guarantee that the Ressource is freed. Either one handler per Ressource which destroys all advantages of linear types, or one handler in total and some mutable memory to track the still open resources.

kccqzy 6y ago

I think for people who need absolute performance, manual memory management seems inevitable. No amount of GC tuning or hacks (such as the wonderful compact regions) would be satisfactory. This enables more kinds of programs to be written in Haskell, whereas your day-to-day typical server programs can just use GC as they currently do.

pjmlp 6y ago
If one needs absolute performance, then their only option is bare metal, as the OS can also induce every kind of delay, including RTOS, so manual == performance goes a long way until it is actually true.
- AlotOfReading 6y ago
  There's a pretty wide area between the current situation and completely bare metal, a gap wide enough to fit the vast majority of performance sensitive applications today. It's not like you have to stop at bare metal either in a world as the hardware can introduce some latency on its own. You really need an FPGA or ASIC to take this to its logical conclusion.
  - pjmlp 6y ago
    Just like exists a gap between allocating memory like crazy, and taking care where it is allocated from, and what kind of data structures are used before assuming that malloc()/free() are faster than the alternatives without taking into consideration what happens between calling them and the kernel round-trip that takes place. So, while Haskell isn't D or Nim, there also also more than just one way to allocate memory when performance fine tuning is called for. And yes, in Fintech that is exactly what they do, reach out for FPGAs and measure cable lengths as well, while on high integrity computing all allocations are static, either at compile time or as part of the application startup, nothing else is allowed.
- nine_k 6y ago
  A unikernel library could put your key process front and center, only providing a unified way to access the hardware. Things become more interesting when you start to need concurrency. You can of course do it manually, too, controlling every fiber switch (I've seen this done in an engine controller, where all the computatios should complete within one rotation of the shaft.)