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

111–120 of 168 posts

Re: Everything old is new again: memory optimization

#111

Post by cataphract »

gmueckl wrote: post #108
wat10000 wrote: post #65

Earlier quoted context omitted.

Turning these numbers into "memory consumption" gets complicated to the point of being intractable. The portions that are allocated but not yet used might just be page table entries with no backing memory, making them free. Except for the memory tracking the page table entries. Almost free.... A lot of "image" will be mmapped and clean. Anything you don't actually use from that will be similarly freeish. Anything tha…

This assumes that executable code pages can be shared between processes. I'm skeptical that this is still a notable optimization on modern systems because dynamic linking writes to executable memory to perform relocations in the loaded code. So this would counteract copy on write. And at least with ASLR, the result should be different for each process anyway.

ld writes to the GOT. The executable segment where .text lives is not written to (it's position independent code in dynamic libraries).

ASLR is not an obstacle -- the same exact code can be mapped into different base addresses in different processes, so they can be backed by the same actual memory.

Re: Everything old is new again: memory optimization

#112

Post by hrmtst93837 »

pjc50 wrote: post #7
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…

>> 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. At this point I'd make two observations: - how big is the text file? I bet it's a megabyte, isn't it? Because the "naive" way to do it is to read the whole thing into memory. - all these numbers are way too small to make meaningful distinctio…

[flagged]

Re: Everything old is new again: memory optimization

#113

Post by baud9600 »

Strange days we live in. Python and C++? What about a line of bash:

tr -s '[:space:]' '\n' I’d like to know the memory profile of this. The bottleneck is obviously sort which buffers everything in memory. So if we replace this with awk using a hash map to keep count of unique words, then it’s a much smaller data set in memory:

tr -s '[:space:]' '\n' I’m guessing this will beat Python and C++?

Re: Everything old is new again: memory optimization

#114

Post by wat10000 »

gmueckl wrote: post #108
wat10000 wrote: post #65

Earlier quoted context omitted.

Turning these numbers into "memory consumption" gets complicated to the point of being intractable. The portions that are allocated but not yet used might just be page table entries with no backing memory, making them free. Except for the memory tracking the page table entries. Almost free.... A lot of "image" will be mmapped and clean. Anything you don't actually use from that will be similarly freeish. Anything tha…

This assumes that executable code pages can be shared between processes. I'm skeptical that this is still a notable optimization on modern systems because dynamic linking writes to executable memory to perform relocations in the loaded code. So this would counteract copy on write. And at least with ASLR, the result should be different for each process anyway.

Dynamic linking doesn't have to write to code. I'm not familiar with other platforms, but on macOS, relocations are all in data, and any code that needs a relocation will indirect through non-code pages. I assume it's similar on other OSes.

This optimization is essential. A typical process maps in hundreds of megabytes of code from the OS. There are hundreds of processes running at any given time. Eyeballing the numbers on an older Mac I have here (a newer one would surely be worse) I'd need maybe 50GB of RAM just to hold the code of all the running processes if the pages couldn't be shared.

Re: Everything old is new again: memory optimization

#116

Post by badsectoracula »

pjc50 wrote: post #89
inetknght wrote: post #68

Earlier quoted context omitted.

> I look at memory profiles of rnomal apps and often think "what is burning that memory". As a corrolary to this: I look at CPU utilization graphs. Programs are completely idle. "What is burning all that CPU?!" I remember using a computer with RAM measured in two-digit amounts of MiB. CPU measured in low hundreds of MHz. It felt just as fast -- sometimes faster -- as modern computers. Where is all of that extra RAM b…

> I remember using a computer with RAM measured in two-digit amounts of MiB Yes, so do I. It was limited to 800x600x16 color mode or 320x200x256. A significant amount of memory gets consumed by graphical assets, especially in web browsers which tend to keep uncompressed copies of images around so they can blit them into position. But a lot is wasted, often by routing things through single bottlenecks in the whole sys…

FWIW a two digit amount of MB is usually at least 16MB (though with low hundreds of MHz it was probably at least 32MB if not 64MB) and most such systems could easily do 1024x768 at 16bit, 24bit or 32bit color. At least my mid-90s PC could :-P (24bit color specifically, i had some slow Cirrus Logic adapter that stored the framebuffer in triplets of R,G,B, probably to save RAM but at the cost of performance).

Re: Everything old is new again: memory optimization

#117

Post by ziml77 »

_dain_ wrote: post #104
VorpalWay wrote: post #94

Earlier quoted context omitted.

I too wonder that. And it is true on an OS level as well. The only worthwhile change in desktop environments since the early 2000s has been search as you type launchers. Other than that I would happily use something equivalent to Windows XP or (more likely) Linux with KDE 3. It seems everything else since then has mostly been bloat and stylistic design changes. The latter being a waste of time in my opinion. Of cours…

>The only worthwhile change in desktop environments since the early 2000s has been search as you type launchers. Add to that: unicode handling, support for bigger displays, mixed-DPI, networking and device discovery is much less of a faff, sound mixing is better, power management and sleep modes much improved. And some other things I'm forgetting.

There are some people who would exclude all of those an enhancements because they don't care about them (yes, even Unicode, I've seen some people on here argue against supporting anything other than ASCII)

