I mean, I know why I got that much—I really value the ability to load up a ~20GB dataset into Pandas or pipe it through AWK for a one-off (or ten-off) task and just not worry about the particulars. Running `make -j16` and having the system stay usable while the compiler chews through the hundreds of KLOC of (admittedly very... vertical-looking) C and C++ is also appreciated. Also, memory modules are cheap and I feel stupid paying the markup for basically the same ICs soldered down, and once I had the slots available, well, as I said, memory modules are cheap.
More generally, though, screens and syntax trees.
First, a laptop screen that an 19th century book printer wouldn’t call an atrocity against the art (say 200ppi and above), at 32 bpp, takes ~16 MB for a single framebuffer. At 60 Hz, that means your display panel interface is already pushing 750 MB/s of useful data (and I’m ignoring all the legacy cruft like overscan and vblank). Unsurprisingly, the GPU that does all that, for multiple layers, in floating point (so 96 or 128 bpp), is heavily pipelined. Feeding that pipeline adequately and without heroics means at least a length-3 swapchain, so already you have 48 MB of screen buffers for any full-screen app that you don’t need to wait to redraw after you switch to it (remember when we needed to do that?). If said app is showing something large and scrollable, and you count on being able to see the thing you’re scrolling (remember when you couldn’t? thank touch input for killing that), that’s probably also, what, three, four screens’ worth of prerendered tiles? And now we’re already pushing a hundred megs—just for the pixels. How many browser tabs do you have open? (Personally, I get really irritated when my browser gets an attention deficit and doesn’t immediately show me the tab after I click on it.) Or thousand-page PDF specs?
(I was recently installing an old version of Windows in QEMU, and the installer showed me the installation wizard’s window—with all the text and controls—first and then spent multiple seconds blitting a purely frivolous graphic of a computer with installation disks around it onto the left pane. I didn’t remember computers used to do that! At least until you got around to installing the graphics driver, anyway, I guess.)
Second, I’ve been mulling over a Web browser’s job, and I can’t help but conclude that it’s really bloody awful.
The existence of the mutable DOM means it has to maintain a full-fat syntax tree for all the HTML—a humongous soup of pointers in a 64-bit address space (so in modern browsers they are hand-rolled 32-bit not-really-pointers). On top of that it needs to have an acceleration structure for style recomputation accessed on the critical user interaction path (because :hover), as well as a layout tree with line boxes supporting dynamic Unicode- (even BiDi-) aware line breaking and perhaps even hyphenation on resize, and none of that should fall over if you load up War and Peace in the original Russian+French with the paragraph breaks deleted.
It’s old compiler lore that no syntax tree will be as compact as the source code it was constructed from. Browsers sound like the bottommost circle of syntax tree hell even more than a general GUI has to be. The situation is probably salvageable with a flattened representation like the one Jetpack Compose uses and differential execution[1] used before it. But it’s definitely a lot of work, and to my admittedly cursory knowledge noöne’s really working on it.
(This part inspired by the urge to clutch my pearls that I felt while watching Andreas Kling’s Ladybird videos—there’s a lot of very thicc pointer soup in there, and I don’t think it’s possible to morph it into something saner in a continuous fashion. But then I thought about the problem, and yeah, the problem sucks.)
So all in all I think single-digit gigs sound about fair, I think, and that’s how much my system typically shows when I’m not deliberately running heavy stuff on it.
(For what it’s worth, I once spent weeks cramming all data required for Unicode normalization into about 20K. It’s certainly possible, but as it turns out, three iterations of fetch-shift-popcount for every character is slow. Not “why do I need to wait for my computer” slow, but definitely “why does my computer’s SSD have to wait for its CPU” slow.)
More generally, though, screens and syntax trees.
First, a laptop screen that an 19th century book printer wouldn’t call an atrocity against the art (say 200ppi and above), at 32 bpp, takes ~16 MB for a single framebuffer. At 60 Hz, that means your display panel interface is already pushing 750 MB/s of useful data (and I’m ignoring all the legacy cruft like overscan and vblank). Unsurprisingly, the GPU that does all that, for multiple layers, in floating point (so 96 or 128 bpp), is heavily pipelined. Feeding that pipeline adequately and without heroics means at least a length-3 swapchain, so already you have 48 MB of screen buffers for any full-screen app that you don’t need to wait to redraw after you switch to it (remember when we needed to do that?). If said app is showing something large and scrollable, and you count on being able to see the thing you’re scrolling (remember when you couldn’t? thank touch input for killing that), that’s probably also, what, three, four screens’ worth of prerendered tiles? And now we’re already pushing a hundred megs—just for the pixels. How many browser tabs do you have open? (Personally, I get really irritated when my browser gets an attention deficit and doesn’t immediately show me the tab after I click on it.) Or thousand-page PDF specs?
(I was recently installing an old version of Windows in QEMU, and the installer showed me the installation wizard’s window—with all the text and controls—first and then spent multiple seconds blitting a purely frivolous graphic of a computer with installation disks around it onto the left pane. I didn’t remember computers used to do that! At least until you got around to installing the graphics driver, anyway, I guess.)
Second, I’ve been mulling over a Web browser’s job, and I can’t help but conclude that it’s really bloody awful.
The existence of the mutable DOM means it has to maintain a full-fat syntax tree for all the HTML—a humongous soup of pointers in a 64-bit address space (so in modern browsers they are hand-rolled 32-bit not-really-pointers). On top of that it needs to have an acceleration structure for style recomputation accessed on the critical user interaction path (because :hover), as well as a layout tree with line boxes supporting dynamic Unicode- (even BiDi-) aware line breaking and perhaps even hyphenation on resize, and none of that should fall over if you load up War and Peace in the original Russian+French with the paragraph breaks deleted.
It’s old compiler lore that no syntax tree will be as compact as the source code it was constructed from. Browsers sound like the bottommost circle of syntax tree hell even more than a general GUI has to be. The situation is probably salvageable with a flattened representation like the one Jetpack Compose uses and differential execution[1] used before it. But it’s definitely a lot of work, and to my admittedly cursory knowledge noöne’s really working on it.
(This part inspired by the urge to clutch my pearls that I felt while watching Andreas Kling’s Ladybird videos—there’s a lot of very thicc pointer soup in there, and I don’t think it’s possible to morph it into something saner in a continuous fashion. But then I thought about the problem, and yeah, the problem sucks.)
So all in all I think single-digit gigs sound about fair, I think, and that’s how much my system typically shows when I’m not deliberately running heavy stuff on it.
(For what it’s worth, I once spent weeks cramming all data required for Unicode normalization into about 20K. It’s certainly possible, but as it turns out, three iterations of fetch-shift-popcount for every character is slow. Not “why do I need to wait for my computer” slow, but definitely “why does my computer’s SSD have to wait for its CPU” slow.)
[1] https://stackoverflow.com/questions/4445656/what-is-differen...