'Eerste Intel Optane-producten bieden 16GB en 32GB 3D XPoint-geheugen'

De eerste producten op basis van 3D XPoint-geheugen zijn naar verluidt twee Optane Memory 8000p-modules, van 16GB en 32GB. Intel zou ze in de markt willen zetten als geheugen voor systeemacceleratie en niet als ssd's.

Intels Serie Optane Memory 8000p komt op de markt in configuraties met 16GB en 32GB en in de formfactors m2-2280 en m2-2241 waarbij ze van de pci-e 3.0 x2-bandbreedte gebruikmaken. Dat meldt de Taiwanese site Benchlife, dat vaker informatie over Intel-producten vroegtijdig publiceert. De 32GB-variant biedt betere lees- en schrijfsnelheden: achtereenvolgens 1600MB/s en 500MB/s. Bij de 16GB-variant zijn de sequentiële lees- en schrijfsnelheden respectievelijk 1400MB/s en 300MB/s. Ook de geclaimde random 4k-lees- en schrijfsnelheden staan in de tabel die BenchLife publiceert.

Informatie over de gebruikte controller is er nog niet. De modules zouden bedoeld zijn voor de combinatie met Intels Kaby Lake en latere platformen, onduidelijk is of er ondersteuning voor eerdere platformen komt. Op een eerder verschenen roadmap over het Optane-geheugen van Intel stond het System Acceleration onder de codenaam 'Stony Beach' met een releaseperiode van eind 2016.

Tegen die tijd moet ook Mansion Beach verschijnen, de eerste pci-e 3.0 x4-ssd op basis van het nieuwe type geheugen. Begin 2017 volgt Brighton Beach, de pci-e 3.0 x2-variant. 3D XPoint betreft een vorm van phase change-geheugen, waarbij individuele cellen of bits net als bij dram individueel kunnen worden aangesproken: bij flashgeheugen worden cellen steeds per string uitgelezen en per blok beschreven. Het moet de snelheid van werkgeheugen combineren met de opslagcapaciteit van flashgeheugen. Volgens het bedrijf zal het geheugen in de toekomst 1000 keer zo snel als nand kunnen zijn, 1000 keer zo lang mee kunnen gaan en een tien keer zo grote dichtheid kunnen bereiken als dram, waarmee het veel goedkoper moet worden.

Reacties (60)

[bosbeetle]

"als geheugen voor systeemacceleratie" Hoe moet je dat in de praktijk zien. Met andere woorden zijn operating systems hiervoor al ingericht, of wordt het gebruikt om te swappen of iets dergelijks?

Of gewoon sec aangesproken als conventioneel werkgeheugen?

[Reactie gewijzigd door bosbeetle op 23 juli 2024 13:06]

[dmantione]

Ik heb er enkele weken geleden een presentatie van Intel over gehad. Dit kan de hele informatica op zijn kop zetten. Het is direct adresseerbaar geheugen, net als RAM-geheugen. Dit betekent dat een bestand dat op Xpoint-geheugen opgeslagen is, niet eerst geladen hoeft te worden. Als je het wilt raadplegen krijg je gewoon een pointer naar het bestand dat al in het geheugen staat. Je kunt ook denken aan pointers tussen bestanden. Elke wijziging wordt direct permanent bewaard, dus bit in het geheugen veranderen is klaar.

Als je momenteel een ingewikkelde datastructuur op schijf moet opslaan, dan volgt een ingewikkeld proces van serialisatie van de structuur. Niet meer nodig. Alloceer de datastructuur in crosspointgeheugen en klaar is Kees.

Maar je kunt het ook als RAM gebruiken. Swappen tussen RAM en crosspoint is niet nodig, want crosspointgeheugen is snel genoeg om direct gebruikt te kunnen worden. Stel je hebt straks 8GB RAM en 512GB crosspoint, al die 512GB crosspointgeheugen kan als tijdelijk werkgeheugen gebruikt worden.

[TD-er]

