'AMD gaat L2-cache van Z-ram maken'

Bij EETimes valt te lezen dat AMD een licentie heeft verworven voor het gebruik van Z-ram, ook wel bekend als 'zero capacitor'-geheugen. Z-ram zou dankzij SOI-technologie een veel grotere dichtheid van componenten kunnen hebben, en daarmee is het heel geschikt om een veel grotere cache aan een processor te knopen dan wat momenteel haalbaar en betaalbaar is. Craig Sander, AMD-directeur met technologie in zijn portefeuille, wist te melden dat de chipfabrikant druk bezig is om te evalueren of de nieuwe techniek geschikt gemaakt kan worden voor de producten van het bedrijf, door tests uit te voeren met 90nm- en 65nm-transistors. Een concrete tijdlijn voor de productie van processors met Z-ram-caches kon hij nog niet geven, maar als de experimenten succesvol zijn zal de techniek zo snel mogelijk worden ingezet.

Hoewel de AMD-voorman nog de nodige slagen om de arm houdt als het om schaalbaarheid gaat, hoopt AMDzone dat de naar schatting vijfmaal grotere dichtheid van Z-ram ook vijfmaal grotere cachegeheugens betekent. Omdat een periode van twee jaar voor de overgang van plan naar productie gangbaar zou zijn, verwacht deze site dat we mogelijk eind volgend jaar al de eerste dualcore AMD's met in totaal 10MB aan L2-cache in de winkel zouden kunnen aantreffen, maar dat is wellicht wishful thinking. Dat deze techniek AMD mogelijk een voorsprong kan geven op de concurrentie is in ieder geval duidelijk. Z-ram is weliswaar ook voor andere producten van de chipfabrikant bruikbaar, maar dat zou vooralsnog te veel aanpassingen aan de productiefaciliteiten vergen. Wel werkt AMD op diverse terreinen nauw samen met IBM, maar of en hoe dat bedrijf met Z-ram aan de slag kan, is nog in nevelen gehuld.

Reacties (67)

[Verwijderd]

ik begrijp dat Z-RAM een speciale variant is van DRAM. normaalgesproken bestaat cache geheugen op een processor uit SRAM. SRAM (typ. 15 ns accesstijd) is zon 4x sneller als DRAM (typ. 60ns accesstijd).

nu kan het natuurlijk zijn dat het uit oogpunt van systeemperformance voordeliger is een heel grote pool van (embedded) DRAM te nemen ipv een veel kleinere pool van sneller SRAM. zeker met een toename van het aantal cores is het begrijpelijk de hoeveelheid cache geheugen te verhogen ipv de snelheid van dat cache geheugen (vergelijk verhogen van aantal cores in een processor ipv verhogen van de clockrate van die processor).

maar ik wil maar even opmerken dat Z-RAM welliswaar een veel hogere density heeft dan SRAM maar helaas ook een stuk trager is.

[edit@mbuys]
ik had inmiddels ook dat getal 3ns gezien, maar als dat zo is dan zou de fabrikant van zram toch van de daken schreeuwen dat het 5x sneller is dan SRAM en ook nog eens veel compacter en minder energie verbruikt? begrijp de eenzijdige focus op density niet zo...
[/edit]

[edit2@mbuys]
graphics kaarten gebruiken gewoon DRAM in de vorm van gemultiplexte bankjes met een snelle bus ala DDR (GDDR3 bijvoorbeeld). voor de rest is het afwachten wat de latency van ZRAM is. wat ik tot dusverre begrijp is dat ZRAM capaciteit-loos DRAM is hoe gek dat ook mag klinken...
[/edit]

[jbvo]

Na ongeveer een minuutje zoeken:

ZRAM technology does not require designers to compromise on speed or power: read and write operations in under 3ns have already been demonstrated on silicon

Bron: http://www.cieonline.co.u...iclen.asp?pid=518&id=5434

Maar als je dus wel gelijk hebt wat betreft de verhouding van de snelheid van ZRAM en SRAM, dan lijkt het me niet slim om die als vervanger van SRAM als cache te gaan gebruiken.

Edit: Denk ook aan de videokaarten die steeds vaker 2 of 3ns geheugen gebruiken (en waar het dan ook groot op de doos staat enzo), dus zo speciaal is die 3ns dan ook weer niet; het is eerder net zo snel als gewoon geheugen, maar dan met een grotere dichtheid. (ongeveer 2 keer volgens datzelfde artikel)

