Jedec publiceert Lpddr5x-standaard met maximale snelheid van 8533Mbit/s

Standaardenorganisatie Jedec heeft een nieuwe Lpddr-standaard gepubliceerd. JESD209-5B is zowel van toepassing voor Lpddr5- als Lpddr5x-geheugen. Voor die laatste gaat de snelheid omhoog naar maximaal 8533Mbit/s.

Jedec heeft de specificaties van de standaard online gezet en fabrikanten kunnen die kopen. De organisatie schrijft in een persbericht dat de nieuwe standaard zowel geldt als een vervanging van de huidige standaard voor Lpddr5-geheugen, als een nieuwe standaard voor Lpddr5x.

Onder de nieuwe standaard blijft de maximale snelheid van Lpddr5 gelijk met 6400Mbit/s. De standaard is daar voornamelijk bedoeld voor betere prestaties, energiebeheer en flexibiliteit, zegt Jedec. Zo zijn er verbeteringen doorgevoerd aan de signaalintegriteit. Geheugen zou daarnaast stabieler worden doordat Adaptive Refresh Management wordt toegevoegd.

Voor Lpddr5x gaat de maximale snelheid wel omhoog. Die gaat van 6400Mbit/s naar 8533Mbit/s. Volgens AnandTech gaat daarmee de maximale theoretische bandbreedte voor mobiele socs omhoog van 51,2GB/s naar 68,26GB/s, wat betere cpu- en gpu-prestaties mogelijk maakt.

Samsung en Micron hebben samengewerkt met Jedec aan de Lpddr5x-standaard. Beide bedrijven maken al Lpddr5-geheugen, dat onder andere wordt gebruikt in smartphones, tablets, sommige laptops en in Valve's Steam Deck.

Reacties (17)

[Hetisweergezell]

Misschien een beetje domme vraag maar in wat voor soort toepassingen ga je deze snelheden echt merken? Is geheugensnelheid momenteel een bottleneck voor processors? Of is het net als met gigabit internet dat het leuk en aardig is maar dat alleen uber power users er iets aan hebben (maar de massa pas wanneer Netflix naar 8k op 240 hz gaat om maar even een raar voorbeeld te noemen)?

[johnbetonschaar]

Misschien een beetje domme vraag maar in wat voor soort toepassingen ga je deze snelheden echt merken? Is geheugensnelheid momenteel een bottleneck voor processors?

Afhankelijk van de toepassing is het antwoord 'ja, een beetje', of 'ja, dat ga je heel erg goed merken'.

Er zijn best wel wat taken die heel erg 'memory-bound' zijn kwa performance (in plaats van 'compute-bound' of 'I/O bound'), wat wil zeggen dat het geheugen de limiterende factor is, en het geen zin meer heeft om andere factoren (CPU speed bijvoorbeeld) verder op te schroeven. Vooral taken die grote hoeveelheden data in niet-lineaire volgorde van/naar het RAM lezen/schrijven (lineare geheugentoegang zoals copies/moves kunnen meestal efficient gebruik maken van de CPU cache, waardoor de snelheid van het RAM minder impact heeft).

Heel veel software is ook gewoon best wel slecht geschreven, zonder enige aandacht voor efficient gebruik van de CPU cache (ook games), dus daar ga je zeker voordeel zien van sneller geheugen.

En zoals hierboven al staat voor systemen met unified RAM waarbij CPU & GPU het geheugen delen gaat dit helemaal veel verschil maken, niet alleen omdat de bandbreedte gedeeld moet worden, maar omdat GPU's hoe dan ook al extreem bandwidth hungry zijn.

[Reactie gewijzigd door johnbetonschaar op 24 juli 2024 00:01]

[sapphire]

Nu wellicht nog weinig maar het is een net gedefinieerde standaard. Tegen de tijd dat dit op de markt komt of mainstream is is het vast wel nodig. CPU’s worden sneller dus de data moet ook sneller aangevoerd worden om al die cores te voeden

[bwerg]

Niet alleen de CPU's zelf, met een APU loop je gewoon hard tegen een bottleneck aan door gebrek aan geheugenbandbreedte voor de interne grafische processor.

De huidige APU's lopen achter op discrete videokaarten vanwege deze bottleneck. Ja, natuurlijk heeft een APU ook gewoon minder grafische rekenkracht maar met name AMD kan prima een krachtigere IGP maken. Dat heeft echter geen toegevoegde waarde zolang dat nog met DDR4 is.

[Vlizzjeffrey]

Goed punt, voor APU's gaat je graphics performance zo goed als lineair mee omhoog met de geheugenbandbreedte wanneer je het geheugen sneller maakt, dat maakt het tunen van die APU's zo leuk, er is zoveel extra performance uit te persen door je geheugen te overclocken en timings strakker te zetten.

[Vlizzjeffrey]

Met gamen ga je het in ieder geval merken, sneller geheugen zorgt vaak voor lagere frametimes in gebieden van games waar geheugen bandbreedte de bottleneck zijn, wat veel voorkomt in games.

[Marctraider]

Geheugensnelheid / latency is een bottleneck zodra de data die de processor nodig heeft niet gefetched kan worden van L1, L2, L3 of L4 cache (Mits aanwezig). Dan wordt uiteindelijk het geheugen aangesproken.

Dit is dus totaal afhankelijk van de software, waar je ziet dat de ene game/applicatie er baat bij heeft, en de ander juist weer totaal niet.

[Reactie gewijzigd door Marctraider op 24 juli 2024 00:01]

[Furrr]

Temperaturen ben ik erg benieuwd naar.

[Vlizzjeffrey]

Temperaturen zijn toch tot nu toe nog geen probleem geweest, zolang de fabrikant van de gpu zorgt dat de heatsink contact maakt met de geheugen modules?
Ik heb wel verhalen gezien van gpu's waarvan het geheugen heel heet werd, maar dat was dan omdat de fabrikant de gpu cooler gewoon verkeerd ontworpen had.
Heb nog niet gehoord dat deze dingen '' moeilijk'' te koelen zouden zijn, verwacht niet dat dat nu opeens het geval zou wezen bij deze nieuwe standaard.

[supersnathan94]

Gpu? Dit is gewoon RAM he? Wel low powered dus zal voornamelijk op so dimms en direct soldering voor laptops worden gebruikt.

[Vlizzjeffrey]

Ik noemde dat voorbeeld omdat ik enkel daar nog wel is hoor over te warme geheugen modules.

[JWL92]

Maar dit is toch helemaal geen gddr?

[Vlizzjeffrey]

Nee, maar ik noemde dat als voorbeeld omdat ik enkel daar wel is hoor over te warme geheugen chips, door een slechte heatsink design. Hadden de ddr4 lpddr4 geheugens dan wel veel last van hitte?

[Hilko113]

Is het niet 8533 MT/s (megatransfers per second) ipv Mbit/s ?

[JWL92]

https://www.youtube.com/watch?v=diZT3ly0vy4

[Henk Poley]

En natuurlijk: Ian Cutress: Explaining MHz vs MT/s

[jklu]

Grotere snelheid van geheugen betekent dat je data die te groot is voor de cache van je processor toch sneller kunt benaderen. Het hangt van het algoritme (en de programmeur ) af of je genoeg hebt aan de cache of dat je toch regelmatig naar RAM moet. De meest voor de hand liggende oplossing lijkt dan het groter maken van de processor cache maar ook dat is niet triviaal.

Voor de liefhebber:

Latency numbers that every programmer should know by year