Samsung wil 'processing-in-memory' toevoegen aan DDR5- en Lpddr5-geheugen

Samsung werkt aan DRAM-geheugen voor consumenten-pc's voorzien van een geïntegreerde chip die rekentaken kan uitvoeren op het geheugen, waardoor voor sommige taken geen cpu nodig is. Samsung past dat momenteel al toe in zijn HBM-PIM-chips voor serverhardware.

Samsung heeft zijn HBM-PIM-chips, ofwel high bandwith memory met processing-in-memory, in de praktijk getest in combinatie met een Xilinx Virtex Ultrascale+-accelerator voor AI-berekeningen. Samsung claimt dat dit prestatieverbeteringen tot 2,5x en energiebesparingen tot 60 procent oplevert. De fabrikant spreekt daarbij de intentie uit om near-memory processing-technologie, of processing-in-memory zoals Samsung het noemt, toe te voegen aan consumentengeheugen.

Volgens Tom's Hardware heeft Samsung op Hotchips 33 meer details daarover gegeven en gaat het om DDR4-, GDDR6 en Lpddr5x-modules. Op renders van Samsung is ook DDR5-geheugen met een programmable computing unit te zien. Samsung noemt dat een Axdimm, ofwel Acceleration DIMM.

Near-memory processing is nog een grotendeels theoretische technologie waar momenteel onderzoek naar gedaan wordt. In feite voegt het een geïntegreerde processor toe aan de bufferchip, die zelf rekentaken kan uitvoeren op de geheugenmodule. In februari maakte Samsung bekend te werken aan HBM2 met 'geïntegreerde AI-rekenkracht'.

Het idee achter de module is dat bepaalde AI-berekeningen op de geheugenmodule worden gedaan, zonder dat de cpu daaraan te pas komt. Daardoor hoeft er minder data heen en weer gestuurd te worden tussen de cpu en de geheugenmodule. Dat levert minder bottlenecks op, versnelt het uitvoeren van berekeningen en zorgt voor een lagere energieconsumptie, aldus Samsung. Het nadeel is dat er op de module ruimte moet worden vrijgemaakt voor de chip, zodat er minder geheugencapaciteit is.

Volgens Samsung zijn de modules met processing-in-memory al geschikt voor gebruik in standaard geheugensleuven, maar het bedrijf zegt tegen Tom's Hardware te hopen dat cpu-makers aanvullende ondersteuning voor de technologie gaan ontwikkelen, zodat de samenwerking tussen het geheugen en de processor geoptimaliseerd kan worden.

In februari kondigde Samsung het eerste geheugen aan dat voorzien was van een geïntegreerde processor, de HBM2 Aquabolt. Dat geheugen is voornamelijk bedoeld voor snelle dataverwerking in supercomputers en AI-applicaties. Samsung testte de processor bovendien in de Xilinx Virtex Ultrascale+ AI-accelerator.

Tests met HBM-PIM hebben volgens Samsung uitgewezen dat de techniek ook geschikt is voor geheugenmodules gericht op computers voor consumenten en ook voor geheugen in smartphones. In de eerste helft van 2022 hoopt Samsung het processor-in-memory-platform, of PIM-platform, gestandaardiseerd te hebben zodat andere fabrikanten er ook mee kunnen werken.

Reacties (53)

Dat wortd nog een leuke voor de CPU cache. Normaal gesproken veranderen bits in het geheugen niet spontaan, dus de CPU memory controller kan gewoon de laatst geschreven waarde bewaren. DMA gaat niet coor een CPU core, maar de memory controller weet het wel, dus dat gaat nog goed.

Kijk, voor simpele opdrachten als "zero page X" kan de controller nog wel detecteren dat het geheugen die heeft uitgevoerd, en sterker nog, die zou dat ook meteen in cache kunnen doorvoeren.

Het geheugen registreer je als non-cacheable write-combining (tenzij de controller over cache-coherency protocols beschikt) en vervolgens lock je tijdelijk de bus gedurende je DMA operatie.

Voor de 3D renderer die ik ooit schreef zou ik een moord gedaan hebben voor een snellere 'zero page x'. Die depth buffer clearen heb ik altijd als zonde tijd gezien.

Zou ook mooi zijn als RAM daarmee RDMA (Remote Direct Memory Access) mogelijkheden krijgt. Dus in plaats van dat de CPU altijd tussen een medium en het RAM zit, dat de CPU de opdracht geeft aan het RAM om geheugen te laden vanaf een medium.

GPU's kunnen dit al en daarvan beginnen de voordelen zichtbaar te worden (directstorage).

[Reactie gewijzigd door CykoByte op 24 augustus 2021 16:01]

CPU de opdracht geeft aan het RAM om geheugen te laden vanaf een medium.

