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

Western Digital zet groot in op risc-v voor dataverwerking

Western Digital gaat zich richten op de inzet van de risc-v-architectuur voor het gebruik van producten op het gebied van dataverwerking. WD gaat sterk bijdragen aan de ontwikkeling van de architectuur en onder andere zelf risc-v-cores ontwerpen.

WD's focus op risc-v is aangekondigd door de cto van het bedrijf, Martin Fink, tijdens de Risc-v Workshop, die afgelopen week gehouden is en waar WD dit jaar een van de grote sponsoren voor was. Volgens Western Digital zorgt de flexibiliteit en openheid van de architectuur ervoor dat risc-v in te zetten is voor aan de ene kant big data en aan de andere kant fast data. De grootzakelijke markt zou in de toekomst behoefte hebben aan beide: grotere hoeveelheden data die steeds sneller verwerkt moeten worden.

Fink noemde geen specifieke WD-producten waarin de chips terecht moeten komen. De cto vertelde dat gebruikers zich wellicht niet bewust zullen zijn dat toekomstige producten een risc-v-processor bevatten, net zoals ze nu niet weten welke chips er in ssd's en usb-sticks zitten. Momenteel levert WD volgens hem al meer dan een miljard cores per jaar via zijn opslagproducten en zal dat aantal naar verwachting verdubbelen. In de komende jaren wil Western Digital apparaten, platforms en systemen met chips op basis van risc-v uitbrengen.

Risc-v is een opensource-isa die zijn oorsprong heeft bij de Computer Science Division van de University of California. Doel van het project, dat in 2010 in gang werd gezet, is om cpu-ontwerpen vrijelijk onder een bsd-licentie beschikbaar te stellen.

Door

Nieuwscoördinator

30 Linkedin Google+

Submitter: Squee

Reacties (30)

Wijzig sortering
Om deze ontwikkeling de juiste context te plaatsen moet je even naar de slides kijken. Het gaat allemaal om Storage en Compute samen te brengen.

Nu heb je aan de ene kant een HD en aan de andere kant een CPU en alle data wordt voortdurend heen en weer gestuurd. Eerst naar de CPU om te verwerken, dan terug naar de HD voor opslag, dan weer naar de CPU voor stap twee, etc..
In kleine systemen gebeurt dat nog binnen 1 kast, maar bij grotere systemen gaat dat transport via het netwerk van het ene rek naar het andere rek met apparatuur. Al die communicatie kost een hoop tijd.

Vroeger, in de tijd van de draaischijf, waren CPU's zo veel sneller dan de schijven dat je eigenlijk oneindig veel schijven op 1 CPU kon aansluiten. Toen was het niet zo'n probleem om de data heen en weer te slepen. De CPU kon het altijd allemaal zo snel verwerken als de HD het kon aanleveren.
Tegenwoordig, nu we SSD's hebben, is dat niet meer waar. Een stel moderne storage-devices kan een CPU helemaal vullen.

Het is dus tijd om het model om te veranderen. In plaats van 1 CPU met veel HDs, moeten we naar een systeem met minder HD's per CPU. Misschien wel 1 CPU met HD, of misschien wel zelfs meerdere CPU's per HD *.

Als je dan toch al een controller op je SSD hebt met flink wat rekenkracht, dan is het maar een kleine stap om het ding te upgraden naar een volwaardige CPU die bepaalde bewerkingen op het apparaat zelf kan doen.

* Wie herinnert zich nog de floppydrive van de Commodore64? De controller die daar op zit was zo snel dat programmeurs er soms voor kozen om werk door die processor te laten doen in plaats van door de hoofdprocessor.

[Reactie gewijzigd door CAPSLOCK2000 op 1 december 2017 21:45]