Edit2: Volgens wiki draait de L1 en L2 cache van de K8 op dezelfde snelheid als de core en bij een 2.6Ghz processor zou dat betekenen dat de accesstimes van het gebruikte geheugen ten hoogste ongeveer 0.4ns mogen zijn (tenzij er niet elke klokslag iets uit het cache hoeft kunnen te worden gehaald, dat weet ik niet precies)

[Roland78]

Ze kunnen ook de cachegrootte gelijk laten en dan de prijs met 25% verlagen. Meer chips uit een wafer, meer productie. Door de lagere prijs ook meer afzet en dus een hoger marktaandeel en bij een goede positie op de prijselasticiteitscurve nog meer omzet en winst ook!

[Krankenstein]

Ik denk niet dat een prijsverlaging zoveel extra verkopen zal opleveren. Daar hebben ze immers de budgetlijn al voor.

Wat zou de optimale cachegrootte zijn voor de huidige high-end desktopprocessors? Want op een gegeven moment gaat de toegang tot de cache weer teveel performance kosten natuurlijk.

[Rob_G]

ik denk dat AMD wel degelijk meer CPU's verkoopt met een prijsdaling van laten we zeggen 20% over de hele linie. Dit omdat de prijs/kwaliteit verhouding dan stijgt, en meer mensen die eigenlijk een Intel wilden nu toch maar de AMD kopen. Tegenwoordig is de beste prijs/kwaliteitsverhouding nog steeds in handen van AMD, maar dat verschil tussen AMD en Intel was vroeger groter.

Dus mijn advies aan AMD is: verdubbel de cache in plaats van het 5x groter te maken. Dit heeft een substantiele snelheidsverhoging EN kostendaling tot gevolg, waardoor de concurrentiepositie verbetert...

[Verwijderd]

Als je AMD's prijs laat dalen gaat imho het voornaamste effect zijn dat mensen AMD gaan linken met minderwaardig budget spul. In hoofde van veel mensen is duurder beter.

[Verwijderd]

het is maar net hoeveel verstand de verkopers in de winkel ervan hebben. Mensen die dure pc's beter achten dan goedkope, hebben er geen verstand van en zullen voordat ze een bak geld uitgeven meestal wel eerst even advies aan de verkoper in de pc-zaak vragen.

Afgezien van echt dom volk, maar dat heeft meestal niet eens geld, laat staan interesse in een pc

[Ranzy]

Ehm, verkopers proberen meestal gewoon het duurste aan te smeren, buiten die 1% geinformeerde en eerlijke verkopers...

[Verwijderd]

Aangezien zo'n L2-cache toegang altijd nog sneller is dan toegang tot geheugen buiten de chip, is "oneindig" je antwoord

[hellfire_ultd]

omdat software hier simpelweg (nog) geen gebruik van maakt.

Je kunt je cache geheugen met software nauwelijks tot niet beïnvloeden, hoewel programma's sneller worden als hun geheugentoegangspatronen geoptimaliseerd worden. Dat doen ze door het geheugengebruik zo lokaal mogelijk te houden, dus door zo lang mogelijk in een zo klein mogelijk stukje geheugen te blijven werken. Een groter cache geheugen betekent dat je software minder gelokaliseerd hoeft te werken om toch voordeel te hebben van het cache geheugen. Dus wat je zegt werkt juist de andere kant op: met een oneindig groot cache geheugen hoeft de software er simpelweg totaal géén rekening mee te houden.

[Verwijderd]

met een oneindig groot cache geheugen...

...wordt de toegangstijd daarvan ook oneindig ;-)

Maar in een realistischer scenario: de cache zorgt ervoor dat de gemiddelde toegangstijd tot het geheugen korter wordt.
Grotere cache => grotere hitrate => kleiner gemiddelde.
Deze relatie is echter niet lineair, waardoor het groter maken van de cache steeds minder lonend wordt.

Grofweg betekent een verdubbeling van de cache een halvering van de miss rate.

Als Tmem = 20 * Tcache
dan geldt bij een hitrate van 96% = missrate van 4%
Tgem = 0.96 + 0.04*20 = 1,76 * Tcache.

Verdubbel de cache, missrate wordt 2%
Tgem = 0.98 + 0.02*20 = 1,38 * Tcache
Dit is 22% snelheidsvoordeel uit de verdubbelling.

