Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door Willem de Moor

Redacteur componenten

MIT werkt aan geheugenbottleneck

Snellere caches en cpu- en geheugenintegratie

Door , 19 reacties

3d-integratie van cnt-fets en rram

Een tweede onderzoeksgroep bij het Massachusetts Institute of Technology richt zich op een alternatief computerontwerp dat niet meer de klassieke Von Neumann-architectuur aanhoudt. Zoals elke computer in ons bezit, maakt een Von Neumann-computer gebruik van invoer die verwerkt wordt door een cpu, die data uitwisselt met geheugen en de resultaten van berekeningen ten slotte uitvoert. Juist omdat de communicatie tussen cpu en geheugen, zoals we op de vorige pagina zagen, vaak een bottleneck vormt voor de rekensnelheid van een processor, kijken veel onderzoekers naar alternatieven voor de Von Neumann-architectuur om computers sneller te maken.

De onderzoeksgroep van het MIT werkt samen met de Stanford-universiteit en gezamenlijk hebben ze in wetenschappelijk tijdschrift Nature een chip omschreven die geheugen en rekenkracht bij elkaar brengt, zodat de geheugeninterface niet langer een beperkende factor voor de rekensnelheid vormt. Bovendien hebben ze twee nieuwe technieken voor de fabricage van het geheugen en de cpu-transistors gebruikt. Voor het geheugen hebben de onderzoekers rram, oftewel resistive ram, gebruikt en de transistors van het rekendeel zijn gemaakt van koolstof nanobuisjes. De twee lagen zijn bovenop elkaar gemaakt, met een netwerk van interconnects tussen de transistors en het rram. Het rram fungeert niet alleen als dram, maar behoudt zijn data ook zonder spanning: het is dus zowel tijdelijke als permanente opslag.



Vooralsnog is de chip die door de onderzoekers gemaakt werd nog een prototype, maar de één miljoen rram-cellen en het cnt-transistordeel zouden aanzienlijk zuiniger zijn dan silicium- en dram-equivalenten. Als derde laag bouwden de onderzoekers nog een laag koolstof nanobuisjes die als sensors dienen om gassen in de atmosfeer te herkennen. Dankzij de 3d-integratie van rekenlogica, rram-opslag en sensoren kon alle sensordata parallel worden uitgelezen, iets wat met conventionele technologie tegen bandbreedteproblemen zou aanlopen. Bovendien zou dergelijke integratie met siliciumcomponenten niet mogelijk zijn, omdat die veel hogere temperaturen vergen voor verwerking dan de cnt's en rram-cellen.

Het is volgens de onderzoekers voor het eerst dat zo'n grootschalige integratie van cnt-fets en rram-cellen is gerealiseerd. Waar eerdere ontwerpen nog met enkele honderden transistors werkten, hebben de MIT- en Stanford-onderzoekers twee miljoen cnt-fets gecombineerd met één miljoen rram-cellen en ook één miljoen gassensors. De onderste laag bestaat overigens uit traditioneel op silicium gebaseerde logica, met erboven de cnt-fet-logica, rram-cellen en cnt-fet-sensors. Tussen de lagen zit steeds een isolerende laag waarin via's, of verbindingen, zijn aangelegd.



De chips met rram en cnt-fets zouden op termijn vooral geschikt zijn voor toepassingen in neurale netten of andere computers waarvan de werking lijkt op die van hersenen.

Reacties (19)

Wijzig sortering
Zijn registers nog steeds apart geheugen in een processor? En is dat geheugen nog sneller dan L1 cache en zit het nog dichter op de processor?
Ja, de registers zitten min of meer direct geintegreerd in de processor pipeline, aangezien ze de waarden bevatten waar de instructies hun operaties mee uitvoeren en hun resultaten weer naar terug schrijven. Eigenlijk bestaat meestal niet echt een enkele fysieke register file meer in veel moderne out-of-order processoren, (door o.a. register renaming, bypass busses etc etc). Zo is er vaak een working register file en een architectural register file waar verschillende kopieen van waarden zich in bevinden, waarbij de ene speculatieve waarden bevat (de processor weet nog niet of hij het juiste heeft uitgevoerd). Vanuit het oogpunt van het programma dat draait zal je alleen de architecturele waarden zien, aangezien ondanks dat er van alles out-of-order gebeurt, het toch een sequentieel machine model representeert. Over de register file kan je meer lezen op Wikipedia, maar dat artikel zag er een beetje uit als een complex zooitje.