In het verleden heeft WD gespeelt met Ceph nodes, ik verwacht dat ze weer zoiets willen gaan doen. Voor Ceph hebt je idealiter 1HDD per CPU/node voor maximale redundancy. Gooi er een klein beetje meer cpu power en geheugen bij dan nodig is voor het storage deel en je kunt er eventueel ook een paar containers op draaien. Met wat slim programmeren moet het ook nog wel mogelijk zijn dat de containers in eerste instantie de interne hdd aanspreken voor opslag.
Waarom zou WD met ceph gaan spelen als ze zelf object storage in het portfolio hebben?
Omdat je eigen "Storage OS" onderhouden nogal wat resources vergt, Ceph een standaard oplossing aan het worden is, en Ceph (of een dergelijke oplossing) direct op een HDD zo'n beetje de natte droom is van een heleboel mensen. HDD (voor zover je dan nog van een HDD kan spreken) direct in het netwerk prikken en gaan met die banaan. :9
Nu heb je aan de ene kant een HD en aan de andere kant een CPU en alle data wordt voortdurend heen en weer gestuurd. Eerst naar de CPU om te verwerken, dan terug naar de HD voor opslag, dan weer naar de CPU voor stap twee, etc..
Wat is er met het RAM gebeurd?

HD->RAM->CPU->RAM->CPU-RAM->HD veel zinniger en doen gelukkig ook de meeste systemen.
RAM is verwaarloosbaar.
Zowel SSDs als CPU's zijn steeds sneller aan het worden. RAM niet genoeg. Daardoor wordt RAM steeds minder belangrijk. Daarbij groeit de bandbreedte naar je RAM toe ook niet voldoende om de ontwikkelingen bij te benen.
RAM werkt als een buffer voor langzame storage. Als je SSD sneller is dan je CPU heb je geen buffer nodig. Dat is nu precies het model dat wordt omgedraaid.
RAM is, behalve een simpel buffer, ook zeer betrouwbaar en een veelvoud keer te lezen/schrijven dan welk ander opslagmedium dan ook. Wat dat aangaat is RAM superieur aan bijv. SSD's en alleen dat gegeven maakt RAM nog altijd zeer belangrijk.

Je onderschat schromelijk de voordelen van RAM.
Je hebt gelijk, ik overdrijf het, het was ook meer een voorspelling voor de toekomst dan een observatie. RAM blijft z'n plek hebben maar het gaat wel minder belangrijk worden. Er blijven reden om RAM te gebruiken, maar de lage doorvoersnelheid van storage gaat verdwijnen als reden.

Aanvulling: op het moment worden computers gebouwd vanuit de gedachte dat Storage langzaam is en CPU snel. De hele architectuur is gericht op de pyramide disk -> ram -> cache -> registers -> cpu. RAM is er om te compenseren voor een langzame disk. Door RAM te gebruiken kunnen we de disk zo optimaal mogelijk inzetten. Dat gaat veranderen. RAM wordt in de toekomst wellicht gebruikt om te compenseren voor een langzame CPU!

Vaak is er een trade-off mogelijk tussen Storage en Computer. Traditioneel wordt er daarbij altijd gekozen om de workload in de richting van de CPU te schuiven. Als je een storage-operatie kan uitsparen door wat meer CPU-operaties te doen is dat eigenlijk altijd bevordelijk voor de snelheid. In de toekomst zou dat omgedraaid kunnen worden, waarbij je liever wat IOPS opoffert om je CPU maar zo efficient mogelijk te gebruiken.

Die traditionele aannames over de verhouding tussen Storage en Computer zit op talloze niveau's in onze computers verweven. Iedereen werkt vanuit die aanname, vaak zonder zelf te beseffen dat er uberhaupt een andere keuze mogelijk is. Het zal heel wat jaren duren voor iedereen tussen de oren heet dat die regels aan het veranderen zijn..

[Reactie gewijzigd door CAPSLOCK2000 op 2 december 2017 17:23]

Sorry, maar ik zie dat niet zo snel veranderen zolang SSD's achtige chips "slechts" een beperkt aantal writes aankan. Integendeel, zou ik bijna zeggen want met elke nieuwere vorm (slc > mlc> tlc: tlc-3D) zie je juist dat het aantal writes wat de chips aankan omlaag gaan. Het tegendeel wat je dus zou wensen als je het als ram-vervanger wil gaan gebruiken.