Dat is zeker interessant, maar is dan 32 GB niet een beetje weinig?
Dat soort zaken wil je dus als aanvulling op RAM en dan is 32 GB wel heel weinig extra, aangezien je een beetje server van tegenwoordig al snel voorziet van een veelvoud van dat.
Het moet dan al erg dicht bij de prijs van een SSD liggen, wil het interessant zijn, aangezien je voor 16 a 32 GB aan RAM nu ook niet echt de hoofdprijs betaalt.

Edit:
Je zou het natuurlijk wel kunnen gebruiken voor een journal van een filesysteem en een cache-tier voor bijvoorbeeld een Ceph cluster met erasure encoding.

[Reactie gewijzigd door TD-er op 23 juli 2024 13:06]

[dmantione]

Daar ben ik het mee eens, maar wellicht is dat de reden waarom het als "cache" gepresenteerd wordt.

[necessaryevil]

Dat was dus ook mijn gedachte, je kan er ook extra ram inprikken, daar heb je geen Optane voor nodig...

//edit
Misschien is het extra nut dat het om non-volatile memory gaat. Ik zit te denken aan snel booten o.i.d.

[Reactie gewijzigd door necessaryevil op 23 juli 2024 13:06]

[Carni]

Dat is zeker interessant, maar is dan 32 GB niet een beetje weinig?

Ik denk dat je er van Intel best meer dan 1 mag kopen
Geen idee of dit nog interessant is om in een vorm van raid te zetten? Of als read/write cache?

[TheekAzzaBreek]

Niet als aanvulling op RAM, maar als vervanging van zowel RAM als Tier 1 storage, dat is nu juist de grote belofte van deze technologie. Als dat lukt dan wordt dat een revolutie in hard- en software. Het onderscheid tussen het bewerken van gegevens en het opslaan vervalt, dat belooft veel voor real-time en high-concurrency toepassingen.
Zo ver zijn ze overigens nog niet, RAM performance zit er nog niet in, maar de verwachting is dat dat een kwestie van jaren is.

[supersnathan94]

Daarnaast (en dat is wat ik nu mis in het hele verhaal) zijn de prestaties helemaal niet zo denderend. Samsungs 3D-Nand based NVME drives zijn een stuk sneller in sequentiele en random data en random IO is juist datgene wat geheugen, geheugen maakt. Ze zijn per GB ook nog eens een stuk goedkoper.

De huidige drives is dus meer proof of concept dan ook echt nuttig ofzo. Zet een andere controller op een SM951pro en je hebt meer en beter. Lijkt mij.

[cdwave]

Uh, elk OS presenteert alles al als een geheugenmapping.

Je kunt losse files of partities of hele schijven gewoon direct adresseren als geheugen. Het OS zorgt transparant voor het uitwisselen van data. Geen nieuwe hardware nodig, dat werkt al heel lang zo.

Dus die revolutie zie ik niet zo zitten.

[dmantione]

Nee. Jij bedoelt een mmap. Een bestand heeft bij een mmap pas een geheugenadres zodra je het mapt. Daarmee is er geen vaste pointer naar een bestand mogelijk en ook pointer kruislings tussen bestanden zijn niet mogelijk. Het mappingadres is (normaliter) variabel waardoor je geen interne datastructuren in dat "geheugen" kunt aanmaken. En, omdat het een emulatie is, is dat ook geen goed idee vanwege prestatieoverwegingen.

Gegevens in mmaps zijn doorgaans gewoon geserialiseerd, net als bij bestanden die via read/write bewerkt worden. Mmaps maken met name random access in bestanden wat eenvoudiger.

[cdwave]

Wat ik bedoel gaat verder dan alleen de "mmap" call. Het OS zelf mapt alles naar adresranges, ook als de applicatie gewoon klassiek read/write doet.

Aangezien je ook kunt kiezen waar een mapping terecht komt, kun je, als je dat wil, gewoon pointer structuren gebruiken over diverse sessies heen, en deze zelfs tussen mappings uitwisselen. Zelfs met andere machines.
Probleem wordt dan wel dat je alle problemen die een filesystem voor je oplost dan weer terug krijgt. Dat is een van de redenen dat we dat nooit doen.

