Intel wil sram in cpu door dram vervangen

Intel zou met een project bezig zijn om het statische geheugen in processors te vervangen door dynamisch geheugen. Dram is compacter en goedkoper en de bandbreedte zou verveelvoudigen.

Een onderzoeksgroep van Intel toonde tijdens de Research@Intel Day een volgens hen veelbelovende ontwikkeling: in cpu's zou sram door dram vervangen kunnen worden. De caches in processors bestaan traditioneel uit statisch ram, met als voornaamste beweegredenen de hogere snelheden en lagere energiebehoefte ten opzichte van dynamisch ram. Sram is echter ook duurder dan dram en heeft relatief veel transistors, en dus ruimte, voor een enkel bit nodig. De onderzoekers van Intel zijn er nu echter in geslaagd om dram te construeren dat uit slechts twee transistors bestaat en geen condensators nodig heeft.

Het Intel-team zegt in staat te zijn om het compacte dram op snelheden tot 2GHz te klokken wanneer een 65nm-productieproces gebruikt wordt. Het 2T-dram, zoals het compacte geheugen gedoopt is, zou daarmee snelheden van 128GBps tussen de cores van de processor mogelijk maken. Ter vergelijking: de Harpertown-core van nieuwe Xeons beschikken over een bandbreedte van 18 tot 20GBps. Wanneer de snelheid van het dram verder omhoog geschroefd wordt om in de pas te lopen met Intels snelste quadcores, die op 3,2GHz tikken, zou de bandbreedte zelfs tot ruim 200GBps kunnen stijgen, tien keer zo snel als in de Xeons. Dat zou volgens Intel mogelijk zijn als het 2T-dram op 45nm wordt geproduceerd. De techniek zal mogelijk voor het eerst in de opvolger van de Larrabee-core gebruikt worden.

Reacties (63)

[hatex]

NIet echt vernieuwend qua idee, AMD was in 2005 er ook al mee bezig :

It was AMD which licensed the capacitor-less DRAM memory, known as ZRAM, in 2005. AMD wanted to use ZRAM to add memory to microprocessors with less usage of silicon than that taken by a conventional DRAM based on a transistor + capacitor cell structure.

Then Renesas announced, also in 2005, that it had developed a similar, capacitor-less DRAM structure. Renesas wanted the technology, which it calls TTRAM (twin transistor RAM), to add memory to its SOCs which would take up the minimum possible amount of silicon area.

TT-Ram wiki : http://en.wikipedia.org/wiki/Twin_Transistor_RAM

[Maarten21]

In hoeverre is die bandbreedte een bottleneck in een cpu?

[hugoy]

Dat ligt maar net aan de applicatie en het aantal cores, als je bijvoorbeeld >100 cores hebt (en dat zie ik binnen 3 jaar wel gebeuren) en je een applicatie hebt wat ook daadwerkelijk zoveel threads heeft, dan is elke verhoging in bandbreedte een groot voordeel. En dit zou er ooit misschien voor kunnen zorgen dat RAM overbodig wordt omdat er zoveel en zo'n snelle cache al in de CPU ingebakken zit.

[TD-er]

En dit zou er ooit misschien voor kunnen zorgen dat RAM overbodig wordt omdat er zoveel en zo'n snelle cache al in de CPU ingebakken zit.

Zo veel is het nou ook weer niet.
Sram heeft per bitje 6 transistoren nodig en deze techniek 2 transistoren. Oftewel op hetzelfde oppervlak kun je dan max zo'n 3x zoveel aan opslag kwijt. Op dit moment is in de praktijk 12 MB cache op een enkele processor-behuizing wel zo'n beetje het maximum, dus dan zou je op zo'n 36 MB uit kunnen komen.

Wat wel handig is, is dat je zonder condensator geen refresh meer nodig hebt, dus zou je wel een snelle level-3 cache nog kunnen maken van significante grootte. (Hadden we vroeger ook, denk aan de COAST-modules op de Pentium-bordjes en de losse chips op de 486-ers)
Of mischien wel sneller DRAM-geheugen, mits 2T geheugen kleiner is dan 1 transistor en een condensator.

[elteck]

