[HN Gopher] Researchers Develop Transistor-Free Compute-in-Memor...
___________________________________________________________________
Researchers Develop Transistor-Free Compute-in-Memory Architecture
Author : giuliomagnifico
Score : 82 points
Date : 2022-10-12 10:35 UTC (2 days ago)
(HTM) web link (www.allaboutcircuits.com)
(TXT) w3m dump (www.allaboutcircuits.com)
| FunnyBadger wrote:
| bilsbie wrote:
| I feel like this could be a really big deal?
| colonelpopcorn wrote:
| It seems much more viable as an alternative to transistors than
| fiber optics does.
| colinthompson wrote:
| 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?
| cogman10 wrote:
| > 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.
| amelius wrote:
| A metal case is not an obstruction for a static magnetic
| field.
| whatshisface wrote:
| 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.
| metadat wrote:
| Why is this?
| whatshisface wrote:
| Conductors shield against electric fields which 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.
| ilaksh wrote:
| 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.
| meragrin_ wrote:
| Isn't identifying flaws an important part of getting things
| to work?
| ilaksh wrote:
| 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.
| [deleted]
| sroussey wrote:
| Realistic optimists are required to effect change.
|
| Finding negatives is easy. Working through them to a
| positive result is gold.
| jimkoen wrote:
| Cybernetics isn't even close to bringing any decent advantage
| to a healthy human physiology over the next 25 years wtf
| ilaksh wrote:
| 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.
| solsane wrote:
| 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.
| obblekk wrote:
| 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.
| hoosieree wrote:
| 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.
| naasking wrote:
| Plenty don't though, like functional programming and relational
| databases. They're common enough these days.
| chowells wrote:
| 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/
| naasking wrote:
| > 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
| chowells wrote:
| Data Parallel Haskell has been deprecated since roughly
| when I started using Haskell. It's basically seen as a
| failed experiment.
| bheadmaster wrote:
| > 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?
| DSMan195276 wrote:
| 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.
| bheadmaster wrote:
| 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.
| DSMan195276 wrote:
| 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.
| josephg wrote:
| "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.
| xmcqdpt2 wrote:
| 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.
| bheadmaster wrote:
| 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.
| atoav wrote:
| 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.
| marshray wrote:
| 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.
___________________________________________________________________
(page generated 2022-10-14 23:01 UTC)