So reflecting on that, I think the core assumption that didn't pan out is that the memory / CPU ratio will grow because we'll need more memory, hence requiring CPUs to address more than 16 EiB of data (16 EiB = 16384 PiB = 16777216 TiB of data, what 64 bits can address).

But in practice, we've produced a lot more compute. The memory / CPU ratio has increased, but most growth has been from more CPUs (and generally not shared-memory ones, but ones with their own completely separate memory space).

IPv6 is 128 bit, so we do have 128 bit ways of addressing computers, but I'd say we're still a long way from a CPU needing to address that much memory as a common case. The speed of light limits how far away memory can be from the CPU for good performance, so short of some drastically new memory technology, it seems unlikely we'll need it soon for any ordinary type of computing device.

▲

dist-epoch 2 days ago | parent | next [-]

Because of LLMs we are back to memory being king (KV cache).

But there was another thing - clusters of thousands/millions of machine instead of one big iron with all the memory.

▲

jsLavaGoat 3 days ago | parent | prev [-]

the cases where its useful, it's in vectorized instruction sets, etc.

▲

kelnos 3 days ago | parent [-]

You're conflating 128-bit registers with 128-bit memory addressing. This article is about the latter.

	▲	flohofwoe 2 days ago \| parent [-]
		Also arguably we already have 256 or 512 bit CPUs, what matters most for memory throughput is not the register width but essentialy the L1 cache line width (eg what in old CPUs was the databus width). As for address width, we're not even close to get full 64 bit pointers from CPUs anyway, more like 48 or 52 bits. Wide pointers (eg 128 bit general registers) would make sense for carrying capabilities for memory safety though I guess.