7 ms·

What would happen in your utopia is that DaVinci Resolve would fail to start because Firefox or Discord would reserve too much memory. Or maybe Firefox would de

by slaymaker1907 4y ago

What would happen in your utopia is that DaVinci Resolve would fail to start because Firefox or Discord would reserve too much memory. Or maybe Firefox would demand you close open tabs before allowing you to open a new one. We have a solution to the problem you describe, it's called paging to disk and hoping that we won't need to read or write to that memory very often (which works great for something like Firefox where a bunch of pages are sitting idly in the background).

kristoff_it 4y ago
Allocating upfront is only one technique. Somehow DaVinci Resolve is capable of using all the free memory it can find and not more than that, otherwise it would never be able to complete any rendering job. That's one "utopic" program that's pretty real. > We have a solution to the problem you describe, it's called paging to disk and hoping No. The solution is to be smart about memory usage, and to handle failures when trying to allocate memory. DaVinci would become unusable if it started swapping when rendering. Maybe for some programs swapping is a fine solution, but the argument that software engineers shouldn't concern themselves with designing for OOM conditions is absolutely ridiculous. That's not a 'utopia', that's what we should be concretely be striving for.
- mananaysiempre 4y ago
  It’s difficult to see how that would be possible without a hard break from legacy systems when fork/exec practically forces overcommit and very dubious resource accounting on us. (One consumer system that handled OOM conditions with remarkable grace was Symbian, but of course it forced an extremely peculiar programming style.)
  - kristoff_it 4y ago
    That's a fair point, but it's also true that we're never going to break away from legacy systems until we start writing software that has a chance of functioning correctly when running out of resources. The good news is that we do have ecosystems where you don't have overcommit, like webassembly and embedded devices, and if you're writing libraries meant to also work on those platforms, then you will have some good building blocks that can be used to iterate towards more robust software. That's how you're expected to approach library writing in Zig.
    - deleted 4y ago
      [deleted]
- astrange 4y ago
  The purpose of abstractions is so you don't have to think about what's under them. malloc() can fail if you try to allocate many GBs at once, but if you let it fail for 32 byte allocations then what are you even going to do about that? The only solution is to crash your process, but that will lose user data if you haven't saved it yet, and purity isn't worth that.
  - kristoff_it 4y ago
    As far as I'm aware, witing to a file doesn't require any memory allocation on any of the major OSs, so you can most definitely save the user's work when running out of memory. > The only solution is to crash your process I disagree. I think this is a bad mindset that we allowed ourselves to slid into. There's a lot more than can be done when an allocation fails, starting from what I mentioned above. That said, I'll agree that at least you need a programming language that can help you design and maintain allocation-free codepaths in your program, and that 's hard if your language has builtins that allocate implicitly, as you will have to avoid them all. Zig has the philosophy of keeping all memory allocations explicit precisely for this reason. In the beginning people used to say that it was too extreme, but now Rust is also embracing this approach in order to be used in the Linux Kernel (one place where the "only solution is to crash" learned helplessness will not be well received), so hopefully there will be even more options in the future.
    - astrange 4y ago
      > As far as I'm aware, witing to a file doesn't require any memory allocation on any of the major OSs, so you can most definitely save the user's work when running out of memory. Course it does. You can’t run any code in a typical app environment without allocating heap objects as you go, and even if you didn’t, anything that accesses a swapped out page is “allocating physical memory”. And once it gets into the kernel, file systems have to allocate their own objects to track new writes. Though if the kernel is failing to allocate memory you have worse problems.
      - kristoff_it 4y ago