Serialiseren is helemaal het probleem niet, als je maar goed nadenkt over hoe je de data wil opslaan. Databases gebruiken doorgaans in memory dezelfde opslag als op disk, dan is de serialisatie gewoon een no-op. En om by in-memory structuren nog een extra optelling te doen voor elke pointer dereference is met name op een Intel CPU nagenoeg gratis, dus ook complexe boomstructuren kun je prima opslaan in hetzelfde formaat als op je persistent store.

Als je gewoon het geheugen intact wil houden is het simpeler om de hele machine niet meer uit te zetten. En als je dat toch wil, in stand houden van gigabytes RAM kost nauwelijks energie, dus met een suspend-to-RAM ben je dan beter af.

[gertrudi]

Het grote verschil tussen een ssd en geheugen is, is dat een ssd niet byte adresseerbaar is. Als je 1 byte wil wijzigen zal je eerst een blok van 4 kb (orde van grootte) in moeten lezen dan byte aanpassen en dan terugschrijven.

[cdwave]

SDRAM, waaronder dus ook het geheugen in je PC, is ook niet byte-adresseerbaar.

[groene henk]

Lijkt interessant, maar met snelheden van 1.4GB/s is dit niks vergeleken met de 70GB/s wat memory van een i7-E systeem kan halen (normaal i7 systeem doet de helft).