Nu heb ik wellicht een beetje onder een steen gelegen (komt uit uit 8086, z80 tijdperk), maar dat is precies wat DMA doet.

Het onderscheid DMA en Remote DMA is wie de DMA-controller is. Als RAM zelf een DMA-controller heeft, zou data kopiëren van geheugenlocatie 1 naar geheugenlocatie 2, zonder tussenkomst van de CPU kunnen.

Als de DMA-controller op de CPU zit, kan het wel zonder tussenkomst van de CPU-kernen, maar moet de data nog wel fysiek langs de CPU. Met latency als gevolg.

Maar met directstorage moet de data toch ook alsnog langs de CPU. Het grote verschil is dat de GPU de data zelf kan uitpakken, maar de latency van die detour blijft er ook met directstorage. Het is niet alsof de GPU ineens direct verbonden is met de M.2 slots.

Ja, daar heb je gelijk. Die verbinding loopt altijd via de CPU inderdaad. Stom genoeg over het hoofd gezien

Klassieke controllers die DMA ondersteunden waren disk/printer controllers die dat al zelfstandig deden.
(SASI/SCSI dan) de 8089 was al een universele DMA controller volledig naast de CPU voor de 8086/8088.
Toen virtual memory op kwam zetten leverden Intel en co een soort van DMA controller op de chip mee om de mapping in orde te maken.
Bij andere leveranciers zoals DEC hadden de controllers mapping registers als een soort van "Light" pagetables.

Intel heeft er zelf voor gekozen om de DMA controller naar binnen te trekken vanaf de 80186.

Dus het copieren gaat een stuk sneller?zonder tussenkomst van de processor als ik goed gelezen hebt.

En weer een nieuwe attack-vector erbij.

ja ik houd het zelf ook liever bij een telraam, daar kunnen ze alleen naar binnen als ze hardware access hebben

een telraam met ethernet-aansluiting! Ik vraag direct patent aan!

te laat, nu is het gepubliceerd

Behalve voor US ingezetenen, die kunnen nog een jaar terug claimen.

Dat was waar ik ook meteen aan dacht. Lijkt me ook leuk om malware hierop te gaan analyseren. Zelfs je memory kan berekeningen gaan doen ...

Als je Computers sneller wilt maken, moet je denk ik vooral eens kijken wat ze langzamer maakt, zaken als:
* Legacy
* Bottlenecks zoals de bandbreedte naar het geheugen, beperkt aantal decoders
* Meerwerk zoals het heen en weer kopiëren van data van GPU geheugen naar CPU geheugen
* veel voorkomende taken in SW oplossen die in HW kunnen worden opgelost
De huidige Wintel PC is een stapel op een stapel op een stapel van oplossingen die steeds complexer zijn met heel veel ducttape en Tiewrap oplossingen, achterwaartse compatibiliteit en bottlenecks die het gevolg zijn van bepaalde keuzes uit het verleden.
Wellicht beter iets geheel nieuws te bedenken.

Legacy code is vaak juist beter geoptimaliseerd dan nieuwe code. Tegenwoordig wordt al snel naar python of andere high-level talen gegrepen omdat het makkelijker (en vooral sneller) te ontwikkelen is. Dat levert over het algemeen een bij elkaar geraapt zooitje van libraries die niet het onderste uit de kan halen qua performance.

Dus "Wellicht beter iets geheel nieuws te bedenken." zal hoogst waarschijnlijk niet sneller resultaat opleveren, plus veel fouten die in het verleden gemaakt zijn zul je opnieuw gaan maken.

Legacy code is vaak juist beter geoptimaliseerd dan nieuwe code. Tegenwoordig wordt al snel naar python of andere high-level talen gegrepen omdat het makkelijker (en vooral sneller) te ontwikkelen is. Dat levert over het algemeen een bij elkaar geraapt zooitje van libraries die niet het onderste uit de kan halen qua performance.

Dus "Wellicht beter iets geheel nieuws te bedenken." zal hoogst waarschijnlijk niet sneller resultaat opleveren, plus veel fouten die in het verleden gemaakt zijn zul je opnieuw gaan maken.

Maar Legacy sw daarentegen maakt geen gebruik van moderne instructiesets, Hardware acceleratie, is 16 of 32 bits etc etc

Dat ligt er aan of de code opnieuw gecompileerd wordt of gewoon de oude gekopieerd.

Overigens maakt 32 of 64bit niet heel veel uit voor de snelheid, tenzij je enorme hoeveelheid ram gaat gebruiken.

Ik bedoel ook niet te zeggen dat legacy code per se sneller is. Dit is meer in het mom van nieuw is niet per se beter.

32 bits code heeft zelfs het voordeel dat het minder bandbreedte naar RAM nodig heeft - alle pointers zijn 50% kleiner. Het maakt dus ook je caches efficienter.

