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

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
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... ;)
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
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.


Call of Duty: Black Ops 4 HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S9 Dual Sim Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V. © 1998 - 2018 Hosting door True