Daarbij tellende dat een Nvme SSD als het dubbele doet, dan mis je dus aan beide kanten (normaal geheugen is sneller en snelle SSD's zijn sneller).

Het enige wat het dan nog interessant kan maken is de prijs

[dmantione]

Dat is een beetje kortzichtig: De eerste SSD's waren ook traag en verloren het sequentieel ruimschoots van een harde schijf. Dit geheugen wordt ook sneller, zodra het op DIMM's te krijgen is zal je bijbehorende bandbreedtes zien. Verder is deze maar 32GB groot. Voor 32GB opslag is 1.4GB/s heel veel, lukt je niet met een 32GB SSD.

[TheekAzzaBreek]

Henk heeft wel een punt: Intel & Micron verkopen dit als het toekomstige alternatief voor zowel SSD als RAM. T.o.v. SSD komen ze leuk mee, maar t.o.v. RAM hebben ze nog wel wat te doen. Dat dat wat tijd nodig heeft is niet zo vreemd, overigens, het is voor het eerst dat deze technologie op grote schaal ingezet gaat worden.

[TD-er]

Wat natuurlijk wel interessant is, is dat je commits naar een filesysteem veel sneller kunt doen en dus daarmee al een hoop complexiteit weg kunt laten die nodig is om er zeker van te zijn dat in alle gevallen de data niet corrupt kan raken.
Je zou het dan inderdaad als cache kunnen zien, maar anders dan het "SSD-deel" van een hybride schijf.

[sdk1985]

Zo lang ze nog op 3000 MB/s zitten is dit natuurlijk nog lang geen vervanging voor ram. Tegenwoordig zitten we namelijk over de 25000 MB/s aan bandbreedte.

In deze vorm lijkt het meer iets voor Intel srt/rst http://www.intel.com/cont...d-storage-technology.html .

[Reactie gewijzigd door sdk1985 op 23 juli 2024 13:06]

[casparvl]

Ik ben absoluut geen expert op dit gebied, maar weet dat FreeNAS bijvoorbeeld gebruik kan maken van SSDs als snelle lees/schrijfbuffers (zoals anderen al hadden gezegd, beetje a-la de hybride harde schijven). Gezien dit geheugen op een M2 slot gaat, kan ik me voorstellen dat FreeNAS het vrij eenvoudig op een vergelijkbare manier zou kunnen aanspreken en gebruiken.

Dus, in die zin zijn er al OS-en die hier inderdaad op zijn ingericht, maar ja... FreeNAS is dan ook wel een OS dat gericht is op opslag... Hoe het bijv. met Windows zit, of die er op de een of andere manier gebruik van zou kunnen maken... geen idee.

[DigitalExorcist]

Met Storage Spaces kan Windows al iets ongeveer vergelijkbaars doen in SAN omgevingen; veelgebruikte data op SSD's zetten en 'oude' data naar HDD's verplaatsen zonder dat je hier zelf iets van ziet. Das echter niet hetzelfde als caching SSD's gebruiken. Volgens mij ben je dan nog aangewezen op swapfiles en zo. Maar ik weet niet of Windows 2016 daar verandering in brengt.

[PcDealer]

Is dit niet bekend als data tiering?

[DigitalExorcist]

In feite wel, storage tiers .. MS noemt het alleen weer eens anders

[supersnathan94]

Daarvood kan je dan alleen beter een Samsung of Intel NVME drive gebruiken. Sequential reads en writes zijn een stuk hoger en IOPs ook. Daarnaast is 256GB niet eens zo heel duur in verhouding met wat dit ws gaat kosten per GB

[robvanwijk]

Of gewoon sec aangesproken als conventioneel werkgeheugen?

Op dit moment nog niet: "Intels Serie Optane Memory 8000p komt op de markt [..] in de formfactors m2-2280 en m2-2241". Uiteindelijk is het inderdaad wel de bedoeling dat dat mogelijk gaat worden.

[dmantione]

Dat zegt niets: Directe adressering van geheugen via PCI-E is geen enkel probleem. Dat gebeurt bijv. nu al met het geheugen op je videokaart.

[robvanwijk]

Zelfs al krijg je het geadresseerd (en ik betwijfel of je kunt booten zonder "gewoon" RAM, met alleen geheugen aan je PCI-E bus; als het technisch kan, dan toch echt alleen met een heel erg custom BIOS), dan nog gaat het geen fatsoenlijk werkgeheugen zijn; het zit gewoon fysiek te ver van de processor af.

Bovendien ging de vraag van bosbeetle niet over "werkgeheugen", maar over "conventioneel werkgeheugen". Als je het met allerlei trucjes uiteindelijk aan de praat krijgt (hulde! ), dan nog telt het toch echt niet als "conventioneel". Let ook op de laatste zin van mijn reactie: op de lange(re) termijn gaan hier "DDR4" reepjes van gemaakt worden (correcter: DIMM reepjes) en dan wordt het wél (de volgende generatie) conventioneel geheugen.

[dmantione]

Crosspoint-geheugen adresseren en DRAM vervangen zijn twee gescheiden zaken. Op lange termijn kan crosspoint-geheugen DRAM mogelijk vervangen. Het ligt in de planning dat er over enige tijd DIMM's met crosspoint-geheugen komen. Op dat moment kan je er DRAM mee vervangen, maar het hoeft niet, DRAM- crosspoint-DIMM's kunnen gemengd worden.

Als je er vanuit gaat dat een belangrijke doelstelling van crosspoint is dat je het direct kunt adresseren, lijkt het me zeker niet gek dat dat bij een M.2-implementatie ook het geval zal zijn, zeker nu in dit nieuwsbericht aangekondigd wordt dat het geen SSD's worden.

[rjberg]

Van wat ik ervan begrijp is xpoint nog niet zo snel als ram, maar wel sneller dan ssd's. Het is wel goedkoper dan ram, dus misschien inderdaad een swapfile.

Het grootste voordeel is misschien nog wel dat het geen stroom nodig heeft om zijn data te bewaren. Als je dit dus wel als ram gebruikt zou je dus stroom besparen en ook nog eens goed beveiligd zijn tegen stroomuitval. Je start op, en de computer doet precies hetzelfde als hij deed voordat hij werd uitgezet.

Ik vraag me af of mobiele apparaten met android of ios ook hiervan gebruik zullen maken als het sneller wordt. RAM en opslag op dezelfde eenheid, met veel opslagruimte vanwege de hoge dichtheid, weinig stroomverbruik, en heel snel opstarten/afsluiten, dat lijkt me wel wat.

[AndreStarTrek]

Sneller dan M.2 x4 PCIe gen 3? Misschien de IOPS maar maar de rest is langzamer, Ik zie op deze wijzen niet zo veel nut van deze techniek in desktop PCs.

Dit zou wel een uitkomst kunnen bieden voor NAS server met ZFS zoals FreeNAS, dan kan je daar ZIL en/of L2ARC op zetten.

[Reactie gewijzigd door AndreStarTrek op 23 juli 2024 13:06]

[dasiro]

als je veel databasecalls doet dan kan het goed zijn dat je met meer IOPS toch een lagere doorvoersnelheid haalt, het hangt er gewoon maar van af hoeveel data er wordt opgevraagd, maar dat je toch sneller klaar bent.

[supersnathan94]

Samsung en intel nvme drives halen al 450.000 iops

[pduin]

Als ik een gokje zou moeten wagen denk ik iets in de richting als wat Intel al doet met RST, een techniek waarbij een (deel van een) SSD kan worden ingezet als cache voor een traditionele en trage harddisk.

[Johannes77]

Ik denk dat het beste gebruikt kan worden om van een reguliere harddisk een hybride shd te maken, vergelijkbaar met de Momentus XT van Seagate.

[jadjong]

Frits van de virtualisatie heeft al een tijdje de optie om werkgeheugen van nodes uit te breiden via interne storage. Zo kan je met 32GB ram toch 64GB aan vm's aanzetten en zolang ze niet allemaal tegelijk actief zijn goocheld de node wel virtueel ram heen en weer tussen fysiek ram en een SSD of dit chipje van Intel.

[TheekAzzaBreek]

"als geheugen voor systeemacceleratie" Hoe moet je dat in de praktijk zien. Met andere woorden zijn operating systems hiervoor al ingericht, of wordt het gebruikt om te swappen of iets dergelijks?

Of gewoon sec aangesproken als conventioneel werkgeheugen?

'Conventioneel' werkgeheugen is de toekomst, deze technologie belooft op den duur het onderscheid tussen werkgeheugen en opslag weg te nemen. Zo ver is het nog niet.

Ik vermoed dat ze hier storage accellerators bedoelen, vergelijkbaar met de SSD caches in moderne SANs.

[Navi]

Hmm had hier meer van verwacht, dit is toch helemaal niet zo snel? De pas uitgekomen nvme ssd van samsung, de 960 pro doet al het dubbele?

[Powrskin]

qua doorvoer, maar waar het om gaat is 4k iops.

[Navi]

Ook daar wordt het ruim verslagen, 3500/2100 mb/s en 440.000 / 360.000 4k iops voor de 960 pro.

[Diavire]

Je vergelijkt een grote SSD met kleine RAM packages.

De SSD is zo snel over hij over veel chips tegelijk schrijft, breng de opslag terug naar 32GB zoals deze sticks en de snelheid zou veel lager uitvallen.

Dat kan dan ook de andere kant op werken, stop deze chips in grotere SSDs en ze zullen weer veel sneller zijn.

[Yamotek]

Dan blijven er twee belangrijkere vragen over, wat gaat de prijs doen en wat is de betrouwbaarheid (en verhouding daarvan met de prijs dus) per GB van dit type geheugen.

Nu is het wel zo dat een SSD ook RAM geheugen als buffer kan hebben, maar ik moet zeggen dat ik met deze opslagcapaciteit niet echt warm loop om dit speciaal aan te schaffen voor een 'swapfile'. Aangezien goedkoop DDR4 ram ongeveer 50 euro is voor 16 GB moet dit geheugen hier al ver onder liggen willen het kunnen concurreren met normaal RAM.

[Powrskin]

ik zie het dan is het wel wat crappy.

[FireDrunk]

En zelfs die vallen me tegen zoals @Navi al zegt... 3D XPoint zou tussen SSD (in mijn ogen dan dus NVMe) en (D)RAM in moeten zitten.

Nu is het eigenlijk gewoon een matige NVMe SSD, en zelfs dat niet...

Maar het is de eerste iteratie, dus hopelijk zien we in opvolgende producten(/firmware/versies) een mooie verbetering.

[gintoki]

The 512GB also features 512MB of DRAM cache and is rated to deliver up to 330,000 IOPS of 4K random read and write performance. DRAM cache is doubled to 1GB for the 1TB model, which bumps up 4K random read and write performance to 440,000 IOPS and 360,000 IOPS

over de 960 pro bron

misschien is de durability nog hoger(?).
Ik had wel iets meer verwacht van Intel qua specs. Zeker als je kijkt hoe ze het Xpoint verhaal hebben lopen hypen.

[Reactie gewijzigd door gintoki op 23 juli 2024 13:06]

[TheekAzzaBreek]

Hmm had hier meer van verwacht, dit is toch helemaal niet zo snel? De pas uitgekomen nvme ssd van samsung, de 960 pro doet al het dubbele?

Maar dan heb je het over 512 GB units, die zwaar kunnen parallelliseren. Hier hebben we het over 16 of 32 GB.

[locke960]

Deze hele discussie is een beetje zinloos zolang we niet weten wat het Intel ding gaat kosten. Pas dan kun je het vergelijken met producten in dezelfde prijscategorie en iets zinnigs over verschillen zeggen.

[TheGhostInc]

Ik denk dat 'we' een beetje verwend zijn geraakt en als dit ding 2 jaar geleden was uitgekomen dan waren we volledig weggeblazen. De 950 is pas een jaar oud!

Daarnaast moeten we het nog even doen met de 960 pro, terwijl de volgende generatie van Intel begin 2017 al zou moeten komen met pci-e 3.0 x4. Ik vermoed dat ze heel snel haasje over gaan doen. Als een nieuwe technologie binnen een jaar de huidige top verslaat heb je echt iets bijzonders. De eerste SSD's hadden bijvoorbeeld ook flink moeite om de HDD's bij te benen. Dan waren echt alleen de IOPS beter.

Intel heeft wel geluk dat de .m2 pci-e 3.0 x4 sloten nu overal verschijnen. Dat maakt het voor veel meer mensen bruikbaar als het echt doorbreekt.
Als volgend jaar de volgende generatie SSD's en deze drive's uitkomen dan krijgen we een mooie strijd die de hdd's bijna doen vergeten.

[Verwijderd]

"3D XPoint betreft een vorm van phase change-geheugen, waarbij individuele cellen of bits net als bij dram individueel kunnen worden aangesproken: bij flashgeheugen worden cellen steeds per string uitgelezen en per blok beschreven."

Volgens mij kun je dram geheugen per byte lezen/schrijven maar is een enkele bit niet te benaderen.

[scsirob]

Dat heeft met packaging op de DIMMs te maken. DRAM kan wel degelijk per bit aangestuurd worden. Sterker nog, vroege PC's hadden losse chips voor ieder bit. Je had er acht (of negen voor parity) van nodig om een byte te vormen. Zoek de 4164 of 41256 DRAM maar eens op.

[Verwijderd]

Welke CPU kan één bit lezen/schrijven op de databus ?
Je leest de hele byte, maskeert de waarde en schrijft dan de hele byte terug om één bit te kunnen wijzigen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 13:06]