Ho ho.... het feit dat je geen extra condensator nodig hebt, wil nog niet zeggen dat je geen refresh nodig hebt. Ze noemen het niet voor niets DRAM (D = dynamisch), d.w.z. de bits worden nog steeds d.m.v. lading onthouden, en die heeft zeer zeker een refresh nodig.

Hoogst waarschijnlijk (mijn inschatting) hebben ze de lekstromen zo laag gekregen (met hun hoge K gates) dat de gate-capaciteit van de transistor zelf voldoende is om als opslag medium te dienen.

[Reactie gewijzigd door elteck op 25 juli 2024 11:48]

[apa]

Wat wel handig is, is dat je zonder condensator geen refresh meer nodig hebt

Bij mijn weten gebruikt Intel in plaats van een condensator een eigenschap van het SOI-productieproces dat de lading tijdelijk bijhoudt wat voor het "geheugeneffect" zorgt. Aangezien dat effect slechts tijdelijk is moet het geheugen nog steeds ge-refreshed worden (wat dus niet het geval is met SRAM).

@elteck: Ik heb me suf gezocht naar waar ik dat gelezen had, maar het bleek in een eerder artikel op T.Net te zijn: http://tweakers.net/nieuw...en-procestechnologie.html:

Het weglaten van de condensator is mogelijk doordat transistors die middels een soi-procedé gebakken zijn, ook lading kunnen opslaan.

edit:
Bronvermelding...

[Reactie gewijzigd door apa op 25 juli 2024 11:48]

[elteck]

Gebruikt Intel SOI? AMD/IBM doen dat inderdaad, maar Intel beweerde toch zonder te kunnen?

Het SOI zelf lijkt me onwaarschijnlijk als geheugen. Die vorm van geheugenwerking is traag (te veel weerstand), en je hebt trench scheiding nodig, wat weer veel ruimte kost.
SOI wordt gebruikt om lokaal de bulk spanning en daarmee de drempelspanning te moduleren, waarmee je snelheid en lekstroom van de transistoren aanpast. Voor DRAM is dat laatste zeker belangrijk, hoe lager de lek des te lager de refresh rate.

[Toontje_78]

Niet noodzakelijk SOI, maar een variatie hierop zou toch best wel eens kunnen?

Uitsparen van een condensator geeft ook weer ruimtewinst tenslotte.

[Snoitkever]

Op dit moment is in de praktijk 12 MB cache op een enkele processor-behuizing wel zo'n beetje het maximum, dus dan zou je op zo'n 36 MB uit kunnen komen.

Maar dit gaat niet over huidige processoren. Intel heeft hier een mooie oplossing voor het probleem waar ze over een aantal jaar tegenaan lopen, namelijk "wat doen we met al die transistoren?". Elke anderhalf jaar verdubbelt de hoeveelheid transistoren die een CPU ter beschikking heeft, en op een gegeven moment hebben consumenten helemaal niets meer aan de zoveelste verdubbeling van het aantal cores. 4 cores, prima, 8 cores, tja, maar 16 of 32 of zelfs 64 cores? Dan kun je beter een hele lading RAM op je chip bakken zodat je threads veel sneller kunnen functioneren.

[Sissors]

Euhm, hoe kom je hier bij? En waarom is het omhoog gemod. Ze hebben echt geen ruimte teveel bij intel op hun wafers.

Als er eenmaal geproduceerd wordt is de kosten per processor proportioneel tot de hoeveelheid ruimte die een processor inneemt. Intel is hardstikke blij als ze transistoren over hebben, dan maken ze gewoon processor kleiner, kunnen er meer processoren per wafer, en verdienen ze meer.

[Snoitkever]

Als er eenmaal geproduceerd wordt is de kosten per processor proportioneel tot de hoeveelheid ruimte die een processor inneemt. Intel is hardstikke blij als ze transistoren over hebben, dan maken ze gewoon processor kleiner, kunnen er meer processoren per wafer, en verdienen ze meer.