Re: Everything old is new again: memory optimization

#118

Post by pjscott »

baud9600 wrote: post #113

Strange days we live in. Python and C++? What about a line of bash: tr -s '[:space:]' '\n' I’d like to know the memory profile of this. The bottleneck is obviously sort which buffers everything in memory. So if we replace this with awk using a hash map to keep count of unique words, then it’s a much smaller data set in memory: tr -s '[:space:]' '\n' I’m guessing this will beat Python and C++?

> I’d like to know the memory profile of this. The bottleneck is obviously sort which buffers everything in memory.

That's not obvious to me. I checked the manuals for sort(1) in GNU and FreeBSD, and neither of them buffer everything in memory by default. Instead they read chunks to an in-memory buffer, sort each chunk, and (if there are multiple chunks) use the filesystem as temporary storage for an external mergesort.

This sorting program was originally developed with memory-starved computers in mind, and the legacy shows.

Re: Everything old is new again: memory optimization

#119

Post by cogman10 »

ridiculous_fish wrote: post #110
cogman10 wrote: post #88

Earlier quoted context omitted.

There are 2 unavoidable atomic updates for RC, the allocation and the free event. That alone will significantly increase the amount of traffic per thread back to main memory. A lifetime system could possibly eliminate those, but it'd be hard to add to the JVM at this point. The JVM sort of has it in terms of escape analysis, but that's notoriously easy to defeat with pretty typical java code.

Why would an allocation require an atomic write for a reference count? Swift routinely optimizes out reference count traffic.

> Why would an allocation require an atomic write for a reference count?

It won't always require it, but it usually will because you have to ensure the memory containing the reference count is correctly set before handing off a pointer to the item. This has to be done almost first thing in the construction of the item.

It's not impossible that a smart compiler could see and remove that initialization and destruction if it can determine that the item never escapes the current scope. But if it does escape it by, for example, being added to a list or returned from a function, then those two atomic writes are required.

Re: Everything old is new again: memory optimization

#120

Post by knome »

baud9600 wrote: post #113

Strange days we live in. Python and C++? What about a line of bash: tr -s '[:space:]' '\n' I’d like to know the memory profile of this. The bottleneck is obviously sort which buffers everything in memory. So if we replace this with awk using a hash map to keep count of unique words, then it’s a much smaller data set in memory: tr -s '[:space:]' '\n' I’m guessing this will beat Python and C++?

>which buffers everything in memory

gnu sort can spill to disk. it has a --buffer-size option if you want to manually control the RAM buffer size, and a --temporary-directory option for instructing it where to spill data to disk during sort if need be.

Post reply on HN