De L1 cache zit overigens ook diep geintegreerd in de processor; de L1 data cache vaak in of tegen de load-store-unit, en meestal is die in slechts 3 kloktikken te benaderen om de meest gebruikte waardes uit het geheugen weer meteen snel terug in een register te kunnen lezen. De L1 instructie cache zal aan de fetch/decode kant van de processor diep geintegreerd zitten. Iets verder naar buiten, de L2 cache, zit vaak in de orde van 12-14 kloktikken, L3 cache zo'n 50-60, en extern geheugen dan heb je het over honderden klokcycli voordat de resultaten pas terug komen.
Zat vroeguhr de L2 cache niet op het moederbord? pentium1 enzo.
Daarna de L2 cache op de printplaat van de pentium2.
En pas bij de pentium3 daadwerkelijk op de cpu.
Hier staat het allemaal duidelijk uitgelegd:

https://en.wikipedia.org/wiki/CPU_cache#History

Overigens wel prachtig om te zien hoe computers nog steeds krachtiger worden. Het ziet er naar uit Moore's law misschien tot halt komt- gebrek aan creativiteit echter niet. "We hebben bijna geen ruimte meer om zaken nog kleiner te maken!" > "Ah dan bouwen we toch gewoon laag op laag!" Zo logisch, zo heerlijk. Ik ben alleen bang dat naarmate we dingen ingewikkelder maken er steeds meer kans is op falen. Ik doel hier een beetje op het hallelujah/omafiets principe waar de meesten onder ons bekend mee zijn: Er zit niks op dus er kan ook weinig kapot aan gaan! Zijn hier geen failsafes tegen? Wordt hier iets aan gedaan of bedacht?
Maar wordt het ingewikkelder? Of juist simpeler?

DRAM heeft een moederbord nodig en een connector, er zijn 'contactlijnen' nodig, er moet gesoldeed worden, en er moet altijd spanning op staan. Dat kan allemaal kapot.

Bij een SoC heb je minder onderdelen en het RRAM-geheugen is eenvoudiger aan te sturen omdat er niet altijd 'ververst' hoeft te worden. Het is niet modulair, dus niet te 'repareren', maar heeft minder onderdelen en contactpunten die kunnen falen. Verder heb je nooit risico op een niet werkende combo van MoBo, RAM en CPU: De boel is in de fabriek al getest.

Een 10nm-telefoon SoC is veel complexer dan een omafiets-CPU uit 2005 met externe North- (en South-?)bridge, maar gaat de SoC daarom ook eerder kapot?
Het risico dat iets kapot gaat, cpu of omafiets of whatever, zit met name in het vervaardigingsproces en veel minder in het design van zoiets. Naarmate iets complexer is, is het moeilijker te maken en dus meer risico op foutjes waardoor het tzt kapot gaat. Met chips zie je dat yield echt hoger worden en het procede dus beter wordt. Dat verlaagt ook failure risico (mits het design ok is na een x aantal iteraties).
itt de "gewone" P2, had de P2 Celeron >300MHz on-die L2 cache op corespeed (bron: ik had er een). Volgens mij was dat de eerste consumenten CPU die dat had.
En ja inderdaad had ik daarvoor een PC (486? P1?) waarbij de L2 op een soort van dimm zat.
Klopt. Dat concept is zelfs nog ouder; er zijn 386 borden met L2 cache sockets.