En over tien jaar? Dan kun je 64 Nehalems op een chip bakken met dezelfde afmetingen als een Nehalem chip nu, aangenomen dat Moore's Law het zo lang volhoudt. En Nehalems hebben al een geintegreerde geheugencontroller en GPU, dus wat moet je dan? Uiteraard kun je het aantal cores uitbreiden, maar op een gegeven moment heeft de doorsnee gebruiker echt niet genoeg threads draaiend om elke core aan het werk te houden. Daarnaast kun je de GPU capaciteit van de chip uitbreiden, maar dat is ook alleen nuttig voor een klein deel van de markt. Vervolgens kun je misschien nog de southbridge gaan integreren in de chip, maar na 20 USB poorten, 64 PCI-E versie X lanen en 10 SATA controllers is daar de creativiteit ook wel een beetje op. Clocksnelheid per core kan ook niet altijd omhoog gedreven worden, dus als je niets doet blijft performance op een gegeven moment steken.

Uiteraard kun je de chips veel kleiner gaan maken, maar dan heb je uiteindelijk twee problemen. Het eerste is dat je, zolang je nog competitie in de markt hebt, prijzen altijd omlaag moet halen in verhouding tot productiekosten. Intel heeft echter geen zin om chips te gaan verkopen die maar een paar euro kosten.
Het tweede probleem is dat, wanneer er geen vooruitgang meer zou zitten in je processoren, mensen niet zomaar meer upgraden. Nu kopen mensen een nieuwe pc als de oude verouderd is en niet alle nieuwe programmas meer draait, maar als upgraden toch geen zin meer heeft kopen mensen pas een nieuwe pc als de oude kapot is. Bovendien kunnen oude processoren dan nog weer gerecycled worden in een nieuwe pc, dus zolang de chip zelf niet kapot gaat blijft deze in de handel. Lijkt me dat de winst bij Intel in beide gevallen snel naar beneden schiet.

EDIT: En misschien is 10 jaar nog niet eens een goed voorbeeld. Laten we 20 jaar nemen, dan zitten we niet op 64 Nehalems, maar 8192 Nehalems. Iemand een 32768-core, 65536 thread chip?

[Reactie gewijzigd door Snoitkever op 25 juli 2024 11:48]

[Toontje_78]

Iemand een 32768-core, 65536 thread chip?

Als tegen die tijd het uiteenrafelen van treads door processor en/of compiler een beetje wil lopen, waarom niet. (Hoe heet het project waarbij een aantal cores zich als een enkele virtuele core voordoet ook weer.. )

[Verwijderd]

Als het geheugen net zo snel is als de CPU, waarom dan uberhaupt moeilijk doen met cachegeheugen? Zorg voor een snelle verbinding tussen CPU en RAM en laat cachegeheugen helemaal weg.

[warrg]

dan zie ik het nog eerder andersom...
dat ze de huidige RAM modules vervangen door cache geheugens (wat een heel pak sneller is, maar ook duurder)

[Toontje_78]

boh.. zoveel jaar geleden was het hele systeem, OS + programma, kleiner dan de cache alleen al. 15 jaar geleden was de norm RAM voor een standaard systeem 4 MB.

Ik vraag me af of het mogelijk zou zijn een RAM-loos systeem te maken en zo een antiek systeem de cache als RAM aan te laten spreken.

[GeniusDex]

RAM zal niet snel overbodig worden. Kijk maar eens hoe groot de chips op een geheugenbankje bij elkaar zijn en hoe groot je processor is. Zonder een gigantische vergroting kom je nooit aan gigabytes geheugen in je CPU.

[knirfie244]

De grote van de package zegt helemaal niets. Het gaat om het silicium wat er in ligt...

[Reactie gewijzigd door knirfie244 op 25 juli 2024 11:48]

[Nokian95dude]

Denk ik ook niet. Bovendien is het nog de vraag of die bandbreedte ook optimaal gebruikt word voor waar je geheugen voor wil.

Die verandering is niet zo'n concurrent voor je RAM aangezien die een ander doel heeft. Ook is het niet nodig want t zal nooit zo snel kunnen zijn als ram aangezien die daarvoor gemaakt is en de cpu andere functies/doelstellingen heeft.

Dat je snelheid erdoor omhoog gaat is natuurlijk heel erg mooi en dat t tegelijkertijd goedkoper is ook.

