4 ms·

> But what really made TP 7 special was its CP/M heritage. Turbo Pascal came to Windows by way of CP/M and MSDOS, which meant it had a compiler core that was de

> But what really made TP 7 special was its CP/M heritage. Turbo Pascal came to Windows by way of CP/M and MSDOS, which meant it had a compiler core that was designed to run with tight memory and a comparatively slow CPU. In the days when most compilers had to write a stack of intermediate files on disk, TP just constructed everything in memory. [...] It doesn’t matter much today if your compiler spits out a heap of temporary files, because disk storage is fast and cheap. But in the days of the floppy disk, you had to minimize disk access. Unfortunately, you also had to minimize memory use, because there wasn’t much of that, either. Of course, the “heap of temporary files” is itself originally an adaptation for low main memory. The genius of Turbo Pascal is exactly that on those early PCs main memory was large enough / mass storage was small enough that for the program sizes in question the architecture of many passes communicating via disk files just wasn’t worth it. As far as I know, that was never true on minicomputers that our compiler tech was born on, and it’s very much not true on PCs now. (Consider: DOS machines had 100s of K to perhaps 4M of RAM and a couple megs to several dozen megs of floppy or disk, amounting to a proportion of perhaps 1:20. The laptop I’m typing this on has 4×10¹² bytes of mass storage and 64G bytes of RAM, a ratio of about 1:60, and I specifically made sure to get an abnormally large amount of RAM.)

renewedrebecca 2y ago
You’ve got to wonder though: why in the world do we need that much memory?
- mananaysiempre 2y ago
  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.) [1] https://stackoverflow.com/questions/4445656/what-is-differential-execution https://stackoverflow.com/questions/4445656/what-is-differen...
- ASalazarMX 2y ago
  Just like porn advanced web technologies, videogames advanced PC hardware. Don't believe anyone who tells you that porn and videogames are useless, they were the recreative equivalent of the Apollo Program.

renewedrebecca 2y ago

You’ve got to wonder though: why in the world do we need that much memory?

mananaysiempre 2y ago
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.) [1] https://stackoverflow.com/questions/4445656/what-is-differential-execution https://stackoverflow.com/questions/4445656/what-is-differen...
ASalazarMX 2y ago
Just like porn advanced web technologies, videogames advanced PC hardware. Don't believe anyone who tells you that porn and videogames are useless, they were the recreative equivalent of the Apollo Program.