Actual result: "This new process promises to increase the number of optical fibers that can be connected at the edge of a chip, a measure known as beachfront density, by six times."
Faster interconnects are always nice, but this is more like routine improvement.
IBM initially leads with the more salient point (current architecture designs are hindering frontier computing concepts), then just kinda…relents into iterative improvement.
Which is fine! I am all for iterative improvements, it’s how we got to where we are today. I just wish more folks would start openly admitting that our current architecture designs are broadly based off “low hanging fruit” of early electronics and microprocessors, followed by a century of iterative improvements. With the easy improvements already done and universally integrated, we’re stuck at a crossroads:
* Improve our existing technologies iteratively and hope we break through some barrier to achieve rapid scaling again
OR
* Accept that we cannot achieve new civilizational uplifts with existing technologies, and invest more capital into frontier R&D (quantum processing, new compute substrates, etc)
I feel like our current addiction to the AI CAPEX bubble is a desperate Hail Mary to validate our current tech as the only way forward, when in fact we haven’t really sufficiently explored alternatives in the modern era. I could very well be wrong, but that’s the read I get from the hardware side of things and watching us backslide into the 90s era of custom chips to achieve basic efficiency gains again.
About 20 years ago the CS community was getting excited about optical memory. It promised to be huge, must faster than static RAM, and hold it's state. Tied directly to the CPU as a very large cache+RAM replacement it would have revolutionized computing. There were other advantages besides speed. One was that you could just pause the CPU, put the computer to sleep, then wake it up later and everything was already in RAM and computation would continue where it left off. Instant boot. Running apps would be instant, they were already in RAM and could be run in place. Prototypes existed but optical memory never happened commercially. Not sure I remember why, maybe couldn't scale, or manufacturing problems. There was also the problem that code is never perfect, so what to do when something stored became corrupted? Without a boot phase there would be no integrity checks.
Off topic, but does the sentence structure of STATEMENT-QUESTION MARK have a name? It's pretty annoying in my opinion. Why not write "IS the von Neumann bottleneck impeding AI computing?" instead?
9 comments
[ 2.9 ms ] story [ 30.0 ms ] threadARM processors primarily use a modified Harvard architecture, including the raspberry pi pico.
Faster interconnects are always nice, but this is more like routine improvement.
https://www.science.org/doi/full/10.1126/science.adh1174
Also they've been working on this for 10+ years so it's not exactly new news.
Which is fine! I am all for iterative improvements, it’s how we got to where we are today. I just wish more folks would start openly admitting that our current architecture designs are broadly based off “low hanging fruit” of early electronics and microprocessors, followed by a century of iterative improvements. With the easy improvements already done and universally integrated, we’re stuck at a crossroads:
* Improve our existing technologies iteratively and hope we break through some barrier to achieve rapid scaling again
OR
* Accept that we cannot achieve new civilizational uplifts with existing technologies, and invest more capital into frontier R&D (quantum processing, new compute substrates, etc)
I feel like our current addiction to the AI CAPEX bubble is a desperate Hail Mary to validate our current tech as the only way forward, when in fact we haven’t really sufficiently explored alternatives in the modern era. I could very well be wrong, but that’s the read I get from the hardware side of things and watching us backslide into the 90s era of custom chips to achieve basic efficiency gains again.