Er is dus nog genoeg werk aan de winkel, als het uberhaupt al mogelijk is. De trend is juist in de verkeerde richting, daarom deel ik jouw optimisme nog niet.
Het aantal writes per cell gaat omlaag, maar dat is alleen een probleem als je die cellen ook veel gebruikt. Als je maar genoeg cellen hebt om de load over te verdelen dan verdwijnt het probleem weer. Het maakt nogal verschil of je een paar GB RAM hebt waar al je data doorheen moet, of een paar TB SSD waar je al die acties over kan verdelen. Ik heb er nog niet aan gerekend, dus ik zeg dit vooral op gevoel.

In hedendaagse computers wordt een flink stuk van het RAM gebruikt als diskcache. Op het (vrij moderne) systeem waar ik nu op zit te werken is 2/3 van het RAM momenteel in gebruik als cache. Als m'n storage sneller wordt heb ik haast automatisch minder cache nodig.

Ten slotte zit er nog een zichzelf versterkende factor in het systeem die wegvalt.
Als je 100GB data van disk wil lezen en je hebt 1GB RAM beschikbaar, dan wordt ieder byte 100 keer overschreven (lees van disk -> schrijf naar ram -> lees uit ram -> herhaal). Als je 100GB RAM hebt dan wordt iedere byte maar 2 keer overschreven.
Als je daarna die actie nog een keer doet, dan kost het bij 1GB ram weer 100 schrijfacties per byte.
Bij 100GB RAM kost het echter 0 schrijfacties! Alles staat nog in de cache, je hoeft het alleen maar te lezen. Het totaal aantal IO-operaties (lees van disk, schrijf naar ram, lees uit ram) daalt dan plotseling enorm.

Dat is een belangrijke factor in het gesleep met data waar ik het in mijn eerste post over had. Als we data niet meer hoeven te cachen daalt het totaal aantal IO-operaties.

Nogmaals, ik heb er nog niet aan gerekend en dat zou ik eigenlijk wel moeten doen. Onze huidige computers zijn echter zo een opeenstapeling van caches en trucjes om IO sneller te krijgen dat ze de hele architectuur domineren. Een kleine verandering kan dan grote gevolgen hebben. Het stormachtige succes van SSDs laat zien hoe enorm we er op zitten te wachten. Als het zo door groeit is het een kwestie van tijd voor de veranderingen dramatisch worden.
Met RAM hoef je niet te rekenen, dat werkt altijd. RAM is er vooral om er data, wat erin staat, te bewerken, zonder ook maar één enkele schrijfactie. Dat gebeurt pas, als je een schrijf commando geeft (of als dat automatisch getriggert word).

Mijn punt is; met SSD storage cells zoals die nu bestaan, hoe snel ook, is het totaal niet verstandig om dat als RAM te gaan gebruiken. Hoe vaak je het RAM ook leest/schrijft; op RAM krijg je doorgaans levenslange garantie. Het gaat zo tientallen jaren mee. En wat doen de SSD chips? Die kunnen daar totaal niet aan tippen.

Buiten dit alles., chips die direct aan de SSD gekoppelt zijn, zijn natuurlijk geen echte "Central Processing Units, aka CPU's". Die titel is toch echt voorbehouden aan de chip in het moederbord socket. Denk dat WD dezelfde weg opgaat als Samsung: nieuws: 'Samsung ontwerpt risc-v-cpu voor internet-of-things'

Risc-V cores met een beperkt aantal transistors, alleen in dit geval specifiek gericht op data transporteren e.d.
Totaal niet vergelijkbaar met de CPU's van Intel en AMD zoals we die kennen dus.

[Reactie gewijzigd door Madrox op 3 december 2017 01:43]

