Brett (ggtgp.delete@this.yahoo.com) on January 19, 2020 2:18 pm wrote:
> Brendan (btrotter.delete@this.gmail.com) on January 19, 2020 11:25 am wrote:
> > Hi,
> >
> > Jukka Larja (roskakori2006.delete@this.gmail.com) on January 18, 2020 9:13 pm wrote:
> > > Brendan (btrotter.delete@this.gmail.com) on January 18, 2020 11:40 am wrote:
> > > > Jukka Larja (roskakori2006.delete@this.gmail.com) on January 17, 2020 9:08 pm wrote:
> > > > > Brendan (btrotter.delete@this.gmail.com) on January 17, 2020 12:52 pm wrote:
> > > > >
> > > > > > The difference is when you find out that you need to deal with a low memory problem - in a well defined
> > > > > > place (as soon as you try to allocate the memory) where it's easy to control the circumstances, or "at
> > > > > > any time, almost anywhere" where you have to worry about the least convenient circumstances.
> > > > >
> > > > > So in your opinion, when ever one writes "new" or "malloc", there should be (serious) handler
> > > > > in case of OOM? Able to release some random caches and so on, if at all applicable to that
> > > > > particular software? And you consider that something everyone should spend time on?
> > > >
> > > > In my opinion; a software developer should be able to do whatever they think is sane for their software
> > >
> > > Ok, I agree with this. What I obviously don't agree with is "sane" for most software.
> > >
> > > > (which could include dropping cached data, and/or waiting until another thread finishes and
> > > > releases resources,
> > > > and/or refusing to accept additional work to ensure already accepted work succeeds,
> > >
> > > I don't really see how one is supposed to do these things without trying
> > > to allocate any new memory, except in trivial toy examples.
> >
> > Why is this hard to figure out? Don't forget that you can pre-allocate (e.g. at program
> > startup/initialization, or at compile time) to avoid allocations during error handling.
> >
> > > > and/or reporting failure
> > > > in a way that is consistent with the way all other problems are reported, and/or anything else); and a
> > > > software developer should not be prevented from doing whatever they think is sane because they're forced
> > > > to accept something that is almost never sane (either OOM killer, or SIGBUS that is unusable for most
> > > > cases, or constant monitoring that can't solve the problem due to race conditions).
> > >
> > > How exactly is getting an OOM on memory allocation so much better than getting it at some other random
> > > time via signal?
> >
> > Do you honestly expect me to believe that you don't think you can handle OOM (e.g. without
> > allocations, etc) when it happens at the most convenient place you choose, but do think you
> > can handle OOM when it happens at the least convenient place that you don't choose?
> >
> > > In typical code, most allocations probably aren't done by applications own code, but some
> > > library. For example, put some std::string or std::vector to stack and they will allocate from heap too.
> > > If there's a system wide OOM going on, how can you even expect to be able to write a log message?
> >
> > Stack is pre-allocated (and without overcommit the OS guarantees that the pre-allocated stack
> > is safe to use and you won't trigger OOM by using it), when you create an simple object (e.g.
> > std:string, std:vector) you allocate memory (not the library that contains the objects class,
> > constructor, etc) and you will (unless you intentionally broke C++) either get a reference that
> > is NULL (that you must check yourself) or a "std:bad_alloc" exception (that you must catch).
> >
> > In theory there might be a library that allocates memory itself without giving you any hope of detecting
> > that when the allocation/s fail. I have never seen this and I doubt it actually exists in practice. Anybody
> > that is too incompetent to write a usable library will not write a library that anyone will use.
> >
> > > > Yes; but even for games, "what makes sense for the game" can depend on the game. For example, maybe for
> > > > one game it makes sense to do an auto-save before changing to a different level/zone, then load everything
> > > > and pre-allocate everything for the next level/zone (while managing allocation failures), then not have
> > > > a reason to care while the player remains in that level/zone
> > > > because you know everything was already allocated
> > > > successfully; and maybe for a different game that approach
> > > > can't make sense because there are no levels/zones
> > > > (or there's multiple players or ...) and something very different is far more suitable.
> > >
> > > Yeah, sure. If things happen to be just right, then it
> > > makes sense to do X. The game will need extra buffers
> > > to load everything the level needs from disk. They will be needed right until everything is loaded, at
> > > which point the memory consumption will be the highest (add some random variation due to multithreading
> > > and the fact that the player may decide to put the console to sleep in the middle of this).
> > >
> > > You are also completely ignoring that memory fragmentation
> > > gets really bad really fast, if you are constantly
> > > running near the limit. If your normal mode of operation is doing something in response to allocation
> > > failures, you're screwed anyway. All that crazy amount of error handling for nothing (note that this is
> > > no longer about system wide OOM, but strictly what's happening inside a game on a console).
> >
> > If you're constantly running near the limit; then the user is constantly being
> > told "Sorry, you can't do that because their isn't enough memory", given that:
> >
> > a1) if the software happens to support a "deallocate unnecessary data to increase the chance
> > of success" approach, then it will reach a point where there is nothing left for the software
> > to deallocate; causing the software to fall back to some other approach.
> >
> > a2) if the software happens to support a "reduce quality of work to increase the chance
> > of success" approach (e.g. maybe switching to lower resolution textures, etc), then
> > it will reach a point where there the quality of work has reached its minimum and
> > can't be reduced; causing the software to fall back to some other approach.
>
> If I were still in games I would be doing dynamic rendering distance, so pop in
> happens closer in geometry heavy areas to keep a steady frame rate above 60.
> Also I would be going small round worlds instead of flat so that I could have flat fields with long rendering
> distances. Getting sick of jagged terrains to hide poor rendering distance and hide pop in.
> I bet both are common now, neither were done when I did console
> titles. Some titles did do pop up for distant objects, yuck.

Actually dynamic rendering distance has been around forever, I meant to say this is a feature users are not aware of, and I have seen a lot of games botch this.
If you don’t manage your CPU tasks correctly you get spikes that cause frame drop.

> This is not the 64k days, anyone that complains that 4 gigabytes is not enough
> and your app is crashing due to running out of ram is running crap software.
> You can’t stream 4gb to the video card 60 times a second, games have
> more ram than they can use, if the programmer is using his brain.
>
> Servers have the same issue, you are limited by your Ethernet and
> disk throughput and seek time, and sometimes by lack of hot data.
> Too much cold data out in ram can be as useless as more disk space, if you can’t
> access the data fast enough then the user has moved on and your ad never rendered.
>
> > b) the software can't be using a "wait until other work finishes (and frees memory) before
> > continuing" approach (possibly as a fall-back); because if it was it can't be constantly
> > running near the limit (and would be constantly waiting near the limit instead).
> >
> > c) the software can't be using a "report lack of memory in a manner consistent
> > with all other errors, save user's data, then terminate" approach (possibly
> > as a fall-back); because if it was it can only reach that limit once.
> >
> > d) the only other approach (that I can think of) is "cancel that one piece of work and
> > inform the user, so all other pieces of work can continue" (possibly as a fall-back).
> >
> > Now; if the user is constantly being told "Sorry, you can't do that because their isn't enough
> > memory"; then it must be because the user hasn't stopped using your software and hasn't dealt
> > with the problem some other way (saving work in other apps and closing those other apps to
> > increase memory available to your process without losing data, buying more RAM, ...).
> >
> > In other words; the only plausible scenario that could involve
> > "constantly running near the limit" is that the
> > user doesn't mind being told "Sorry, you can't do that because
> > their isn't enough memory" constantly (possibly
> > because they know they should be glad that they're not using a dodgy piece of shit that crashes instead).
> >
> > - Brendan
> >
>
>