Researchers Develop Transistor-Free Compute-in-Memory Architecture | Hacker News Reader

Researchers Develop Transistor-Free Compute-in-Memory Architecture

allaboutcircuits.com

Exciting times. I wonder how scalable the materials tech is here.

In the past basically everything lost to Dennard scaling of silicon transistors. Then everything lost to massive capital spend to scale silicon transistors via other optimizations.

Now that we’ve clearly started hitting a wall (see Nvidia CEO recent statement on hardware no longer getting cheaper each cycle), these alternative paths may actually be able to compete on their own exponential learning curve.

That would further hurt silicon transistor scaling as manufacturers like TSCM shifted resources toward new materials scaling, creating a strong positive feedback loop.

As long as there’s some amount of scaling learning curve in a new material, it seems like the markets will shift rapidly (best guess 5-10 years) whereas before nothing could catch the exponential learning of silicon transistors.

Non-von Neumann architectures have a lot of catching up to do on the software side. Nearly every mainstream programming language has "get one thing from memory, compute on it, put it back" semantics.

> Nearly every mainstream programming language has "get one thing from memory, compute on it, put it back"

As far as I remember, non-von Neumann architectures (Harvard architecture being the textbook example) are ones where program code is not stored in the same memory as data (please correct me if I'm wrong). Since most of the modern programs don't rely on modifying code in execution, why would software for non-von Neumann architectures be any different from the current software for von Neumann architectures?

The big difference in that situation is that you need to know whether a pointer is to your code memory or your data memory, most languages assume a single address space and don't make a distinction. Technically it's possible for the compiler/runtime to track that information and hide it from you but it would have overhead.

If you look at writing C programs for AVR (Harvard architecture) there's a lot of extra stuff provided to allow reading from "program memory", with all regular pointers reading from RAM/data memory.

I see - since most of the currently popular languages are object-oriented and implement inheritance through virtual table of function pointers, that would certainly at least slow things down significantly.

Thanks for the clarification.

Well function pointers are actually an interesting case, function pointers should always refer to the program memory and thus aren't ambiguous. Things like string literals are a problem though, you want them to be in the read-only program memory but most functions just take a `const char ` and have no way of indicating where the string is stored. And on the other side, if you _do_ opt to provide this information on every `const char ` that creates a whole lot of overhead to actually reading the contents of the string.

“Most” of the currently popular languages?

That’s true for C++ and maybe Java and C#. Is that true for python or javascript? Swift?

It’s definitely not true for newer languages like Scala, rust or zig.

CPython uses function pointers heavily, although not for vtables, but hash tables (since almost everything in Python is a hash table). I don't know about V8 and JVM, but even if they managed to avoid function pointers, they still rely on JIT compilation, which is as problematic for non-von Neumann architectures, if not worse.

I should've phrased things differently not to imply that all of them use vtables - vtables was just the first example that popped to my mind.

Scala is object oriented and anyway even if you write non OOP code it ends up (usually) on the JVM so you still get all the virtual tables stuff. If anything idiomatic Scala usually has significantly more pointer indirection than Java.

Plenty don't though, like functional programming and relational databases. They're common enough these days.

Eh. Most functional languages actually serialize operations pretty linearly in their default evaluation model, which is why they have explicit constructs for parallelism and concurrency.

There are some languages that are intended to parallelize implicitly, though. They tend to use keywords like "data-parallel" and "array language" to describe themselves. Futhark is a good example: https://futhark-lang.org/

> Most functional languages actually serialize operations pretty linearly in their default evaluation model, which is why they have explicit constructs for parallelism and concurrency.

Yes, but evaluation models can adapt easier when the language does not have explicit mutation, so there's less "catching up" to do for functional languages. Also concurrent programming will always require a separate class of constructs from parallelism.

There's also: https://wiki.haskell.org/GHC/Data_Parallel_Haskell

Data Parallel Haskell has been deprecated since roughly when I started using Haskell. It's basically seen as a failed experiment.

And co-dfns: https://github.com/Co-dfns/Co-dfns (subset of APL compiled for GPU).

I think what this is or could be (if I understood it correctly) is basically memory that can be configured to perform certain mutations "automatically" once you feed it data.

Imagine something like an FPGA but with memory.

So of course you have to find ways to make it do what you want, but that does not mean it could be combined with a traditional von Neumann architecture.

Based on the diagram this does matmul like a resistive crossbar array (something like https://arxiv.org/pdf/1410.2031.pdf). Talked about this in a ‘neuroprocessor’ class I took at uni.

It’s practically ‘free’ since you perform multiplication by applying resistance to a current, and kirchoff’s law results in a sumnation of currents. Very elegant in concept.

That being said, when scaling this approach, I recall one paper saying they had serious issues with signal integrity, in part from analog process mismatch.

If this AlScN approach addresses that this would be really big. I’m interested to see if this can scale beyond a small model like mnist and also about how they map the weights.

It's basic analog computing. However the 4-bit resolution is incredibly limiting. It's also not free since there will still be a setup and hold time you need to reach. Probably more power efficient but not free.

Are ferroelectric diodes more sensitive to external tampering than a “typical” memory circuit? As in, could a device like this be more easily “jammed” by a strong external electromagnetic source? That’s where my head went when reading about this circuit, but maybe it’s no less sensitive than “typical” circuitry?

Compute-in-memory can increase computation performance by many orders of magnitude.

The fact that most people just immediately try to find ways that these advancements can't work rather than trying to actually make them work is the reason that these things take so long to go from research to product.

And it's also an example of the type of weak cognition that will mean un-augmented humans will be irrelevant within the next quarter century.

Isn't identifying flaws an important part of getting things to work?

Sure when you get to that stage. But instead of trying to make things work, people always try to shut down ideas just because they are new. Actually the bigger the advance, the harder people try to discount the ideas.

Realistic optimists are required to effect change.

Finding negatives is easy. Working through them to a positive result is gold.

Cybernetics isn't even close to bringing any decent advantage to a healthy human physiology over the next 25 years wtf

It doesn't need to be close because these changes don't happen linearly. Look at for example computing in 1950 vs 1975 or 1975 vs 2000.

With a new computing paradigm we should anticipate at least a 500X increase in compute per dollar over a period of 25 years. We also should anticipate quite a lot of progress in AI and brain-computer interfaces.

Obviously what I suggested is speculation, but sensible speculation in these areas based on historical trends anticipates changes that are just as radical as the ones we have seen.

"Moore's Law" came close to a wall a long time ago and has been braking hard. Compute-in-memory will allow us to speed up again.

> Are ferroelectric diodes more sensitive to external tampering than a “typical” memory circuit?

Possibly? But the solution would be to put a Faraday cage around the memory. Something that effectively already happens when you have a heat sink on your memory. But further, you also have steal case surrounding your memory that helps there.

Although high permeability materials can route field lines around things to a certain extent, you can't get the kind of total magnetic shielding you'd want to say, protect a floppy disk from a strong magnet, without superconductors.

Why is this?

Conductors shield against electric fields and also catch EM radiation because it involves both E and M fields, but magnetic shielding relies on something analogous to electric polarization and consequently is more difficult.

A metal case is not an obstruction for a static magnetic field.

Previous HN discussions on the same topic:

Rethinking the Computer Chip in the Age of AI:

https://news.ycombinator.com/item?id=33129026

Gain is an essential property of transistor-like circuit elements.

Does this have the capability to amplify or oscillate?

This seems more analogous to the old core memory or diode-based ROM.

I feel like this could be a really big deal?

It seems much more viable as an alternative to transistors than fiber optics does.

Fiber optics is a fantastic alternative to copper cable. Has anyone claimed it's a reasonable alternative to transistors?

I guess for some people it'll always be 1987.

Reply on news.ycombinator.com