Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything old is new again: memory optimization

nibblestew.blogspot.com

Post reply on HN
Print view View original

151–160 of 168 posts

Re: Everything old is new again: memory optimization

#151

Post by Melatonic »

HappMacDonald wrote: post #146
pjc50 wrote: post #92

Earlier quoted context omitted.

As pointed out below, quite a lot of that isn't in RAM - see "working set". There's a common noob complaint about "Linux using all my RAM!" where people are confused about the headline free/buffers numbers. If there's a reasonable chance data could be used again soon it's better to leave it in RAM; if the RAM is needed for something else, the current contents will get paged out. Having a chunk of RAM be genuinely una…

Of course it's doing something for you. Room to defrag other areas of RAM, room to load something new without moving something else out of the way first. Your perspective sounds like the concept that space in a room does nothing for you until/unless you cram it full of hoarded items.

If we're talking about a storage locker that's instantly reconfigurable then it is probably better to be approximately filling it.

Why would anyone buy a locker 5x the size of their needs ?

Re: Everything old is new again: memory optimization

#152

Post by Melatonic »

shepherdjerred wrote: post #105
ThrowawayR2 wrote: post #77

Earlier quoted context omitted.

Next time you see someone on HN blithely post "CPU / RAM is cheaper than developer time", it's them. That is the sort of coder who are collectively wasting our CPU and RAM.

If you ran a business, would you rather your devs work on feature X that could bring in Y revenue, or spend that same time reducing CPU/RAM/storage utilization by Z% and gives the benefit of ???

Why not both ?

Re: Everything old is new again: memory optimization

#153

Post by Melatonic »

toss1 wrote: post #124
muskstinks wrote: post #21

I'm always confused as hell how little insight we have in memory consumption. I look at memory profiles of rnomal apps and often think "what is burning that memory". Modern compression works so well, whats happening? Open your taskmaster and look through apps and you might ask yourself this. For example (lets ignore chrome, ms teams and all the other bloat) sublime consumes 200mb. I have 4 text files open. What is it…

>>I'm always confused as hell how little insight we have in memory consumption. >>I look at memory profiles of rnomal apps and often think "what is burning that memory". Because companies starting with Microsoft approach it as an infinite resource, and have done so literally for generations of programmers — it is now ancient tradition. Back in the x86 days when both memory and memory handles were constrained (64k of…

Software engineers seem to be more and more abstracted from the hardware they use. You also (rarely) back in the day had to worry about things like IRQ ports and optimising for tiny amounts of latency.

Personally I am fine with programmers not spending tons of time optimising down to every last piece because we do have so much more ram and compute relative to the old days. My bigger issue is that things are also a laggy mess even when there is plenty of resources available. I understand these things go hand in hand but I would much rather see more optimisations for the things users will actually notice than just going for metrics. A nice combo of the two would be ideal.

That being said what's probably most appalling is the amount some modern programs hard crash even when they have plenty of resources.

Re: Everything old is new again: memory optimization

#154

Post by astrange »

muskstinks wrote: post #99
Capricorn2481 wrote: post #66

Earlier quoted context omitted.

Is that in Task Manager, or is that not a reliable place to look for these statistics? Edit: From what I can tell, Sublime is allocated 100mb of virtual memory even if it's only using about 10mb in practice.

Real Memory: 138 MB Virtual Memory: 390 GB <<<<<< wtf? :) Shared Memory: 143 MB Private Memory: 34 MB

The 390GB is because of implementation details of GPU drivers. It's not wrong but it also doesn't matter at all.

(The only number that actually means anything there is the first one, but the label for it is basically meaningless. Use `footprint` in Terminal for a better explanation of memory use.)

Re: Everything old is new again: memory optimization

#155

Post by zar1048576 »

bigstrat2003 wrote: post #127
shepherdjerred wrote: post #105

Earlier quoted context omitted.

If you ran a business, would you rather your devs work on feature X that could bring in Y revenue, or spend that same time reducing CPU/RAM/storage utilization by Z% and gives the benefit of ???

You work on both. Sometimes you need to prioritize one, sometimes the other. And the benefit of the second option is "it makes our product higher quality, both because that is our work ethic but also because our customers will appreciate a quality product".