ok_dad 4y ago
Too bad we can't design some protocol for applications to "work together" to ensure each has the memory they need. Like some sort of "application collective memory management" where each application has certain memory it needs/wants and depending on the priority of that need and the current priorities of the other applications, it could know to reduce memory usage during those times when some other application has a higher priority. For one, it would help in your case, because background video processing might be a lower priority, or perhaps you want it to finish as fast as possible, so that Firefox and etc. just "freeze" themselves for a while and drop as much memory as is practicable (ie: deleting currently rendered pages from memory and re-rendering them later, or paging those out to disk for a while).
- kristoff_it 4y ago
  Firefox should in theory be able to crash individual tabs to reclaim memory, but in practice I just see it die.
  - littlestymaar 4y ago
    Isn't it likely because it's not crashing by itself, and is being killed by the OS?
  - astrange 4y ago
    Are you both running with swap turned off? You can't just turn off swap on a system designed for it; of course it's going to break.
- mananaysiempre 4y ago
  Related references: - Neal Walfield’s papers on resource management[1,2] - The agoric papers[3] from the E people (who sadly now seem to be trying to steer the whole thing in the cryptocurrency direction) [1] http://walfield.org/papers/2009-walfield-viengoos-a-framework-for-stakeholder-directed-resource-allocation.pdf http://walfield.org/papers/2009-walfield-viengoos-a-framewor... [2] http://walfield.org/papers/2011-walfield-smart-phones-need-smarter-applications.pdf http://walfield.org/papers/2011-walfield-smart-phones-need-s... [3] https://papers.agoric.com/papers/ https://papers.agoric.com/papers/
newZWhoDis 4y ago
>What would happen in your utopia is that DaVinci Resolve would fail to start because Firefox or Discord would reserve too much memory. Great! Then users can annoy devs who write crappy software “I can’t open anything else when discord is open!” Vs today where the OS essentially conceals crappy software from the user via a billion layers of abstraction and hacks
- vore 4y ago
  Well, no, because the tradeoff with static allocation is that you need to allocate all the memory you want upfront. If you're requesting memory via dynamic allocation, you can be less wasteful by only requesting what you need and returning what you don't need to the OS. In the case of e.g. Firefox, do you really want it to always be doing bookkeeping for 100 tabs when you only need 1? Or having to restart Firefox every time if you've hit the upper limit of tabs? Or just let Firefox dynamically allocate memory as you open more tabs? There are many compelling reasons for dynamic memory allocation, and "the OS essentially concealing crappy software from the user via a billion layers of abstraction and hacks" is a fundamental misunderstanding of its purpose.

kristoff_it 4y ago

Allocating upfront is only one technique. Somehow DaVinci Resolve is capable of using all the free memory it can find and not more than that, otherwise it would never be able to complete any rendering job. That's one "utopic" program that's pretty real. > We have a solution to the problem you describe, it's called paging to disk and hoping No. The solution is to be smart about memory usage, and to handle failures when trying to allocate memory. DaVinci would become unusable if it started swapping when rendering. Maybe for some programs swapping is a fine solution, but the argument that software engineers shouldn't concern themselves with designing for OOM conditions is absolutely ridiculous. That's not a 'utopia', that's what we should be concretely be striving for.

mananaysiempre 4y ago
It’s difficult to see how that would be possible without a hard break from legacy systems when fork/exec practically forces overcommit and very dubious resource accounting on us. (One consumer system that handled OOM conditions with remarkable grace was Symbian, but of course it forced an extremely peculiar programming style.)
- kristoff_it 4y ago
  That's a fair point, but it's also true that we're never going to break away from legacy systems until we start writing software that has a chance of functioning correctly when running out of resources. The good news is that we do have ecosystems where you don't have overcommit, like webassembly and embedded devices, and if you're writing libraries meant to also work on those platforms, then you will have some good building blocks that can be used to iterate towards more robust software. That's how you're expected to approach library writing in Zig.
  - deleted 4y ago
    [deleted]