[apa]

En dit zou er ooit misschien voor kunnen zorgen dat RAM overbodig wordt omdat er zoveel en zo'n snelle cache al in de CPU ingebakken zit.

RAM wordt steeds doorlopend ge-adresseerd en wordt als 1 grote blok gezien dat gedeeld wordt door alle onderdelen die er data/instructies in stoppen (of uit lezen). Cache is een sneller stuk geheugen waarin een kopie van een stukje RAM geplaatst kan worden zodat het sneller toegankelijk wordt. Uiteindelijk moet iedere verandering in de data terug naar het RAM opdat het gebruikt zou kunnen worden door andere verwerkingseenheden.

Eigenlijk zou het wel kunnen wanneer je de lijn doortrekt bij NUMA-systemen (zoals bij AMD sinds de K8 of zoals bij Intel vanaf Nehalem): iedere CPU heeft daar zijn eigen toegang tot een lokaal stuk geheugen en kan ook het geheugen van andere CPU's aanspreken (zij het met wat vertraging). Als de cache nu eveneens aangesproken zou kunnen worden door de cross-bar controller (= een soort virtuele memory controller die beslist of een memory-request door de lokale memory controller dan wel door deze van een andere CPU moet worden afgehandeld), dan zou je kunnen denken aan cache dat gedeeld zou kunnen worden door alle CPU's tegen een veel lagere latency dan het normale RAM... Of zit ik hier helemaal verkeerd?!

[Cristan]

Misschien dat RAM wel binnenkort op deze manier gemaakt gaat worden. Ik zie het wel zitten in ieder geval

[AlexanderB]

ram word nu al zo gemaakt, de grap is juist dat het ram zoals we dat gebruiken nog niet gebruikt word intern de processor

[apa]

ram word nu al zo gemaakt

In het normale RAM (in de DIMM-slots dus) worden condensators gebruikt om de lading een tijd lang bij te houden; hier niet... Dat is dan ook de grootste vooruitgang IMHO.

"RAM" (in de DIMM-slots) wordt dus zeker (nog) niet zo gemaakt: daarvoor zouden ze trouwens een SOI proces moeten gebruiken en ik denk niet dat dat al het geval is.

[Verwijderd]

>100 cores in 3 jaar? haha laat me niet lachen

Kijk eens in de roadmaps van intel, ik geloof dat ze er nog niet zo lang geleden een hebben vrijgegeven Dan zit je over 3 jaar eerder aan de 16 cores

[emilionl]

kan dat 100 cores op een processor met huidige afmetingen proppen?

[Punkie]

In een processor zit veel geheugen. Niet enkel in de caches maar ook tussen de pipeline stages, in de fbu's enz. Als je een instructie decode gaat dat in 2-5 verschillende klokcycli. Tussen elke 2 cycli wordt het resultaat gebufferd en op het einde wordt het in een cache gestopt. Flink wat geheugen aanwezig dus. Afhankelijk van de architectuur kan dit over 20-50% gaan.

Als 1 van de geheugens zonder data zit dan moet de unit "stallen" omwille van "datastarvation". Dit is hooglijk ongewenst. Daarom moet er voldoende bandbreedte zijn. Bandbreedte hier als de hoeveelheid data die men per tijdeenheid kan beschikbaar stellen. De bandbreedte wordt voornamelijk gerealiseerd door caching. veel bandbreedte <=> veel geheugen
Maar laat nou net die caches (connecties + geheugens) een groot stuk van het kostenplaatje uitmaken. veel geheugen <=> duur

Daarom beperkt men de bandbreedte waar men kan zonder te veel stalls te introduceren. De door intel gepresenteerde geheugens zijn klein en toch snel. Waardoor de bandbreedte kan gerealiseerd worden door minder geheugen. Daardoor kan men de vergelijkingen wat veranderen.
minder geheugen <=> goedkoper
genoeg bandbreedte => snel

[Rob Coops]

Een bottleneck is het niet echt maar het gewoone geheugen is dat wel, het is zeer traag in vergelijking tot de CPU en dus als je de cache in de CPU kleiner kunt maken en er dus meer van in de CPU kan schuiven dan kun je dus ook veel sneller bij je data waardoor de CPU weer sneller kan werken.