I agree with this. What you focus on depends on the circumstances. I believe PaulG likes to say that premature optimization is the root of all evil. Early on, you’re trying to ship and get a functioning product out the door — if spending a bit of money on extra RAM at that time helps you, it’s worth it. Over time, as you are trying to optimize, it makes sense to think more about memory management, etc.

Re: Everything old is new again: memory optimization

#156

Post by astrange »

Twirrim wrote: post #73
Capricorn2481 wrote: post #66

Earlier quoted context omitted.

Is that in Task Manager, or is that not a reliable place to look for these statistics? Edit: From what I can tell, Sublime is allocated 100mb of virtual memory even if it's only using about 10mb in practice.

A lot of programs over-allocate on virtual memory, but don't actually use it, and the OS is smart enough to just pretend like it allocated it. I'm sure there's probably some justification for it somewhere, but it's hard not to see it as some absurd organically achieved agreement. Developers used to ask for more memory than their application actually needed and caused all sorts of OOM problems for end users. OS develo…

There is literally no reason to care how much "virtual memory" you're using - pointers are 64-bit after all.

(Well, 48 bits.)

Exceptions apply on Windows for reasons I forget, and on watchOS because there isn't enough memory for the page tables for really big VM regions.

Re: Everything old is new again: memory optimization

#157

Post by astrange »

cogman10 wrote: post #83
xyzzy_plugh wrote: post #46

Earlier quoted context omitted.

That's not strictly true. Mark and sweep is tunable in ways ARC is not. You can increase frequency, reducing memory at the cost of increased compute, for example.

M&S also doesn't necessitate having a moving and compacting GC. That's the thing that actually makes the JVM's heap greedy. Go also does M&S and yet uses less memory. Why? Because go isn't compacting, it's instead calling malloc and free based on the results of each GC. This means that go has slower allocation and a bigger risk of memory fragmentation, but also it keeps the go memory usage reduced compared to the JVM…

Compacting reduces memory usage - that's why it's called compacting.

The JVM uses a lot of memory a) because it's tuned for servers and not for low memory usage and b) because Java is a poorly designed language without value types.

Re: Everything old is new again: memory optimization

#158

Post by shepherdjerred »

Melatonic wrote: post #152
shepherdjerred wrote: post #105

Earlier quoted context omitted.

If you ran a business, would you rather your devs work on feature X that could bring in Y revenue, or spend that same time reducing CPU/RAM/storage utilization by Z% and gives the benefit of ???

Why not both ?

Because time, effort, and attention are all finite

Re: Everything old is new again: memory optimization

#159

Post by astrange »

zozbot234 wrote: post #58
griffindor wrote: post #3

Nice! > Peak memory consumption is 1.3 MB. At this point you might want to stop reading and make a guess on how much memory a native code version of the same functionality would use. I wish I knew the input size when attempting to estimate, but I suppose part of the challenge is also estimating the runtime's startup memory usage too. > Compute the result into a hash table whose keys are string views, not strings If t…

> If the file is mmap'd, and the string view points into that, presumably decent performance depends on the page cache having those strings in RAM. Not so much, because you only need some fraction of that memory when the program is actually running; the OS is free to evict it as soon as it needs the RAM for something else. Non-file-backed memory can only be evicted by swapping it out and that's way more expensive,

All major OSes (well Windows and macOS) do in-memory compression before swap, which is cheaper than evicting a file-backed page. But still slow, so you don't want to rely on it.

Re: Everything old is new again: memory optimization

#160

Post by 6510 »

Someone on youtube[0] suggested we use (something like) KolibriOS[1] in a vm as a kind of webbrowser. Then we can have snappy effective desktop apps for everything cross platform(!)

The 12 MB OS looks surprisingly mature. We are so conditioned for bloat that with each click I'm surprised how fast it responds. I don't remember ever being surprised by the same thing twice in a row but here it stays surprising how everything opens in the next frame even on very poor hardware.

Besides from a vm I read there is a synery[3] client for it[4]. I've used crappy pc's on extra screens and having a dedicated machine for a single application is fun, useful and it makes old stuff useful. You can run heavy applications on the main computer, it's unimportant the extra cant do it.

[0] - https://www.youtube.com/watch?v=v3NVKOsWkQs

[1] - https://www.kolibrios.org/en

[3] - https://www.youtube.com/watch?v=tlt7X0H5GJw

[4] - https://board.kolibrios.org/viewtopic.php?t=2544

Post reply on HN