Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Bro there's an IANUS acronym in this article and nobody has said anything. Shame on you all

    PIM (XBM, ZAM, etc) are all cope. This 600GB of throughput is ~4.5x higher than the 130 you get from LPDDR5X on a 128 bit bus yet their deltas are only 2.2-3x? I just don't see this being a corner worth cutting over simply paying the cost of a wider bus. Think of all the fun new rowhammer shit this will be able to do to itself

  • Bro, I’m not following. Can you elaborate? - concretely PIM is cope. And the argument that this is bad because rowhammer and how a wider bus would be better.
  • What ever happened to the idea of using memristors for this?
  • Integrated RAM with tensor processing seems like the end game for silicon that's actually efficient at running AI models.

    Or integrated flash with TPUs? That would be awesome. Flash your model onto a model-processor and run it.

    by api
  • I wonder if we might eventually see stacking of NAND, logic, and DRAM dies together so each can still be fabbed on their specialized process. Getting all three on one wafer is extremely impractical, but having them all connected with TSVs or other bonding might be feasible, if the density of the respective dies works out right to give you the right ratio of storage for weights, working memory, and compute.
  • It looks like you tried somewhat, but you can still feel the claude-isms coming through in the writing. This can be fixed with better prompting and more writing examples.
  • AI focussed - as so much these days. Some corp. please put general-purpose cores in that RAM?
  • I looked at this for a client close to 20 years ago. The problem is that you need to get software support for it. Arguably easier these days with open source but still doesn't magically happen.
  • AI inference is basically 1 operation iterated over every single model weight. That's what's makes computer in memory attractive and feasible.

    General purpose workloads would require much more silicon real estate and are not (typically) nearly as bandwidth hungry. Just like not all CPU workloads benefit from being adapted to a GPU, even fewer will benefit from being adapted to processing in RAM.

  • Why does not the article say anything on how KV-cache is handled with in-DRAM processing? Is this trivially obvious?
  • So they built a very specific operation into the RAM. This RAM would only be useful for AI, otherwise the transistors are just wasted.

    And if we fund a different set of operations actually work better for AI you can’t adjust to that either.

    Seems extremely limited. But otherwise wouldn’t you just end up with something like a massive number of tiny microcontrollers each accessing a set of memory? The Transputer again.

  • I like the idea of a CPU/GPU/TPU on RAM (look at those gorgeous bandwidth numbers!) -- but I also wonder what problems it may potentially bring in the future... I think it would be a good idea that if RAM is to implement processors / PIM on it in the future, that each RAM stick should have an external DIP "safety" switch on the side which switches off such processing. If this switch is flipped by the user, then the stick simply falls back to operating as normal "dumb" RAM, driven by external CPU control. Also, it would be a good idea to have debug ports, debug proxying, single step capability, etc., in these futuristic RAM sticks, as well...

    Related:

    "SIMDRAM: A Framework for Bit-Serial SIMD Processing Using DRAM Extended Abstract" (2020):

    https://arxiv.org/html/2012.11890v1

    >"We leverage the SIMDRAM framework to accelerate seven application kernels from machine learning, databases, and image processing (VGG-13 [63], VGG-16 [63], LeNET [38], kNN [42], TPC-H [66], BitWeaving [45], Brightness [28]). SIMDRAM provides up to 2.5× speedup for the kernels compared to Ambit [58]. Compared to a CPU and a high-end GPU, SIMDRAM is 257× and 31× more energy efficient, while providing 93 × and 6× higher throughput, respectively."

  • That's like saying your CPU should come with a switch that makes it a four-function calculator. Which isn't how any of this works.
  • You seem to think that "compute in memory" would mean the disappearance of commodity DRAM parts and their replacement with parts that had compute capabilities. This is impossible. Adding compute to memory will make it more expensive, so it will get zero adoption outside of the niches where it actually proves to be useful and valuable. Nobody is going to be putting compute in memory chips onto standard consumer DIMMs.
  • "DRAM banks already provide most of the bandwidth; the external pins cannot expose it." Closed the tab.
  • Why would you want to read something someone was so sloppy at they didn't improve it with AI?
  • Processing in memory was one of the extra topics we covered in my grad computer architecture class. Fifteen years ago. And even then, it was very clearly an old-hat idea.

    One of the problems with trying to move a lot of ALUs close to the DRAM logic is that ALUs are pretty hot, and DRAM is some of the most sensitive components to heat. There are some other issues too, like the process manufacturing differences mentioned by a sibling comment.

  • Compute In Memory has been most of what electronics research (more accurately, the parts I am interacting with) talking about this year. There are a few trends and I am curious to see which ones survive in the market. RAM designers are hot in the market and job openings at the moment.
    by honr
  • > RAM designers

    How many RAM designer jobs are there in the world? 100? 1000?

  • "Processor-in-Memory", is an age-old idea which was even explored in a doctoral thesis from 1998: "Computational RAM: A Memory-SIMD Hybrid"*. At the time, the motivation was, "Between a DRAM chip and a microprocessor mounted on a circuit board, we can only get a few hundred megabytes per second of bandwidth. However, inside the memory chip itself, there's hundreds of gigabytes (terabits) of bandwidth available, so why not move some of the logic there?". And then the author pushed it to the extreme where there was a wide array of 1-bit processors at each column of DRAM. (Note: the reason why true PIM isn't viable is because of the radically different semiconductor process used for DRAM vs. high-speed digital logic, i.e.: your digital logic circuits will perform poorly on a "DRAM process").

    The designers of HBM5 had the same observations and thought, "why don't we put a logic chip at the bottom of the stack of HBM DRAM chips and get extremely high memory bandwidth?" But, in looking at this, you'll also quickly realize this is almost exactly what Intel and Micron pitched 15 years ago as Hybrid Memory Cube** (which lost on the market compared to the simpler, less costly, and more flexible alternative, HBM)

    * https://www.eecg.toronto.edu/~stumm/Theses/Elliott-PhD98.pdf

    ** https://en.wikipedia.org/wiki/Hybrid_Memory_Cube

  • Age-old... 1998... :grimace:
  • I think it goes back further than 1998. Several old systems had special memory locations where the numbers written would then read back changed. The Apollo Guidance computer for instance didn’t have a shift-right or shift-left cpu instruction. They would write data to a specific area of memory that would modify the data to shift bits around.

    Although I’m sure it’s quite different. The cpu and memory hardware is so completely different. And basic bit manipulation is hardly computation.

  • Duncan Elliott taught my graduate (IIRC) computer architecture course while writing that thesis - we all talked about C-RAM for a while.. And I think it was a rehash of an even older paper / discussion about that idea.