astrange 4y ago
The purpose of abstractions is so you don't have to think about what's under them. malloc() can fail if you try to allocate many GBs at once, but if you let it fail for 32 byte allocations then what are you even going to do about that? The only solution is to crash your process, but that will lose user data if you haven't saved it yet, and purity isn't worth that.
- kristoff_it 4y ago
  As far as I'm aware, witing to a file doesn't require any memory allocation on any of the major OSs, so you can most definitely save the user's work when running out of memory. > The only solution is to crash your process I disagree. I think this is a bad mindset that we allowed ourselves to slid into. There's a lot more than can be done when an allocation fails, starting from what I mentioned above. That said, I'll agree that at least you need a programming language that can help you design and maintain allocation-free codepaths in your program, and that 's hard if your language has builtins that allocate implicitly, as you will have to avoid them all. Zig has the philosophy of keeping all memory allocations explicit precisely for this reason. In the beginning people used to say that it was too extreme, but now Rust is also embracing this approach in order to be used in the Linux Kernel (one place where the "only solution is to crash" learned helplessness will not be well received), so hopefully there will be even more options in the future.
  - astrange 4y ago
    > As far as I'm aware, witing to a file doesn't require any memory allocation on any of the major OSs, so you can most definitely save the user's work when running out of memory. Course it does. You can’t run any code in a typical app environment without allocating heap objects as you go, and even if you didn’t, anything that accesses a swapped out page is “allocating physical memory”. And once it gets into the kernel, file systems have to allocate their own objects to track new writes. Though if the kernel is failing to allocate memory you have worse problems.
    - kristoff_it 4y ago

ok_dad 4y ago

Too bad we can't design some protocol for applications to "work together" to ensure each has the memory they need. Like some sort of "application collective memory management" where each application has certain memory it needs/wants and depending on the priority of that need and the current priorities of the other applications, it could know to reduce memory usage during those times when some other application has a higher priority. For one, it would help in your case, because background video processing might be a lower priority, or perhaps you want it to finish as fast as possible, so that Firefox and etc. just "freeze" themselves for a while and drop as much memory as is practicable (ie: deleting currently rendered pages from memory and re-rendering them later, or paging those out to disk for a while).

kristoff_it 4y ago
Firefox should in theory be able to crash individual tabs to reclaim memory, but in practice I just see it die.
- littlestymaar 4y ago
  Isn't it likely because it's not crashing by itself, and is being killed by the OS?
- astrange 4y ago
  Are you both running with swap turned off? You can't just turn off swap on a system designed for it; of course it's going to break.
mananaysiempre 4y ago
Related references: - Neal Walfield’s papers on resource management[1,2] - The agoric papers[3] from the E people (who sadly now seem to be trying to steer the whole thing in the cryptocurrency direction) [1] http://walfield.org/papers/2009-walfield-viengoos-a-framework-for-stakeholder-directed-resource-allocation.pdf http://walfield.org/papers/2009-walfield-viengoos-a-framewor... [2] http://walfield.org/papers/2011-walfield-smart-phones-need-smarter-applications.pdf http://walfield.org/papers/2011-walfield-smart-phones-need-s... [3] https://papers.agoric.com/papers/ https://papers.agoric.com/papers/

newZWhoDis 4y ago

>What would happen in your utopia is that DaVinci Resolve would fail to start because Firefox or Discord would reserve too much memory. Great! Then users can annoy devs who write crappy software “I can’t open anything else when discord is open!” Vs today where the OS essentially conceals crappy software from the user via a billion layers of abstraction and hacks

vore 4y ago
Well, no, because the tradeoff with static allocation is that you need to allocate all the memory you want upfront. If you're requesting memory via dynamic allocation, you can be less wasteful by only requesting what you need and returning what you don't need to the OS. In the case of e.g. Firefox, do you really want it to always be doing bookkeeping for 100 tabs when you only need 1? Or having to restart Firefox every time if you've hit the upper limit of tabs? Or just let Firefox dynamically allocate memory as you open more tabs? There are many compelling reasons for dynamic memory allocation, and "the OS essentially concealing crappy software from the user via a billion layers of abstraction and hacks" is a fundamental misunderstanding of its purpose.