[robvanwijk]

Welke CPU kan één bit lezen/schrijven op de databus ?

Van de Z80 weet ik het zeker, die heeft er speciale instructies voor (al moet ik bekennen dat ik niet weet wat er in dat geval over de databus gaat; dat zou in principe een read-modify-write kunnen zijn... maar dat zou het nut van de speciale instructies grotendeels om zeep helpen).

Je leest de hele byte, maskeert de waarde en schrijft dan de hele byte terug om één bit te kunnen wijzigen.

Tegenwoordig lees je, op moderne CPUs die bedoeld zijn voor computers, minstens 8 bytes (64 bits) per keer, vaak veel meer. Pak de specs van DDR-geheugen er maar eens bij.
Overigens is wat jij beschrijft (in het geval van multiprocessor of zelfs maar multithreading systemen), zonder speciale voorzorgsmaatregelen, NIET hetzelfde als het wijzigen van een bit. Standaard voorbeeld:

Proces A:
Lees geheugen (in feite: kopieer waarde uit externe geheugen naar register)
Wijzig één bit, laat de rest ongewijzigd

[task switch]

Proces B:
Lees geheugen
Wijzig één bit (een andere dan Proces A), laat de rest ongewijzigd
Schrijf geheugen

[task switch]

Proces A:
Schrijf geheugen (kopieer waarde uit register terug naar geheugen)... en overschrijf per ongeluk wat Proces B heeft gedaan: oeps!