Natuurlijk neemt dat neit weg dat de harddisk nog heel veel trager is en dus all vele jaren een veen grotere bottleneck vormt dan het geheugen maar alle beetjes helpen dus ook dit.

Vier jaar terug zat er ongeveer 1Mb an L2 Cache in een CPU nu zit er vaak al snel 4Mb in als Intel hier mee de hoeveelheid kan verhogen naar 8 of zelfs 16Mb dan kon dat wel eens een heel groot verschil gaan maken voor de snelheid van de CPU zeker als de bandbreedte ook nog eens een factor tien omhoog gaat.
Ik hoop wel dat IBM/AMD snel een vergelijkbare techniek zullen hebben anders lopen ze te veel achterstand op, maar ik heb wel vertrouwen in hun onderzoekers die zullen vast ook een soort gelijk iets vinden of al hebben gevonden.

[NetXtreme]

De Cell processor van IBM heeft al een grotere bandbreedte voor communicatie tussen verschillende cores. De EIB (Element Interconnect Bus) op de Cell processor van 96 bytes per cycle verwerken. Dit geeft een theorietische bandbreedte van meer dan 300 GByte per seconde. In de praktijk hebben programmeurs van IBM aangetoond dat een snelheid van ongeveer 200 GBytes per seconde haalbaar is.

Communicatie tussen verschillende cores wordt steeds belangrijker, zeker wanneer intel en amd met hun hybride processoren komen.

[roy-t]

geheugen is de grooteste bottleneck voor een cpu, de snelheid van geheugen is in verhouding tot de snelheid van de CPU afgenomen. Daarom komen er steeds meer tussen caches (L1, L2, L3, L4) en worden die steeds groter.

Als de L1 cache groter en sneller kan zal dit voor sommige applicaties erg veel voordeel opleveren en het zal zeker een paar procent schelen voor alle applicaties.
(deze wijsheden vekregen uit het boek computer architecture van Tannenbaum)

[EotT]

De caches in processors bestaan traditioneel uit statisch ram, met als voornaamste beweegredenen de hogere snelheden en lagere energiebehoefte ten opzichte van dynamisch ram.

Als deze meer energie gaan nodig hebben, wordt de CPU dan weer ni veel warmer? Hopelijk vormt dit geen probleem, want is wel een mooie ontwikkeling.

Voor de consument : sneller en goedkoper
voor intel ook goedkoper (2x zelfs): ten eerste is geheugen goedkoper. Ten 2de is kleiner, dus kunnen ze nog meer produceren voor dezelfde prijs.

Ik ben ik elk geval benieuwd. Nu nog wachten op enkele benchmarks (zal nog wel eventjes duren...)

[Reactie gewijzigd door EotT op 25 juli 2024 11:48]

[maxjuh]

Het stukje wat je quote gaat over de vergelijking van sram en traditioneel dram. Het dram wat hun nu gaan gebruiken zit weer anders in elkaar dus zal de energiebehoefte bij dit dram ook wel weer anders zijn.

[apa]

Ik vermoed nochthans dat dat nieuw type DRAM ook meer zal verbruiken dan SRAM: het moet namelijk ververst worden (anders was het geen "DRAM" he )...

[maxjuh]

Maar dit neemt niet weg dat de energie consumptie veel minder zou kunnen wezen en daardoor het voordeel van de energie consumptie tegenover SRAM minder is.

[orange.x]

Maar even verderop in het artikel staat ook:

De onderzoekers van Intel zijn er nu echter in geslaagd om dram te construeren dat uit slechts twee transistors bestaat en geen condensators nodig heeft.

Hieruit zou je kunnen concluderen dat ze dat puntje energiebehoefte binnen de perken kunnen houden of misschien zelfs verlagen. Volgens mij zijn 2 transistors niet echt veel, voor 1 bit neem ik aan dat dat is. Weet zo 123 niet wat een normale dram bit aan transistors vraagt.

Tevens staat in het gelinkte artikel dat SRAM gemiddeld 6 transistors per bit nodig heeft. Dus het lijkt me qua energiebehoefte niet nadelig om die nieuwe DRAM te gebruiken.

