5 ms·

Worthwhile? We had PAE for a long time, sure, but I think it was fairly obvious when the Athlon 64 appeared that 4GB was not going to cut it, given some people

Worthwhile? We had PAE for a long time, sure, but I think it was fairly obvious when the Athlon 64 appeared that 4GB was not going to cut it, given some people already had 1GB at home...

jdsully 7y ago
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.
- srgpqt 7y ago
  1GB is still a lot of memory. If anything, we've only learned to squander all available memory.
  - vokep 7y ago
    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.
  - derefr 7y ago
    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.
    - saagarjha 7y ago
      I wouldn’t be so sure.
    - mehrdadn 7y ago
      What are you calling "disk" here? It's not every day that I see a machine with a disk slower than its network connection.
      - tedunangst 7y ago
        That might describe every rpi running off SD.
        boring_twenties 7y ago
        I dunno, not sure about the latest Pi models but the network performance was horrid on the earlier ones, like 20Mbits/sec tops.
        Piskvorrr 7y ago
        If you're talking RPi1, perhaps. That's 2012, however...and one of the first things to get better in every further model.
      - eru 7y ago
        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).
    - trasz 7y ago
      The irony is, on the other end the inverse is true - filesystem cache hit ratio on Netflix servers isn’t particularly high.
    - hvidgaard 7y ago
      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.
  - IvyMike 7y ago
    > 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.
- wahern 7y ago
  > 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.
  - nwmcsween 7y ago
    There were a few benchmarks IIRC where it showed a big improvement, the problem was that x32 ABI was horribly botched.
  - sprash 7y ago
    > 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.
- BruiseLee 7y ago
  Consensus? I would call it dissensus actually.
jandrese 7y ago
PAE was always a terrible hack though. It caused so many problems that I'm super glad native 64 bit became the norm shortly before it would have had to become widespread.
- devit 7y ago
  It's not a terrible hack, it's just 32-bit virtual addresses with a larger physical address space. It only caused problems because some kernels used to expect that all physical memory is mapped at all times (and some hardware could only DMA to 32-bit physical addresses, but that's a problem with 64-bit CPUs as well).

Worthwhile? We had PAE for a long time, sure, but I think it was fairly obvious when the Athlon 64 appeared that 4GB was not going to cut it, given some people already had 1GB at home...

jdsully 7y ago

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.

srgpqt 7y ago
1GB is still a lot of memory. If anything, we've only learned to squander all available memory.
- vokep 7y ago
  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.
- derefr 7y ago
  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.
  - saagarjha 7y ago
    I wouldn’t be so sure.
  - mehrdadn 7y ago
    What are you calling "disk" here? It's not every day that I see a machine with a disk slower than its network connection.
    - tedunangst 7y ago
      That might describe every rpi running off SD.
      - boring_twenties 7y ago
        I dunno, not sure about the latest Pi models but the network performance was horrid on the earlier ones, like 20Mbits/sec tops.
        Piskvorrr 7y ago
        If you're talking RPi1, perhaps. That's 2012, however...and one of the first things to get better in every further model.
    - eru 7y ago
      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).
  - trasz 7y ago
    The irony is, on the other end the inverse is true - filesystem cache hit ratio on Netflix servers isn’t particularly high.
  - hvidgaard 7y ago
    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.
- IvyMike 7y ago
  > 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.
wahern 7y ago
> 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.
- nwmcsween 7y ago
  There were a few benchmarks IIRC where it showed a big improvement, the problem was that x32 ABI was horribly botched.
- sprash 7y ago
  > 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.
BruiseLee 7y ago
Consensus? I would call it dissensus actually.

jandrese 7y ago

PAE was always a terrible hack though. It caused so many problems that I'm super glad native 64 bit became the norm shortly before it would have had to become widespread.

devit 7y ago
It's not a terrible hack, it's just 32-bit virtual addresses with a larger physical address space. It only caused problems because some kernels used to expect that all physical memory is mapped at all times (and some hardware could only DMA to 32-bit physical addresses, but that's a problem with 64-bit CPUs as well).