Hacker News Reader

Hacker News

Comment by hdjfjrbrbt | Hacker News Reader

Parent Full thread

hdjfjrbrbt

At 100 GHz signals can only propagate 3 cm per clock.

So to run at those speeds, you need extremely compact circuits, and you need to bring memory closer too.

Maybe move to 3D, another way to increase reach.

What is the current thinking regarding this problem?

View on HN

3mm rather than 3cm, but also note that full CPUs have to run slower than the upper limit of the transistors inside them, because most operations need to go through multiple transistors.

One thing to note is that this is a bit-serial adder. If you use this to perform, say, 32-bit arithmetic, then the effective clock rate is about 3GHz. Half that for 64-bit. Compare this to a PCIe4 bus, which is clocked at 16GT/s -- that is, each "lane" runs at 16GHz and is used to transmit data around serially instead of routing more wires around to make a wider bus. That's readily-available (damn the chip shortages) tech, but we can't buy 16GHz general-purpose processors.

Nothing you said was incorrect but I'm afraid people might take away a misconception. So, the adders you find in a modern processor are probably going to be a carry-bypass adder or something like that. For a constant factor more transistors you can complete your addition in sqrt(n_bits) time rather than n_bits. There are also tree adders which can can perform their calculations in log(n) time but take n^2 transistors but nobody uses those. Most modern processors have pipeline stages where you have one transistor driving 4 other 10 to 30 times or the equivalent. You can do that even with 64 bits in a clock cycle with a carry-bypass but not a serial adder.

https://en.wikipedia.org/wiki/Carry-skip_adder

It's a bit-serial adder not for any technical reason other than it's a convenient benchmark for characterization of the logic within. You could obviously use the process to make wide adders with faster clock speeds than stacking serial adders in front of each other.

I'm sorry, but that's not obvious. Given that we've got PCI circuits running at 16GHz, why don't chipmakers give us full-scale processors with those faster clock speeds?

Bit-serial adders are extremely simple circuits with a single carry register, which can run at essentially the full speed of the underlying switching devices. Ripple-carry adders have a circuit depth proportional to the number of bits in the adder -- they're only stable when the clock is substantially slower than the switching time (proportional to the circuit depth), because the carry signal needs to propagate through all of the 1-bit adders.

> I'm sorry, but that's not obvious. Given that we've got PCI circuits running at 16GHz, why don't chipmakers give us full-scale processors with those faster clock speeds?

That's not what I said. I'm just saying that it's obvious that if you wanted a fast 64 bit adder on the process, you'd build a carry lookahead adder or other fast adder, not stack a single bit adder 64 times. Saying "YOU NEED TO MULTIPLY PROP TIME BY 64" seems kinda dishonest.

I said:

> > You could obviously use the process to make wide adders with faster clock speeds than stacking serial adders in front of each other.

Do you really think the optimum thing is going to be stacking 64 of these in a row?

Ah, I misread you -- yes, there are obviously faster adder circuits. My point is that they won't have such impressive clock rates as this serial adder can achieve.

But for CPUs no one uses ripple carry, they use high radix adders like Kogge-Stone

Caches are already closer than 3cm and can take multiple cycles to fetch from. DRAM takes 100s of clock cycles to fetch from! It's bad -- but the badness was already here.

Propagation delay problems are real, but for caches IIRC the biggest problems are transmission lines being lossy and having propagation speeds much slower than the speed of light in a vacuum, and for DRAM the biggest problems are waiting for precharge and waiting for the sense amplifiers to stabilize. Waiting for the precision required to read obscenely small capacitors, in other words.

If DRAM is 1T1C and SRAM is 6T, I always wondered why we couldn't just have DIMMs of SRAM at 1/3rd the capacity or whatever. Overprovisioning DRAM by that factor is already common, wouldn't eliminating all the downtime be a way to put that slack to work? Like the HDD -> SSD transition? Ah well, I'm sure there's a constraint I'm just not thinking of.

You'd need a different CPU these days since the memory controller for sram would be a bit different. That said you do see sram in smaller embedded systems because it's also easier to drive and work with signal wise. I bet someone's done it as a research project with larger CPUs but I bet the cost of the SRAM and the cost of a niche cpu design just made it all not viable in the market place.

Right, memory controllers wouldn't be able to fully leverage SRAM DIMMs right out of the gate, but they would be able to partially leverage them right out of the gate and fully leverage them within a JEDEC cycle. It has been multiple JEDEC cycles since over-provisioning became common, so I suspect there must be something else preventing this.

SRAM costs way more, but afaik that's an artifact of market size, not fundamental. Hence the 1T1C vs 6T comparison to tease out the fundamental cost difference, which looks to be not worse than 3x-6x more expensive, which would put SRAM DIMMs will within reach. I lean on heinously expensive SRAM in my own embedded designs and would really like to see some market scale drive down those costs!

I was going to be really disappointed if this page's comments didn't involve the word "capacitor" at some point.

Million core processors, with each core in micrometer range, and threads occupying cores permanently. Cores will be assigned to processes like tiktaks (memory). Probably similar to the transition from bytes of ram to kbs of ram. Will be interesting to see how software expands to fill that space. Every program will become a distributed program. Supercomputers of today will be a commodity tomorrow.

Just so everyone is aware of the scales involved in modern circuits, an entire CPU Core like in Snapdragon 865 might only take up an area of ~3mm2, measuring just ~1.75mm across. 3mm gets you across the CPU and back again. We think in nanometers and picoseconds down here. (Not withstanding signals travel much slower than the speed of light in our tiny copper wires, remember t=RC)

Asynchronous schemes don't need to propagate clock through the whole scheme, so they don't have this limitation.

I remember research on asynchronous (or clockless) CPUs. Philips had an asynchronous ARM demonstrator.

Where did that go?

There would definitely be applications for a tiny ultrafast serial CPU with on-board RAM. Not all algorithms are parallelizable.

I'm imagining a small in-order 32-bit core with ~256KiB static RAM running at 100ghz. Call it the Serial Killer.

Reply on news.ycombinator.com