Verdubbel de cache, missrate wordt 1%
Tgem = 0.99 + 0.01*20 = 1,19 * Tcache
Dit is 14% snelheidsvoordeel uit de verdubbelling.

Vertienvoudig de cache nu, missrate wordt 0.1%
Tgem = 0.999 + 0.001*20 = 1,01 * Tcache
Dit is 16% snelheidsvoordeel uit de vertienvoudig!

[Astennu]

Jah maar is dat z-ram ook sneller dan de huidige cache ? volgens mij was de cache van intel zo i zo iets sneller dan die van AMD maar dat kan door de clockspeed van de chip komen.,

[Fairy]

Uiteraard, maar L2 kun je nu nog niet als alternatief RAM gebruiken, omdat software hier simpelweg (nog) geen gebruik van maakt.

[Verwijderd]

Dat geld altijd, minder cache is letterlijk, minder cash...
minder transistoren is lagere IPL, maar ook lagere prijs.

[Tijger]

Of AMD kan gewoon winst maken, dat zou ook wel leuk voor ze zijn, met name omdat een processor fabrikant bijna constant moet investeren in technologie en productie processen/capaciteit.

[zenlord]

Er zijn inderdaad meerdere beleidskeuzes mogelijk met een dergelijke nieuwe technologie, maar persoonlijk zou ik eerder voor de lange-termijn-winst gaan door op midellange termijn de concurrentie zo sterk mogelijk af te troeven.

[TheGhostInc]

Opvallend is dat AMD zowel voor 90 als 65nm deze techniek aan het voorbereiden is. terwijl de verwachting is dat deze techniek eind volgend jaar pas op de markt komt. Dan is 90nm neem ik aan al bijna uitgefaseerd.

Als AMD Intel echt op achterstand wil zetten, dan moeten ze daar binnen een jaar wel meekomen, anders zit Intel met de nieuwe architectuur op een nieuw spoor. Dan kunnen ze wel ontzettend veel L2 cache hebben, maar met een processor die net niet meekomt ben je nog verder van huis. Plus dat Amd juist weinig baat had bij cache, aangezien de geheugencontroller on-die zit.

* 786562 TheGhostInc

[Kaaswagen]

Niet zo snel, er zijn genoeg naab consumenten die denken:

"dat intel Duo ding heeft 2 X 1 mB en die AMD 2 X 8 MB... hmm toch maar de AMD"

Zoiets als wat Intel deed met clocksnelheden, maar dan anders

[Verwijderd]

Wat intel nu al doet met cache, er is een pentium D met 2x2mb cache?!?!

[Verwijderd]

Die nieuwe architectuur zal zijn best moeten doen om AMD bij te houden. Intels laatste processoren bevatten grote ontwerpers fouten. AMD's onboard memory controller blijft zijn grote troef, en als AMD overstapt om DDR2(of eigenlijk liever DDR3) kan het ook alleen maar beter gaan.

Meer cache betekent minder cahce-misses betekend.
1. Extra snelheid, altijd.
2. Kosten van lange pipeline worden lager (eventueel voor het pushen van MHzzetten zonderdat de IPL erg ver omlaag gaat).

De onboard memory controller maakt het geheugen een heel stuk sneller, maar nog steeds op lichtjaren afstand van cache...

[Atmosphere]

[b]Jan Groothuijse: [/b]

De onboard memory controller maakt het geheugen een heel stuk sneller, maar nog steeds op lichtjaren afstand van cache...

Nou.. het maakt het niet echt sneller ... alleen de toegangstijd (latency) is zo veel lager dan bij bv de athlon xp...

linkje: Memory Latency and Bandwidth

[Verwijderd]

Lagere latency is wel degelijk sneller, sterker nog, het is de enige reden dat de K8 in 32bit mode van de K7 wint...De K8 heeft een langere pipeline, een lagere ipl, en dezelfde execution hardware.

[Atmosphere]

peek-bandwidth (sequential-access )wordt echt niet hoger door latency reductie... Echter bij scatter-toegangspatronen (random-access) neemt de totale doorvoer wel toe.

Het geheugen is echter niet sneller geworden zoals jij stelt.

[Skyline GT-R]

Ik denk toch dat jij is wat meer mag gaan opzoeken over die nieuwe architectuur van intel. De Conroe wordt niet zomaar ff een nieuw processortje van intel hoor. Je kan het eerder zien als serieus geoptimaliseerde Yonah (die al bijna even snel is als een X2) en die dan ook nog is op bijna 3GHz loopt. AMD gaat echt met iets heel geweldigs op de proppen moeten komen willen ze intel dit jaar voor blijven...