Het tweaken daarvan was ook al aan de orde: eerst hadden we 20ns, toen 15ns.
Op een gegeven moment had ik ergens 12 gevonden. Hup: 15 er uit, 12 er in.
Er is ook 10ns geweest, daar was lastiger aan te komen en vooral duur. Zelf nooit gehad.

Op simpele benchmarks was het effect op de toegang tot het geheugen ook direct zichtbaar.

Het waren 'klassieke chips' in DIL behuizing. Met een IC-trekker kon je de oude er vrij makkelijk uit halen, en de nieuwe er in duwen. (wel even je anti-statische polsbandje aan natuurlijk!)

Opa verteld uit de oude doos... ;)
Ik weet nog dat ik voor mijn fonkelnieuwe pentium 75(? weet niet meer) net niet genoeg geld had voor module van 128kb pipeline burst cache. Dat was weer zoveel extra krantenwijk dat ik het heb gelaten.
Het is een beetje een BS verhaal. Je kunt de geheugenbottleneck niet oplossen. Je hebt, met welke processor dan ook, een limiet aan het hoeveelheid geheugen dat je in de buurt van je processor kunt plaatsen (dat je snel wilt kunnen benaderen).

Vervolgens zit het volgende onderdeel zoals geheugen en/of processor een aantal klokcycli verderop. Het is ook een vrij fundamenteel probleem: Een processor en/of geheugen heeft een bepaalde fysieke grootte en de volgende zit dus, gegeven de lichtsnelheid, minimaal X clockcycli verder. Een nieuwe plaatsing laat dan wel ruimte over voor nieuwe programmeer methodes (zoals bijv. ook op een videokaart het geval is). Maar het is geen oplossing.

De rest is 'optimalisatie'. Wat ik nog mis is een bewijs dat voor applicatie X en architectuur Y de optimalisatie Z% is. Of dat voor applicatie X een architectuur Y optimaal is (voor stroomverbruik, executiesnelheid, chipkosten, koelingskosten of welke metriek je maar wilt verzinnen).

Het grote probleem is dus dat de meeste software niet goed met die geheugenbottleneck omgaat. Compile en/of programmeertechnieken ontbreken vaak.

Sorry voor de not-so-humble opinion.
Je bent wel gelijk..

Volgens mij is het nog niet goed mogelijk om voor een CPU of OS te bepalen hoe lang een bepaalde core actief moet zijn op een thread. Dat kan dus inhouden dat een cache opnieuw gevuld moet worden terwijl als de core nog XX ticks door had gegaan de thread afgerond had kunnen worden.
Dus slim het aantal context switches verminderen gebeurt nog niet in voldoende mate....

Zoals altijd... correct me if I am wrong...
Je kan ook anders tegen het op lossen van de bottleneck aan kijken, bijvoorbeeld ssd.
De Hdd was eerst de bottleneck van ieder systeem, totdat de ssd uitgevonden werd en steeds sneller wordt. Sata 3gb was al snel de volgende waarna 6gb ook al snel te traag was. Dus is ook voor die bottleneck een oplossing gekomen in de vorm van m.2
Dus met deze implementatie zou het geheugen geen bottleneck meer zijn en alles sneller worden tot de volgende bottleneck.
Het grote probleem is dus dat de meeste software niet goed met die geheugenbottleneck omgaat. Compile en/of programmeertechnieken ontbreken vaak.
Het grote probleem is dat de meeste software een soort "oneindig en exclusief" machine model aanneemt als het geschreven wordt, en helemaal niet ingesteld is op een "alles eerlijk delen" principe tussen verschillende software taken die binnen een systeem op de verschillende cores draaien. Het lijkt er op dat ze hier een mechanisme presenteren wat probeert te meten wat software nodig heeft en de hardware instelt dat er een meer optimaal performance punt bereikt wordt.