Zoals het er nu voor staat zijn SSDs inderdaad nog niet geschikt om de functie van RAM over te nemen. Ik denk dat het in de toekomst steeds beter zal gaan met de betrouwbaarheid van SSD's, zelfs als de betrouwbaarheid van individuele cellen afneemt. Slijtage is jammer, maar niet noodzakelijk een probleem, het ligt er maar aan hoe snel het slijt, als het vijf jaar mee gaat is dat voor de meeste toepassing voldoende.
Daar zijn we nog lang niet, maar ik verwacht dat het vroeg of laat die kant op gaat.
Buiten dit alles., chips die direct aan de SSD gekoppelt zijn, zijn natuurlijk geen echte "Central Processing Units, aka CPU's".
<knip>
Risc-V cores met een beperkt aantal transistors, alleen in dit geval specifiek gericht op data transporteren e.d.
Totaal niet vergelijkbaar met de CPU's van Intel en AMD zoals we die kennen dus.
Dat klopt, maar dat zie ik niet als een probleem, hooguit als een beperking. Een moderne GPU is ook geoptimaliseerd voor één taak en eigenlijk niet geschikt voor andere klusjes. Die ene taak gaat echter zo vlot dat software wordt aangepast om alles op die manier te doen.

Overigens hoeft een processor niet complex te zijn om compleet te zijn. In theorie zijn ze allemaal gelijk voor wat betreft de berekeningen die ze kunnen doen, de eerste 8086 kon iedere berekening uitvoeren die een moderne i9 kan, alleen niet zo snel.

Ik zal wel even m'n best doen om niet iedere chip een CPU te noemen want dat is inderdaad een verwarrende aanduiding. De kracht van het model waar ik op stuur zit in het hebben van heel veel min of meer onafhankelijke onderdelen.

Denk aan een big-data toepassing waarbij je een HD vol data hebt en je wil het gemiddelde uitrekenen. Daarvoor moet je iedere byte 1 keer lezen en een eenvoudige berekening doen. Daar heb je geen enorme processor voor nodig. Een kleine processor in ieder storage device zou die opdracht zelfstandig kunnen afhandelen en op het einde alleen het resultaat doorsturen. Omdat het werk helemaal binnen zo'n apparaat gebeurt kan dat op volle snelheid, storage en processor kunnen helemaal op elkaar worden afgestemd.

Op grond van de slides lijkt IoT niet het hoofddoel, maar er zijn genoeg overeenkomsten met het model dat ik omschrijf. In beide gevallen werk je met relatief kleine maar onafhankelijke apparaatjes; techniek die voor de ene omgeving wordt ontwikkelt kan ook in de ander omgeving nuttig zijn.
Slijtage is jammer, maar niet noodzakelijk een probleem, het ligt er maar aan hoe snel het slijt, als het vijf jaar mee gaat is dat voor de meeste toepassing voldoende.
Daar zijn we nog lang niet, maar ik verwacht dat het vroeg of laat die kant op gaat.
Echt, ik zie niet in hoe SSD-achtige chips het werkgeheugen van je systeem gaan overnemen. Weet je wel over hoeveel read/writes naar het RAM gaan per minuut, per dag ? Ook al kunnen ze dat "spreiden" over meerdere cells, dan nog. Leg eens uit, hoe zie je dat voor je?
RAM is verwaarloosbaar.
Zowel SSDs als CPU's zijn steeds sneller aan het worden. RAM niet genoeg. Daardoor wordt RAM steeds minder belangrijk.
Dat is niet alleen jouw mening maar ook eentje die alleen van toepassing is op de huidige (en wellicht ouderwetse) computerarchitectuur. HPE kijkt hier heel anders naar en heeft een machine gebouwd (met de toepasselijke naam: The Machine) die een memory-driven architectuur heeft en waar geheugen dan ook belangrijker is dan cpu en storage. Zowel dat RISC-V als The Machine worden voor hetzelfde ingezet: grote hoeveelheden data heel snel verwerken.

Hier nog wat meer technische info: HPE The Machine reaches 160TB Using Cavium ThunderX2.

[Reactie gewijzigd door ppl op 1 december 2017 20:27]