@TD-er:
Maar in het artikel staat dus dat ze nu met 2 transistoren werken en _zonder_ condenstator.

[Reactie gewijzigd door orange.x op 25 juli 2024 11:48]

[TD-er]

Weet zo 123 niet wat een normale dram bit aan transistors vraagt.

DRAM is 1 transistor en 1 condensator per bitje.
Nadeel van DRAM tov SRAM is dat je DRAM moet refreshen en dat het op- of ontladen van die condensator meer tijd vraagt dan bij een SRAM alle transistoren (6 per bitje) in de juiste stand zetten.

[miw]

Deze 2T cell heeft de eigenschap dat het een dynamisch geheugen is; de spanning valt dus langzaam weg en vernielt daarmee de waarde van het geheugen. Het spannings verlies is equivalent aan een energieverlies. Een klassieke SRAM cell heeft niet een dergelijk spanningsverlies en de bijbehorende hogere energieverbruik.
Een traditionele DRAM cell heeft een 1T configuratie: boven elke transistor ligt een condensator waar de informatie op ligt geslagen. Een SRAM cell heeft meestal een 4T configuratie.
Het probleem met de 1T configuratie is dat het een ander produktieprocess vereist om die condensatoren aan te brengen. De gerapporteerde 2T cell lijkt dit probleem niet te hebben, maar deelt wel andere aspecten met een 1T DRAM cell (informatieverlies, hoger energieverbruik).

[Ge Someone]

Ten 2de is kleiner, dus kunnen ze nog meer produceren voor dezelfde prijs.

Dus grotere en snellere caches wat hun processoren de data sneller laat verwerken en architecturen met >8 cores zinvoller maakt.

[Sinlath]

Dit is al zo vaak aangegeven, er zijn zat Enterprise zaken die nu al op dual quadcores draaien.

ik heb hier in het datacenter een ESX farm draaien en een terminal server farm, oracle RAC clusters.. doe mij maar meer cores op minder sockets (scheelt ook in licentiekosten, die gaan per CPU socket, dus physical cpu en niet virtual cpu (core))

meer cores is niet boeiend voor de thuisgebruiker (een DPC-er daargelaten ) maar zakelijk zie ik hier alleen maar voordeel in, als dit de technologie is om 8 cores of meer op een socket te duwen.. gaan met die handel.

[Countess]

als de volgende geheugen standaard nou een zo gemaakt word. dan zou eindelijk de interne snelheid van de geheugen cellen eens omhoog kunnen. die staat al sinds ddr-1 op maximaal 200mhz (officieel).

[TD-er]

Die 200MHz is de frequentie van de gebruikte klok. Je wilt namelijk dat alle dingen in de pas lopen en dus heb je eens in de zoveel tijd een synchronisatie nodig, zodat je zeker weet dat alle parallelle bitjes die je binnenkrijgt ook bij elkaar horen.
Echter worden de bitjes tegenwoordig al veel sneller achter elkaar over de datalijn gestuurd dan de klok.
Bij DDR wordt er tussen elke klokpuls ook nog een bitje verstuurd en bij QDR wordt tussen elke halve klokpuls een bitje gestuurd.
Feit blijft echter dat je de boel nog steeds moet synchroniseren. Ik verwacht in de toekomst dat we van die synchronisatie af zullen stappen en dat je het meer moet gaan zien als een hoop opslag-gebieden naast elkaar, elk met een eigen seriele communicatie.
Dat hebben ze nu ook met PCIexpress gedaan en ik verwacht dat dat binnen een aantal jaren ook zo zal gaan met het geheugen.

[apa]

Ik verwacht in de toekomst dat we van die synchronisatie af zullen stappen en dat je het meer moet gaan zien als een hoop opslag-gebieden naast elkaar, elk met een eigen seriele communicatie.

Als ik mij niet vergis, is het toch dat wat FB-DIMM's doen? Een aparte chip die voor communicatie zorgt tussen parallelle DRAM-chips en dan serieel naar de memory-controller?!

