Hacker News Reader

Comment by CamperBob2 | Hacker News Reader

RAM is free, too, at least as far as library code size is concerned.

A typical system has dozens or hundreds of processes running even when nothing is going on. If they all had their own copy of every system library in RAM, it wouldn’t look so free. Especially on mobile devices.

What if the OS could dedupe pages?

You'd need to arrange for the linking process to result in identical (and identically-aligned!) code pages. If you're going to all the trouble to ensure that, why not just write it all to a file and call it a shared library?

Exactly. Emperors' new clothes from naive convention abandonment of solved problems.

On the fly memory dedupe is incredibly expensive. Especially compared to just not duplicating in the first place.

Also, it's quite likely that static linked libraries wouldn't be located at the exact same page offsets every time they're linked in to a binary, making page-level dedupe not useful.

What if the OS could map a shared object that resides in one section of memory into the virtual address space of multiple processes?

Do any OSes actually do this, though? If not, this is academic until one actually does.

Linux does have something called "KSM" that de-dupes memory pages, but it appears that it's only so a hypervisor can de-dupe guest OS pages? Odd that it's not more general than that. Though I guess there is a cost: the KSM code needs to scan through memory to find duplicate pages, which I can't imagine is fast.

Would not work with any kind of LTO.

Meh, not so much. The processes will only page in the code they actually use.

Shared libraries are a goofy hack dating back to a time when people mistakenly thought they needed them, and they need to go away.

Shared object libraries are incredibly useful because they save memory and CPU resources. Cloning the process space during a fork(2) call, initializing structures, then context switching and whatnot is incredibly expensive.

shared library can be expensive as well, the dynamic symbol lookup could be a lot more expensive than people would assume.

Correct. Shared libraries trade away CPU for memory. Even with some benefits in terms of cache warmth, the extra indirection and loader/VM complexity make shared libraries a net loss in terms of CPU.

>Cloning the process space during a fork(2) call, initializing structures, then context switching and whatnot is incredibly expensive.

Err, we're running Electron apps today, with a full blown embedded browser engine, a vm, and a hellish complex DOM for rendering. Others run apps inside containers, with their own basic OS and standard libs -- compared to that the above is negligible.

> we're running Electron apps today

Some of us try not to on the belief that they don't perform acceptably.

You can usually avoid this problem by using the web version of Slack, Discord, Rocketchat, etc. A single browser running everything is obviously more efficient than running ten.

Nope. A strawman wrong doesn't justify anything related to the topic. fork() duplicates everything, which maybe overkill, which is why pthreads and vfork+exec also exist.

That's not why pthreads exist, and vfork barely does. Pthreads exist to facilitate parallel operation (hence the name) on shared data, not as an efficiency measure. As for vfork, it has been deprecated since every UNIX implementation started marking pages as copy-on-write instead of actually copying. I was doing some of that work myself in 1990-91, so it's hardly new.

The real problems with static linking don't have to do with fork, except in the sense of increasing reliance on VM overcommit (which IMO is a bad idea already). It's more to do with masking reuse of the same library across unrelated processes, as an efficiency issue but even more importantly in terms of tracking dependencies and updating software. No matter how good your configuration management (or similar mechanism) is, rebuilding large-N statically linked executables is less efficient and more error-prone than using the same information to update small-N shared libraries.

You are working on one of these electron-style apps, right?

(Shrug) RAM is there to be used.

I don't think we need to get into my optimization street cred, but suffice it to say I've never used Electron and couldn't really tell you exactly what it is.

Resources aren't infinite. It's arrogant and wasteful to be lazy and resource greedy.

Electron is an embedded web-browser meets cross-platform application platform.. it's bloated, slow and awful... it makes Java look snappy, lightweight and brilliant.

I don't get it. You're using more RAM for literally no benefit. The end result is exactly the same. There isn't even a productivity benefit in the vast majority of cases because a huge chunk of software is packaged by the OS to use shared libraries by default.

Avoiding DLL hell is certainly a benefit. It seems likely that few participants in this thread besides myself have ever actually had to support end users.

you would be surprised to learn that for very large binaries (think about monolithic front end codes at large internet companies), code size is actually enough to put pressure on instruction caches and lead to paging!

It used to be free, until people thought it was free to waste.

RAM is free as long as you don’t have to pay the price. But it does have a price.

Reply on news.ycombinator.com