Martin Fink is niet toevallig de man achter The Machine en achter deze Risc-V aankondiging.
En het hele latency vs throughput dan?
Als je storage maar snel genoeg is verdwijnt dat punt. RAM is een extra stap. Ergens is een punt waar het nemen van die extra stap niet meer opweegt tegen de voordelen van die stap. Met moderne SSD's zijn we hard op weg naar dat punt. Radicale nieuwe ontwikkelingen uitgezonderd is het een kwestie van tijd voor we dat punt bereiken. Voor sommige configuraties en workloads zijn we er nu al.
Ram is een extra stap. Dat geldt ook voor L1, L2 en L3 cache. En de opkomst van SSD's gaat geen van allen overbodig maken. Wat er wel gaat gebeuren is dat snelle SSDs de noodzaak van een diskcache in ram verlagen, waardoor je je ram weer gaat schalen op puur wat je nodig hebt als werkgeheugen voor programmas.
RAM is nog steeds relatief heel veel sneller dan welke opslagtechnologie dan ook. Convergence in snelheden is nog voorlopig even ver te zoeken. Intel probeert het wel met XPoint, maar dat staat echt nog in de kinderschoenen.

Sowieso moet je een hele andere architectuur gaan hanteren als het filesysteem opeens ook de het werkgeheugen is.

[Reactie gewijzigd door ocf81 op 1 december 2017 19:24]

Je hebt helemaal gelijk, maar wel een beetje relativeren m.b.t. de C64: Zo snel was die CPU in de 1540/1541 nou ook weer niet. Het was gewoon een 6502 op 1mhz. Je kon bepaalde (data gerelateerde) taken of rekenopdrachten door deze CPU laten uitvoeren als een soort van parallel cpu naast je 6510. Je had maar 2k ram om je machinetaal in te laden, dus heel gecompliceerd kon het allemaal niet zijn. Daarnaast was de snelheid van de seriebus ook niet om over naar huis te schrijven, dus 'flitsend' data en programmatuur (want die moest je eerst laden) heen en weer schrijven was het nou ook niet bepaald.
Helemaal off-topic, maar ik herinner me dat je acht 1541 drives kon stacken en dat de CPU in de drive vrijweel geheel autonoom een bron floppy disc naar de zeven overige doel discs kon schrijven.

Hoe heette die tools daarvoor ook weer?
Zelfs CPU's beginnen nu bottlenecks te worden, als je een server met 4 E7-8894V4 Xeons heb draaien raak ie bij 100Gbs netwerk verkeer van slag (wanneer je er wat mee doet dus) wanneer je geen Numa gebruikt om de boel in zones op te delen. Database / ESX idem.CPU Latency is a B*tch.
Het is niet zozeer de CPU, maar de interface van CPU naar ram. Veel systeemdesigners (met name voor gevirtualuseerde systemen) vergeten hoe weinig RAM bandbreedte elke core van een dure E7 heeft, en zeker in vergelijking met een low-end E3. Toegeven dat komt voor een groot deel doordat die E3 zn bandbreedte maar over een paar codes hoeft te delen, maar dat maakt onder de streep niet uit. Om 1000 VMs te draaien heb je een rack vol hardware nodig, en met E3s ben je meestal goedkoper uit.
Zoals je het brengt doet me dit denken aan stored procedures op de Oracle/Postgres DB. M.a.w. onder de streep oude wijn in nieuwe zakken.
Aan de ene kant waardeer ik het,

aan de andere kant lijkt het me een gevolg van de patenten-gezeur van verschillende grote partijen.

Nou hopen dat tzt WD zijn interpretaties daadwerkelijk open-source houd als het gaat aanslaan.
Gezien het aantal MCU's dat WD elk jaar in zijn HD's en SSD's stopt kan ik me voorstellen dat hun eigen RISC-V gebaseerde processor ze veel geld gaat besparen, zeker als er meerdere in stoppen.

Los daarvan ben ik ook een groot RISC-V fan omdat Intel's Management Engine al heeft laten zien dat fabrikanten van processoren gewoon niet meer te vertrouwen zijn en in het ergste geval onder één hoedje met de overheid spelen om burgers te bespioneren.

[Reactie gewijzigd door ArtGod op 2 december 2017 21:38]

Openheid staat redelijk los van de (RISC-V) ISA. Het is nl. niet zo dat het gebruik van RISC-V ervoor zorgt dat je inzage in het design hebt. (Het is geen GPL licentie.)

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

*