[Verwijderd]

AMD is vooral erg sterk op het gebied gaming, en ik zie niet in waarom de nieuwe intel architectuur hier verandering in zou brengen. Die architectuur is er overgens nog niet, ik heb het idee dat AMD nog wel even door kan met de AMD64, desnoots met een vebeterde en DDR2/3 ondersteunende memory controller, maar AMD's voet in het gaming segment staat erg vast.

Natuurlijk in de winstone benchmarks en office benchmarks enzo, is de K8 nooit echt goed geweest.

[SPee]

Ze hebben hier misschien minder aan dan intel, maar meer cache direct(!) op je processor is altijd mooi meegenomen.
Dit is stukken malen sneller dan via je dimmetjes. Daar zit een grote bus tussen met een lagere snelheid dan dat je geheugen direct tegen je processor aanzit en ook op dezelfde snelheid zit.

[Femme]

De cache bezet op een desktopprocessor al een aanzienlijk deel van de die. Het vergroten van de dichtheid van de cache is altijd gunstig omdat het een directe kostenbesparing kan opleveren. Intel was hier al erg goed in en dat is één van de redenen waarom de Itanium zulke belachelijke hoeveelheden cache kan hebben. Als AMD hierin mee wil kunnen gaan zal het ook serverprocessors met grotere caches moeten gaan aanbieden.

[Verwijderd]

* TheGhostInc vindt het een beetje een onlogisch verhaal, Intel heeft veel meer baat bij deze techniek, de winst voor Amd is veel kleiner.

Voor single core desktop cpu's heeft het inderdaad weinig nut. Voor de toekomstige Quad core Opteron chips is een grotere L2 Cache wel noodzakelijk. En als je toch al bezig bent waarom niet gelijk alles mee vervangen?

[Verwijderd]

Ik zie hier niet echt een concurrentievoordeel in. Het is namelijk niet zo dat AMD dit exclusief heeft. Als dit inderdaad zo simpel werkt zal Intel gewoon ook een licentie nemen en hetzelfde trucje uithalen.

Het lijkt mij gewoon een kostenbesparing en meer niet. Maar ook dat is leuk

[Atmosphere]

Nou iig bij kleine hoeveelheden, in een omgeving met niet zo heel veel independend threads...

Ik denk dat je in je achterhoofd moet houden dat een veel groter cache met meer lanes en een hoger associatie-vermorgen erg handig zijn in de nabije toekomst vanwege virtualisatie-technieken zoals pacifica.

AMD ziet daarnaast ook dat Intel ook steeds grotere caches implementeerd... DIt houdt in de de Intel-compilers hier ook rekening mee (gaan) houden, waarschijnlijk die van MS ook, etc... De Intel-processoren met veel cache zullen hierdoor beter gaan presteren in vergelijk met AMD of Intel met minder cache.. (Let wel: prestatie verschillen zullen niet dramatisch zijn... maar wel merkbaar/meetbaar)

[daft_dutch]

O ja hoor maak er maar direct 10MB cache van.
Hebben ze nooit van cache hit rates gehoordt. Tuurlijk is het sneller. Maar wat is het percentueel verschil met bijvoorbeeld 5MB

[Zwartoog]

Hangt af van wat je wilt.

Als de verwerking van de cache net zo lang duurt als het ophalen uit het geheugen dan zit er inderdaad een duidelijke grens aan (stel je CPU heeft 100ms nodig om de cache leeg te werken, en je geheugen heeft 100ms nodig om de cache opnieuw te vullen: dan zit je in evenwicht).

Daarentegen, als je twee matrices met elkaar vermenigvuldigt, en van het resultaat een decompositie wilt maken (zeg maar wat), dan is het handig als beide matrices en de uitkomstmatrix in de cache blijven. En aangezien matrices voor serieuze problemen erg groot kunnen worden (1GB geheugen per matrix is niet vreemd), kun je je voorstellen dat je niet genoeg cache kunt hebben...

[Verwijderd]

AMD is wel hard bezig met het aanschaffen van licenties. Eerst bij Rambus en nu weer hier.

Maar weet iemand of Intel niet gewoon ook een licentie op een soortgelijke technologie heeft?

[Verwijderd]

Vergeet niet dat intel met de itanium 3 ook al met 24MB (ok tis L3 cache ) en 2,5 MB L2 komt.