En voordat je zegt "ja maar, dan moet die task switch precies tijdens die ene instructie plaatsvinden, dat gebeurt natuurlijk nooit". Oh inderdaad, bijna altijd gaat het goed, de keren dat het fout gaat zijn echt uiterst zeldzaam. Dat maakt het debuggen van dit soort race condities ook zo "leuk".

[Reactie gewijzigd door robvanwijk op 23 juli 2024 13:06]

[Verwijderd]

"Overigens is wat jij beschrijft (in het geval van multiprocessor of zelfs maar multithreading systemen), zonder speciale voorzorgsmaatregelen, NIET hetzelfde als het wijzigen van een bit"

In een OS is het standaard dat Proces A geen toegang heeft tot geheugenruimte van Proces B, hoe kan een task switch tijdens geheugentoegang dan een race conditie veroorzaken ?

[robvanwijk]

In een OS is het standaard dat Proces A geen toegang heeft tot geheugenruimte van Proces B, hoe kan een task switch tijdens geheugentoegang dan een race conditie veroorzaken ?

Als twee processen geheugen delen om met elkaar te kunnen communiceren. Daarnaast geldt hetzelfde verhaal als je "task switch" vervangt door "thread switch".

[Frank-L]

Jij hebt het over de cpu, scsirob over het RAM geheugen.