Nou vind ik het wel een heel mooi klinkend verhaal over herconfigureren van cache hierarchieen en dergelijke in dit artikel, maar mijn not-so-humble-opinion is dat het uiteindelijk allemaal neer komt op je cache allocatie en replacement policy. Hoeveel cachelines ga ik aan welke core/applicatie toewijzen, en welke gooi ik snel weer weg (streaming data), en welke hou ik extra lang vast (belangrijk deel van de working set, de stack, of instructies). Dat is natuurlijk een gebied waar uitgebreid onderzoek naar gedaan wordt, en al helemaal in het huidige multicore en Cloud tijdperk. Je wil immers een bepaalde Quality of Service (QoS) kunnen leveren, waar je zo min mogelijk last hebt van een "noisy neighbor".

Intel heeft hier overigens een tijdje geleden wat mechanismen voor geintroduceerd, zoals Cache Allocation Technology waar je bepaalde sets binnen je cache aan een bepaalde core/thread kan toewijzen, en de Code and Data Prioritization extensie daar op. Dus wat dat betreft vind ik het verhaal van deze herconfigureerbare caches helemaal niet zo spannend. Wat de beste cache is voor een applicatie? Het antwoord zal altijd zijn: zoveel mogelijk, op een zo laag mogelijke latency. Het interessantere deel hier is het algoritme wat ze gebruiken om hun QoS te bepalen en hoe ze een optimum proberen te vinden voor de performance over alle applicaties.

[Reactie gewijzigd door Squee op 10 juli 2017 23:35]

Het is voor een cpu vrij goed mogelijk een profiel op stellen van datgeen dat uitgevoerd word ook lijkt het me geen (groot) probleem om threads die gedeelde data in L3 gebruiken fysiek korter bij elkaar te laten draaien op een plek op de chip kort bij die portie van het L3 dat gebruikt wordt voor die thread. Ook kan er behoorlijk gewonnen worden door de splitsing van de L2 dynamisch te maken op basis van de code die gedraaid gaat worden, als er een lus is van enkele operaties op een redelijke hoeveelheid data dan hoef ik geen bewijs om te geloven dat een andere L2 indeling flinke winst gaat geven, je kunt zomaar 90% extra L2 verwachten voor een thread voor de duratie van die lus. Na de lus zal de cache waarschijnlijk toch ververst moeten worden dan kan de indeling ook direct aangepast worden op basis van een profiel voor de nieuwe uit te voeren code, een profiel dat op vergelijkbare manier gemaakt kan worden zoals nu ook voor andere delen zoals de prefetcher of cache gedaan wordt.

Software optimalisatie is mooi, maar als je compleet geoptimaliseerde applicatie moet draaien op een dik belaste server gaat het je weinig helpen, dit kan behoorlijk verschil maken. Stel dat voor de threads die continue aan het rekenen zijn op een bult data een hoekje op de cpu wordt toegewezen en meer zodra dat beschikbaar is, dat moet geen groot probleem zijn om te implementeren in een toekomstige generatie maar dan moet een simulatie dat wel eerst uitwijzen, gewoon proberen ga je niet snel zoveel van leren als een goedkoop te tweaken simulatie
vooruitgang, altijd leuk om te zien :)
Is AMD toch ook mee bezig. (En de titel komt best wel clickbaity over...)
De titel komt ongeveer net zo clickbaity over als jouw naam... :?
Wat een leuk artikel om te lezen. Ik vroeg me laatst al af wat die caches nou precies waren en deden. Dank voor de uitleg! :)
Voor de mensen die denken dat 1600mhz of 2666mhz geheugen snel zat, is ur wrong...
Die bottleneck mag er wel uit. Merk een groot verschil tussen 2200, 2666mhz vs 3000 en 3000 vs 3866mhz in Battlefield met 64 spelers.. en dan doelend op de absolute minimum FPS bij een hoop actie en explosies. Zowel GPU als CPU bij lange na niet op de max.
Geheugen vormt zeker wel een bottleneck, alleen met idioot duur geheugen los je het wat op, maar ik denk dat je zelfs nog baat zou hebben bij bijv 10Ghz DDR5

[Reactie gewijzigd door A87 op 15 juli 2017 19:33]

Op dit item kan niet meer gereageerd worden.


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*