[RobT]

Interessant dat velen hier een 'of ... of ...' gedachte bij hebben.

Mij lijkt het eerder dat het mes aan twee kanten snijdt: je kunt bij gelijke hoeveelheden cache een kleinere die hebben, dus goedkoper te produceren, of bij gelijke die-grootte een grotere cache dus betere prestaties.
Daarbij klinkt het ernaar dat dit Z-RAM sneller is. Dit kan ook inhouden dat bij dezelfde snelheid er minder energie gebruikt wordt (zero cap!) en/of dat de chips sneller geklokt kunnen gaan worden.

Dus: de low-end cpu's kunnen goedkoper gemaakt gaan worden, en toch iets beter presteren (zelfde hoeveelheid cache, wel snellere cache), en er zijn betere topmodellen met veel meer cache (en met navenant prijsschema) te maken, met voor het overige hetzelfde design.

Dus uitbreiding aan de bovenkant van het aanbod, met ophoging van de onderkant, terwijl de productiekosten dalen of gelijk blijven.

Als AMD deze technologie inderdaad binnen een jaartje productierijp heeft, ziet het er erg goed uit. In spanning afwachten maar...

[Verwijderd]

Is het ook bekend waar het einde van de cache optimalisatie is? Want ik denk dat de snelheid steeds minder toeneemd met een groeiende cache. De meeste programma's hebben maar een kleine set geheugen die ze steeds hergebruiken toch?

[.oisyn]

kevlar01 geeft het hierboven al juist weer. Met de huidige CPU snelheden en achterblijvende RAM snelheden en hoge latencies is geheugen veruit de grootste bottleneck van games en geheugen-intensieve applicaties. Een grotere cache betekent vrijwel altijd een toename in snelheid omdat de juiste data zo goed als direct opvraagbaar is

[SpiceWorm]

Waarom zijn de athlons van deze generatie (s939) met 1 mb cache amper sneller dan de versies met 512kb op dezelfde clock?

[TD-er]

Mischien omdat vrijwel alle routines waarbij het dus uitmaakt mogelijk zijn geoptimaliseerd voor max 512 kB cache, of mischien zelfs wel voor 256kB.
Pas wanneer je je routines zo maakt dat je bijvoorbeeld een hele stap in je programma wel in die grotere cache kunt passen en niet in de 512 kB cache, dan zul je een serieuze sprong in performance zien.
Bijvoorbeeld een FFT routine die zo groot is dat 'ie niet meer in de huidige cache past.

Een ander probleem kan zijn dat bij het switchen van 2 taken de cache in het gewone geheugen geplaatst moet worden. Als dit ineens een groter blok data is, kan het zijn dat de taskswitching dus duurder wordt, waardoor de winst weer teniet gedaan wordt.

[Left]

In de cache stop je data of code die nu of heel binnenkort nodig is. In het ideale geval vul je de cache weer aan met nieuwe data terwijl de cpu nog bezig is de oude data te gebruiken. Als je cache klein is dan komt het geregeld voor de de cpu de cache data heeft opgegruikt voordat de cache is aangevuld. In dat geval is het zinnig om een grotere cache te gebruiken. Echter, hoe groter je je cache maakt, hoe minder snel het voorkomt dat je cpu de cache heeft opgebruikt. Boven een bepaalde grens wordt het vergroten van de cache dus steeds minder nuttig. Bij de nieuwe Athlons ligt deze grens kennelijk in de buurt van de 512KB.

[.oisyn]

Waar baseer je dat op? Wat voor tests zijn er gedaan? Een cpu-intensieve test als pi uitrekenen is niet representatief, daar zullen beide cpu's even snel in zijn.

[BartOtten]

Volgens mij hebben de huidige spellen vaker last van de HardDisk latency. Zeker als ze grote maps gebruiken wil de HD nog wel eens even nodig hebben...

[Cyberamp]

Volgens mij hebben de huidige spellen vaker last van de HardDisk latency. Zeker als ze grote maps gebruiken wil de HD nog wel eens even nodig hebben...

Dat is alleen tijden het laden. Tijdens het spelen wordt
er nauwelijks wat geladen, alles zit in je geheugen.

[.oisyn]

De vertragingen die je opmerkt in games tijdens laadmomenten komen ook deels door stalls van de videokaart omdat er weer een hele zooi textures overgepompt moeten worden. Als een game een beetje goed geprogrammeerd is (vroeg genoeg beginnen met laden, data in delen vewerken, zorgen dat de data überhaupt al in een zo ver mogelijk verwerkte vorm op disk staat zodat je het direct kunt gebruiken) zou je hier geen last van moeten hebben.

