Hacker News Reader

Comment by PaulHoule | Hacker News Reader

On one hand The IBM System/38 used 128 bit pointers in the 1970s, despite having a 48 bit physical address bus. These were used to manage persistent objects on disk or network with unique ids a lot like uuids.

On the other hand, filling out a 64 bit address space looks tough. I struggled to find something of the same magnitude of 2^64 and I got ‘number of iron atoms in an iron filing’, From a nanotechnological point of view a memory bank that size is feasible (fits in a rack at 10,000 atoms per bit) but progress in semiconductors is slowing down. Features are still getting smaller but they aren’t getting cheaper anymore.

View on HN

I thought up a few ways to visualize 2^64 unique items:

- You could give every ant on Earth ~920 unique IDs without any collisions

- You could give unique IDs for every brain neuron for all ~215 million people in Brazil

- The ocean contains about 20 × (2^64) gallons of water (3.5267 × 10^20 gallons total)

- There are between 100-400 billion stars in the Milky Way, so you could assign each star between 46,000,000–184,000,000 unique IDs each

- You could assign ~2.5 unique IDs to each grain of sand on Earth

- If every cell of your body contained a city with 500,000 people each, every "citizen" of your body could have a unique ID without any collisions

Calculating these figures is actually a lot of fun!

There are only ~368 grains of sand per ant?

No wonder I keep reading about sand shortages.

Well no. See there's this one ant, Jeff, that's hogging them all for itself, so each ant only gets 50 grains grains of sand.

The common claim that there are ~7.5E18 (~2.5 × 2⁶⁴) grains of sand seems to originate from this back-of-the-envelope calculation:

https://web.archive.org/web/19990117001023/http://www2.hawai...

It takes only beach sand into account, and of course there's a lot of guessing involved. It could be easily off by many orders of magnitude.

Those are great examples

I think multiplying (1000 unique identifiers) isn’t fair but I like the gallons.

> filling out a 64 bit address space looks tough. I struggled to find something of the same magnitude of 2^64 and I got ‘number of iron atoms in an iron filing’

Reminded me of Jeff Bonwick's answer to the following question about his 'boiling the oceans' quip related to ZFS being a "128 bit filesystem":

> 64 bits would have been plenty ... but then you can't talk out of your ass about boiling oceans then, can you?

Sadly his Sun hosted blog was eaten by the migration to Oracle, so thanks to the Internet Archive again:

http://web.archive.org/web/20061111054630/http://blogs.sun.c...

That one dives into some of the "handwaving" a bit:

https://hbfs.wordpress.com/2009/02/10/to-boil-the-oceans/

And that one goes into how much energy it would take to merely spin enough disks up:

https://www.reddit.com/r/DataHoarder/comments/71p8x4/reachin...

One absolute limit of computation is that it takes

  (1/2) kT

of energy to delete one bit of information where k is the Boltzmann constant and T is the temperature. Let T = 300° K (room temperature)

I multiplied that by 2¹²⁸, and got 1.41×10¹⁸ J of energy. 1 ton of TNT is 4.2×10¹² J, so that is a 335 kiloton explosion worth of energy just to boot.

That's not impossible, that much heat is extracted from a nuclear reactor in a few months. If you want to go faster you need a bigger system, but a bigger system will be slower because of light speed latency.

(You do better, however, at a lower temperature, say 1° K but heat extraction gets more difficult at lower temperatures and you spend energy on refrigeration unless you wait long enough for the Universe to grow colder.)

In fairness, the need for 128-bit addressable systems will be when 64 address bits is not enough. That will be long before people are using 2^128 bytes on one system. So doing the calculation with 2^65 bytes would be a more even handed estimate of the machine that would require this

> 1.41×10¹⁸ J of energy.

Used over the course of a year, that is a constant 44.4 GW. Less than Bitcoin uses already

The AS/400 and iSeries also use 128-bit pointers. 128-bit would be useful for multiple pointers already in common use such as ZFS and IP6 addresses. I expect it will the last hop for a long time.

In the context of the AS/400's single-level store architecture the 128-bit pointers make a lot of sense, too.

Only 64 of those 128 bits are the actual address. The first byte indicates the type of object the pointer points to. The next seven bytes are (for some pointer types) used to encode security permissions (capabilities); for other types they are just reserved (all zeroes). So taking up 128 bits is more about capability-based security and type safety than the single-level store per se; the single-level store would have worked about as well with only 64-bit pointers. There is also a 129th bit (tag bit) which helps detect unsafe pointer modification. (The tag bit is stored using ECC memory’s extra bits for storing the error correction, which happen to have one spare bit per every 16 bytes.)

Conceptually similar to ARM Morello/CHERI’s 129 bit pointers; although that is a much more sophisticated implementation than IBM 38/400/i.

Those are evolved from the System/38.

Yeah, IBM is one company that shows how to push the models down the road. They do take their legacy seriously.

> On one hand The IBM System/38 used 128 bit pointers in the 1970s, despite having a 48 bit physical address bus.

And the original processor was 24 bits, then it was upgraded to 36 bits (not a typo: 36 bits), and then to POWER 64 bits.

(When that last happened, it was re-badged AS/400. Later, marketing renamed the AS/400 to iSeries, and then to IBM i, without changing anything significant. Still uses Power CPUs, AFAIK).

For users, upgrades were a slightly longer than usual backup and restore.

What's the hard part here?

IBM i is still in development and also has a 128 bit pointer.

Reply on news.ycombinator.com