Bij FB-DIMM's heb je echter nog steeds synchronisatie aangezien het synchroon geheugen is. Asynchroon geheugen heeft ook bestaan (remember "EDO-DRAM"), maar dat bleek ook niet zo heel evident. Ik denk dat asynchroon geheugen pas echt zou kunnen wanneer er gebruik gemaakt wordt van SRAM (aangezien dat niet ververst hoeft te worden).

[Reactie gewijzigd door apa op 25 juli 2024 11:48]

[Verwijderd]

Meer en snellere cache: Altijd goed!

[Sphere-]

Meer is niet altijd beter. Hoe meer cache je hebt, hoe langer het duurt voordat je vind wat je zoekt!

[SirNobax]

Het is geen hardeschijf die in je CPU gebakken zit.

Je beweerd zeker ook dat 1GB aan werkgeheugen sneller is dan 4GB, omdat hij dan niet zo hoeft te zoeken.
Ja, natuurlijk.

[kiang]

Ken jij iets van computerarchitectuur? blijkbaar niet, want dan zou je weten dat caches wel degelijk trager worden als de grootte toeneemt.
Zoals hierboven gezegd hangt het nog af van de associatieviteit, wat het doorzoeken van de cache aanzienlijk verbeterd, maar niet voor alle caches (L1,2 en3 zijn verschillend)

Anders leg ik even uit hoe cache werkt:
in de cache worden kopieën van waarden uit het geheugen opgeslagen. Wanneer de CPU dus bv een waarde uit adres 0x4560 uit het geheugen moet halen, zal de CPU eerst in de cache kijken of die waarde daar al niet in gekopieerd staat. HEt opzoeken gebeurt met de hulp van tags, waaraan de CPU kan zien van welk RAMadres het cacheblok een kopieis.
De hiervoor aangehaalde associativiteit is een methode om dit doorzoeken sneller te laten gaan: fully associative wil zeggen dat elk RAM-adres eender waar in de cache mag gekopieerd worden. Als voordeel heeft dit dat men pas waarden moet verwijderen uit de cache als die volledig vol zit, als nadeel dat men om een waarde te vinden heel de cache moet overlopen.
Een betere manier is echter om de cache-locatie van een geheugenadres te laten afhangen van het geheugenadres zelf. Op die manier weet de CPU op welke plaats de informatie zit, ALS die al in de cache geladen is.
Het voordeel hiervan is natuurlijk dat het zoeken een stuk sneller is(er moet maar op 1 vaste plaats gekeken worden), maar dat men informatie wel redelijk snel weer moet verwijderen, omdat er natuurlijk voor elk cache-blok enkele miljoenen RAM-blokken zijn.
Een soort tussenweg is n-wegs associativiteit: Hierbij mag informatie uit een bepaald RAMblok op n plaatsen in de cache zitten. Doorgaans wordt 8-wegs associativiteit gebruikt. Dit wil dus zeggen dat wanneer men een RAM-adres heeft, dit op slechts 8 plaatsen in de cache kan zitten.
Het voordeel is weeral dat de zoektijden aanzienlijk lager zijn, en dat terwijl informatie toch niet zo snel weer verwijderd wordt: elk RAM-blok heeft namelijk 8 mogelijke bestemmingen, en de kans dat daar eentje van vrij is is redelijk groot.

Tegenwoordig wordt voor de L1 meestal volledige associativiteit gebruikt en voor L2-3 8 wegs-associativiteit.
Als we de L1 groter maken wordt die dus wel degelijk trager

[Reactie gewijzigd door kiang op 25 juli 2024 11:48]

[apa]

Je beweerd zeker ook dat 1GB aan werkgeheugen sneller is dan 4GB, omdat hij dan niet zo hoeft te zoeken.

En toch klopt het enigszins. RAM wordt namelijk niet doorzocht: het wordt steeds benaderd met vaste adressen (of ranges) waardoor er niet door gezocht moet worden. Het lezen van adres 1 in het RAM kost even veel tijd als het lezen van adres 1000...
In cache moet wel gezocht worden omdat het een gedeeltelijke kopie betreft van het RAM en wat erin gekopieerd staat niet vaststaat: er moet dus steeds gezocht worden of een bepaald RAM-adres in de cache opgeslagen staat of niet...