Berekeningen in het geheugen uitvoeren is toch juist een HW ipv SW oplossing, geheel nieuw en ontwijkt de bottleneck van de bandbreedte tussen CPU en RAM??

Legacy is trouwens verdomde handig, of wil jij iedere generatie alles nieuw moeten kopen? Van al je USB devices tot harde schijven, en van je monitor tot je modem?

Ik moet zeggen dat ik mijn USB2 Devices allang niet meer gebruik, en een analoge of DSL modem heb ik ook al lang niet meer, geen PS2 etc etc etc

Heb hier nog een muis, videocamera, gamepad en externe HDDs allemaal USB2.

gebruik je ook nog floppies, Iomega drives, PS2, DIN aansluitingen, Parallelle poort, 25 Pin SCSI? CD ROM?

Meeste toetsenborden en muizen zijn gewoon nog Usb2 omdat 3 overkill is.

Floppies, ja. En dan wel de echte 5 inch gevallen. Ook cassete tapes (C64).

Er is natuurlijk wel een reden dat de legacy code er nog in zit, veelal door het bedrijfsleven. Daarnaast vind ik het ook niet vervelend dat mijn spel uit 1998 het nog doet op mijn nieuwe PC

Dat was hele lange tijd de HDD. Nu kunnen ze state op gaan slaan en uitlezen en heb je geen memory meer nodig, over 5 jaar zal dat wel erin zitten.

Ja dit is echt een hele mooie vooruitgang, zo'n stukje toekomst dat over 10 jaar misschien als de normaalste zaak van de wereld klinkt maar nu nog zo abstract lijkt.

Het gaat CPUs begrijpen wel nog complexer maken dan het al is, in de toekomst (en nu al een klein beetje) zal de tech zo geavanceerd worden dat het gewoon niet mogelijk zal zijn voor andere bedrijven om uberhaupt te concurreren vanwege de bizarre hoeveelheid specifieke kennis die je nodig hebt om gelijksoortige producten aan te bieden.

Inderdaad, dit gecombineerd met de chips die door middel van AI ontworpen worden (wat recent al op zeer basaal niveau gedaan is, maar ook complexer zal worden), zal er voor zorgen dat het heel uitdagend wordt om de ontwikkeling van hardware en algoritmes (wat steeds meer verwoven zullen worden door neuromorphic computing) bij te blijven en te blijven begrijpen hoe een computer functioneert en dus redeneert.

We zullen het functioneren ervan goed aan bepaalde banden moeten leggen om computers als mens nog te kunnen blijven begrijpen in de toekomst.

mini-CPU in geheugenbankjes
video-chip in CPU

Wanneer komt de chip die alles verzorgt?

One chip to rule them all?

Bedoel je zoiets als de M1?

of snapdragon, of elke simpele SOC (je weet wel, System On Chip)

of snapdragon, of elke simpele SOC (je weet wel, System On Chip)

Maar bij een SOC zoals snapdragon zit het geheugen (behalve cache) toch buiten de SOC?
Daarom hebben verschillende telefoons verschillende hoeveelheden geheugen, dacht ik. Of loop ik achter?

on-package, maar buiten chip. Net zoals de M1: daar zit het ook niet in de chip. Maar op de package. Denk chiplets.

Aha, weer wat geleerd. Dankjewel.

Klopt, en bij de M1 is dat ook vziw.
Alleen knopen ze dan de SoC en RAM direct aan mekaar vast (zonder printplaat).
Bij dit Samsung gebeuren werkt dat ook zo, begrijp ik van hier.
Of je zo'n combi dan nog 1 chip "mag" noemen kan je van mening over verschillen.

Gebruikt de M1 niet ook de SSD als DDR, waardoor in sommige Mac Books de SSD in een jaar tijd al bijna over z'n maximaal aantal writes heen was?

Ik liep inderdaad achter. Maar het is wel logisch dat ze dat zo doen om telefoons kleiner te maken.

ja maar da's Apple he, niet voor desktop-pc's waar je mee kan gamen

Bijna iedere chip die turing-complete is kan dat.

Oh, ik zie dan wel mooie toepassingen met versleuteld werkgeheugen voor me.

Wat voor soort operaties op het geheugen hebben we het dan over? Weet iemand dat?

Zal dit ook interessant worden voor de miners aangezien met GPU minen voornamelijk op het geheugen plaatvindt? Dan hebben we straks niet alleen GPUs die massaal door miners worden opgekocht maar ook ram. Misschien een domme vraag voor de expert, maar ik ben wel benieuwd.
Hopen dat proof of stake bij ethereum ervoor zorgt dat GPUs straks weer in de handen van gamers komen

Ik vraag me dan toch af hoe ze dat in sync denken te houden met oa de CPU cache (L1,L2,etc) en de registers. Daar zouden dan toch ook nieuwe instructies voor te moeten gaan komen? (of iig op een x86 cpu)