Hacker News Reader

Comment by jdsully | Hacker News Reader

At the time 1GB was a ton of memory and few applications would use anywhere near that. A 64-bit kernel took on fairly quickly but actually compiling 64-bit applications took a lot longer. Consensus at the time was the memory overhead of larger pointers outweighed the benefits of extra registers.

View on HN

> Consensus at the time

I wouldn't call it consensus, just a persistent claim by a large fraction of developers. They finally got to prove their claims with x32 ABI, which was ILP32 in amd64 mode, including the additional registers. Few if any people used it, nor did it show better performance in practice.

Regarding 64-bit support: by the time amd64 chips shipped people had been writing software for the 64-bit Alpha for 10 years, and 7 years for sparc64. IME most open source software was already 64-bit clean and worked well out-of-the-box. Back then the open source community, and especially GNU projects, heavily emphasized platform and hardware portability.

Perhaps the situation on Windows was different. It also didn't help that Windows kept long 32 bits, which had the effect of breaking code that cast between pointers and long (intptr_t didn't come until C99). The 64-bit ABI for all Unix platforms (AFAIU) carried forward the relationship between long and pointer. I don't think I ever recall seeing Unix or open source code casting a pointer type to int, only long; it was Windows software that presumed pointer->int conversions worked.

There were a few benchmarks IIRC where it showed a big improvement, the problem was that x32 ABI was horribly botched.

> Few if any people used it, nor did it show better performance in practice.

We use it for our specialized analysis framework. The real world performance gain is just shy of 30% which is impressive since all it took was a bunch of compiler flags.

Personally I think x32 is a vastly underused ABI. Every application that is unlikely to use more than 2GB should use it. It is literally free performance.

1GB is still a lot of memory. If anything, we've only learned to squander all available memory.

This. The basic stuff they did back then didn't magically inflate. Except, it seems from afar that thats exactly what happened. But it didn't, and it doesn't have to look like that from afar.

Go ahead and buffer 4k video streams to disk, I dare you :) There's a reason that even modern appliance platforms like Apple/Android TV need multiple GBs of memory, and it ain't bloat.

I wouldn’t be so sure.

What are you calling "disk" here? It's not every day that I see a machine with a disk slower than its network connection.

That might describe every rpi running off SD.

I dunno, not sure about the latest Pi models but the network performance was horrid on the earlier ones, like 20Mbits/sec tops.

If you're talking RPi1, perhaps. That's 2012, however...and one of the first things to get better in every further model.

An aside: that's often true in Google's data centres. So much, that someone wrote a system to sort-of swap out memory to other machines' RAM over the network (instead of to disk, which Google doesn't do in general).

The irony is, on the other end the inverse is true - filesystem cache hit ratio on Netflix servers isn’t particularly high.

If we aim high and say we need 50mbps of bitrate for 4k HDR, we still only need 6-7mb/s. So buffering 30 seconds is still less than 200mb.

It is entirely possible to make a modern system that use far less than they do today. If you're gaming it's a different beast, but for normal OS and programs it's certainly bloat.

> If anything, we've only learned to squander all available memory.

If I've learned anything in my computer career, it is that this is an evergreen comment. I remember reading Q-Link posts from Commodore 64 users with this complaint when the wasteful C128 came out.

Consensus? I would call it dissensus actually.

Reply on news.ycombinator.com