Net als bij databases bestaan er verschillende manieren om te zoeken in cache en de cache moet dus zeker niet zomaar volledig doorwandeld worden voor iedere request. Maar bij eenzelfde "lookup-strategie" zal het in de regel wel langer duren om in de cache te zoeken naarmate die groter wordt.

[kluyze]

Het ram geheugen is een uitbreiding van het cache geheugen, wat de cpu niet kan bereiken in zijn cache gaat hij zoeken in het ram, wat een factor 30 trager kan zijn. Dus als je 2GB aan cache zou hebben is er wel meer tijd nodig om het volledige cache te doorzoeken maar met wat simpele trukjes kwa indeling en addressering kan je cpu dus aan 2GB aan (ram-)geheugen dat even snel is als het cache.

Meer cache is dus zeker wel beter.

[.oisyn]

Je hebt een beetje een rare kijk op de zaak. Het geheugen is geen uitbreiding op de cache. De cache is juist een kopie van het geheugen dat zich veel dichter bij de processor bevindt en sneller is (en daardoor ook een stuk duurder, wat de reden is dat er niet gewoon 4GB cache in een CPU zit oid). Een applicatie ziet de cache ook niet als een apart stuk geheugen. Het enige wat die doet is instructies gebruiken die direct op het geheugen werken, en de CPU versnelt dat door een kopie van het geheugen dat nodig was in de cache te zetten zodat hij ze daarin snel op kan zoeken als de data nog eens nodig is, ipv elke keer weer op het langzame geheugen te wachten.

De meeste L2 en L3 caches op de populairdere CPUs zijn trouwens n-way set associative, wat effectief betekent dat de cache adressen 1:1 overeenkomen met geheugenadressen door te kijken naar een subset van de bits van het geheugenadres. Oftewel, je kan in O(1) de cache van een bepaald geheugenadres opzoeken, ongeacht de grootte van de cache. Een 2GB cache zal dan dus niet langzamer zijn dan een 2MB cache. Een L1 cache heeft daarentegen doorgaans een volledige associativiteit, maar is tevens ook niet heel erg groot (zeg zo'n 32kB). En aangezien het geheugen doorgaans de bottleneck is, is het handiger om de L2 cache flink uit te breiden.

[Reactie gewijzigd door .oisyn op 25 juli 2024 11:48]

[apa]

Het ram geheugen is een uitbreiding van het cache geheugen

Vanuit het oogpunt van de CPU kan je dit misschien zo zien, maar eigenlijk klopt dat niet... Cache is in het leven geroepen om de traagheid van RAM te maskeren voor de CPU. Het is dus eerder andersom.

[Reactie gewijzigd door apa op 25 juli 2024 11:48]

[EotT]

Als het fully associative cache is (dus elke waarde kan op om het even welke plaats komen)
Indien niet, zal het geen verschil maken

[latka]

Hangt van de lookup af, maar bij gelijkblijvende lookup strategie: ja.

[Verwijderd]

vergeet goedkoper niet

[Verwijderd]

Misschien is efficientie toch een soort van "toverwoord"...

[beascob]

Was er pas niet een item over "gevoelige informatie nog tot minutenlang in het RAM-geheugen van een computer"?
En dat dit vooral door de condensators kwam?
Met deze ontwikkeling, stroom eraf, RAM leeg

[Verwijderd]

Ik vind dit goed klinken , meer cache meer bandbreedte en dus snelheid, en uiteindelijk ook goedkoper. Zal wel nog een tijdje duren mag ik aannemen, maar toch een mooie vooruitgang.

[Verwijderd]

Even een beetje gegoogled:

Er blijken al patenten te zijn voor twee-transistor en condensator loze dram cellen:
http://www.google.com/patents?id=mJ4bAAAAEBAJ&dq=5122986
http://www.google.com/patents?vid=USPAT5448513

[Verwijderd]

Als zelfs AMD er al mee bezig is (geweest?) ben ik benieuwd hoe lang het gaat duren voordat deze techniek gaat aanslaan.
Ziet er veelbelovend uit voor de toekomst!