En swapfiles zijn natuurlijk vreselijk. Gaat ook gepaard met veel diskaccess, maar ook hele lappen data worden uit het geheugen weggeschreven. Je moet je voorstellen dat dat proces zich voordoet tijdens je game, en dat die twee processen zich continu afwisselen op de CPU. En is dus elke keer alle data uit je cache weg.

[Atmosphere]

Zoiets is makkelijk op te lossen met raid (raptors in stripe bij voorkeur) en misschien iets meer intern geheugen

[kevlar01]

Denk dat het pas ophoudt als de cache het RAM geheugen kan vervangen, omdat dat eigenlijk een buffer is die na het cache geheugen komt, maar veeeeeeeel trager is. Dus als de cache 2 of 4 GB is dan zou RAM niet meer nodig zijn en extra cache ook niet. Nadeel is wel dat cache niet uitbreidbaar is.

[MetalfanBlackness]

Ik denk niet dat cache geheugen ooit het echte geheugen zal vervangen, daar is het ook niet voor bedoelt. Het is alleen voor vaak opgevraagde gegevens dichter bij de processor te brengen, maar gegevens in het geheugen is heel iets anders dan de cache. Hoe meer cache, hoe minder het geheugen gelezen moet worden, maar er is steeds meer ram nodig, dus dan zou de ontwikkeling van het geheugen voor de cpu (je kunt het dan niet echt meer cache noemen) wel heel erg snel gaan, je hebt nu vaak 1gb of meer ram in je pc zitten, terwijl ik in mijn vorige pc toch tevreden was met 256mb ram.

[Verwijderd]

(alsjeblieft, je vraagt erom om ge 640kB'ed te worden)

Spellen kunnen nog wel eens meer cache nodig hebben (of baad hebben bij meer cache), maar somige CPU fabrikanten verhogen telkens de latency van het cache wanneer ze het verdubbelen, misschien dat je hierdoor op het idee gebracht wordt dat meer cache niet zo veel verschil uit maakt.

[stappel_]

hij heeft niet helemaal ongelijk om de vraag te stellen.
vroeger was het zo dat het totaal nutteloos was meer dan 256mb in je pc te prikken. de windows memory manager was niet geschikt om meer te gebruiken. hij gebruikte het wel maar de pc werd niet sneller.

zo ook met de cache. er zal een limit zijn waarop de huidige cache manager een te grote cache lookup tabel krijgt en slecht gaat presteren.

[Verwijderd]

cache manager?

Nouja, in ieder geval heb je gelijk over een grotere lookup table, dat wordt altijd langzamer, maar er zijn genoeg apps die nog voordeel kunnen hebben van extra cache.

[Verwijderd]

Is het ook bekend waar het einde van de cache optimalisatie is?

640 KByte should be enough for everyone! (Bill Gates, 1981)

[Cyberamp]

640 KByte should be enough for everyone! (Bill Gates, 1981)

Heeft hij nooit gezegd (even de feiten van de roddels scheiden)

[SPee]

Ik denk dat die grotere cache eerst in de server processoren komen te zitten (de dure dus). De prijzen voor die processoren zullen ook niet erg laag zijn, vrees ik.

Ik ben benieuwd of intel niet al met zoiets bezig is en wat hier hun antwoord op zal zijn. (in de trand van: meer cache is slecht voor de processor oid?)

[familyman]

Misschien iets als

2048 kb cache is enough for everyone!

[ShellGhost]

Wat ik ook wel belangrijk vind is de warmteproductie.
Iedereen speculeerd wel over de snelheid en de hoeveelheid van de cache, maar ik hoor niks over de warmte die het misschien met zich mee brengt.
Zou dat minimaal zijn tegenover de huidige cache techniek of zou het juist een vermindering teweeg brengen?
Of wordt het juist wat warmer onder de motorkap?

[Verwijderd]

Z-ram verbruikt minder stroom, dus zal ook wel minder warm worden he En als het wel warm wordt is dat misschien een reden waarom intel deze niet neemt, omdat inteltjes al lekker warm worden (ik weet niet hoe het zit met de nieuwe conroe? maar bij 3,33ghz en 4 ipv 3 instructies per clock denk ik niet aan een lekker koel processortje).