[Wim-Bart]

Ram wordt door cpu aangestuurd en gaat altijd per row dus afhankelijk van de row-size kan een chip worden aangestuurd.

En neem maar aan dat een row meer is dan 1 bit want dan zou je 64 memory chips moeten hebben.

Dus het is 8, 16, 32 of 64 bits lezen bit omzetten en weer terug schrijven.

[DwarV]

Ligt het aan mij, of zijn deze prestaties vergelijkbaar met een gemiddelde M.2 PCIe SSD? Het aantal IOPS is redelijk hoog, maar de lees en schrijfsnelheid niet echt. Eerlijk gezegd had ik verwacht dat het 3D Xpoint geheugen sneller zou zijn dan SLC/MLC flash.

[Barsonax]

De kracht van dit geheugen zal ook eerder bij de lage latency liggen.

En verder is er geen enkele 32GB ssd met zulke iops. Combineer ze maar tot 1TB dan heb je pas iops.

[Kubrix]

Verder is er volgens mij sowieso geen 32GB SSD, en als die er al wel is zal niemand er een willen; logisch want wat heb je daar nu aan? Je kunt er nauwelijks iets op zetten of hij zit al vol. Om nog maar te zwijgen over de 16GB versie.

[chaoscontrol]

Eindelijk phase-change geheugen op de markt. Na 20 jaar erover lullen.

[kdeboois]

De snelheden vallen idd tegen, maar het feit (correct me if I am wrong) dat er geen cel slijtage is zoals bij NAND flash (SSD,één cel 1 bit bevat op dit moment en er geen refresh nodig is zoals bij DRAM maakt het al volledig uniek. De eenvoud brengt de veelzijdigheid.

[Papillon]

Als de getoonte performance statistieken voor een single threaded IO operatie is, dan is het wel degelijk een stap voorwaarts t.o.v. SSD. Momenteel is het gissen.

Voor caching praktijken is snelheid natuurlijk ook wel van belang, maar veel meer van belang zijn de daadwerkelijke latencies van IO operaties. Bij een goede SSD liggen (synced) writes op ca 60 microsec. Reads geloof ik rond de 20 microsec. Als de Optane dit orden lager weet te krijgen is het wel degelijk een interessant produkt.

Het kan natuurlijk ook zijn dat intel marketing technisch eerst inzet op een fractie sneller dan SSD en de komende jaren vele "upogrades" in petto heeft om er flink aan te verdienen totdat het produkt technisch ten volle wordt .benut. Tijd zal het leren.