Soft Machines presenteert VISC-processor

De Californische nieuwkomer op processorgebied Soft Machines brengt zijn eerste VISC-processor op de markt. Naast de VISC-cpu met de naam Shasta, toonde het bedrijf ook een schaalbare soc Mojave. Beide producten moeten in 2016 op de markt komen.

De soc en cpu werden woensdag gepresenteerd op de Linley Processor-conferentie. De VISC-cpu's worden gebouwd rond 'virtuele cores' en 'virtuele hardware-threads'. Een middleware-laag vertaalt de applicaties van het besturingssysteem naar de eigen instructieset van VISC. Vervolgens worden de taken dan weer verder verdeeld over de virtuele cores van de cpu, met als bijzonderheid dat het ook zware single threaded-taken op een virtuele core kan verdelen over verschillende hardware-cores.

De 64-bit-chip wordt gebakken op 16nm en draait op 2GHz met 1MB L2-cache per core. De virtuele softwarelaag kan verschillende instructiesets vertalen, zoals x86 en ARM. Maar de cpu is ook aan te spreken met native VISC-code, die nog efficiënter is.

Bij de introductie van VISC in oktober 2014 stelde de ceo van het bedrijf Mahesh Lingareddy dat hij gelooft dat met 'VISC een derde golf van computerarchitectuur ingeluid wordt'. Het bedrijf bestaat wat dat betreft ook al meer dan acht jaar. Het kwam vorig jaar pas naar buiten toen het een werkend prototype van een VISC-cpu had; deze draaide op 500MHz. De VISC-architectuur moet het mogelijk maken drie tot vier keer meer instructies per cycle te halen, waardoor de prestaties per watt twee tot vier keer hoger moeten zijn bij zowel single- als multithreaded processen.

Soft Machines ontwikkelde de processors niet alleen. Onder de investeerders in het bedrijf zijn bijvoorbeeld AMD en Samsung Ventures te vinden. Het bedrijf hengelde al meer dan 175 miljoen dollar aan investeringen binnen.

Reacties (41)

[Orthodroom]

Begrijp ik het goed dat hier een soort van ingebouwde virtualisatielaag inzit?

[M-en-M]

In mijn ogen lijkt het een beetje op Intel's huidige (x86) CISC implementatie en HyperThreading: er is een decoder die complexe instructies vertaalt naar simpele instructies (uops) en deze vervolgens verdeelt tussen de beschikbare RISC units, welke architectureel simpel/vergelijkbaar genoeg zijn om op te spitsen in meerdere virtuele threads.

Het grote verschil is dat Intel een hardware decoder heeft, maar Soft Machines het volledig op software laat draaien en bovendien geen onderscheid maakt tussen verschillende hardware cores. (Ook is het bij Intel niet mogelijk om de interne RISC instructies aan te spreken, het moet altijd via de decoder.)

[atlaste]

Zo las ik het ook. Overigens niet helemaal correct, Intel gebruikt voor complexere Cisc opcodes microcode, die ze ook via firmware updaten. Dat is eigenlijk gewoon een soort software middel-layer.

That said...

Ik heb er nog eens over nagedacht en geconcludeerd dat ik het niet begrijp...

Allereerst: [multi-core virtualisatie] Een CPU is normaal meer dan alleen een core; hij bevat ook registers en (L1/L2) cache. Dat laatste is een belangrijk gegeven, want dat maakt het snel -- maar tegelijkertijd ook lastiger om dingen te parallelliseren. Simpel uitgelegd, als je een read of een write doet naar memory. hoeft dat niet te betekenen dat dit ook echt naar memory gaat -- het kan gewoon in je cache blijven, wat sneller is, maar als probleem heeft dat een andere thread de data niet observeert. Registers geldt ongeveer hetzelfde voor als voor L1/L2 cache. Dit los je normaliter op via synchronizatie, memory fences, etc.

De architectuur doet me vermoeden dat ze Ofwel de cache delen tussen de cores, Ofwel gewoon geen cache hebben. Dat eerste is een issue omdat dit caching een multi-core probleem maakt (daar heb je synchronizatie oid voor nodig en dat is relatief langzaam); het tweede is eigenlijk vanwege performance niet een serieuze optie...

Het rare is dat sommige plaatjes laten zien dat ze L1 cache per-core hebben en de cores de L2 cache delen. Dat betekent dat auto-parallelisatie in veel gevallen de data in L2 cache moet schrijven en synchronizatie nodig is. Dat is wel heel spannend, ik heb werkelijk geen idee hoe je dit qua performance snel gaat houden... uiteindelijk zijn instructies afhankelijk van elkaar, wat zou betekenen dat de code de snelheid van je L2 cache gaat overnemen. M.i. is dat niet snel genoeg.

Ten tweede: [single-core virtualisatie] Opcodes omschrijven naar fysieke VISC opcodes moet dan wel echt jantjesnel gaan. Dat klinkt eenvoudig, maar is echt een enorme prestatie. Stel je voor dat je een 2 GHz CPU wilt emuleren. Throughput is niet echt een probleem; latency wel (de tijd die het kost voordat je de instructie uit kan voeren). Stel dat je een opcode vertaalt naar 3 opcodes, dit kost je dan al snel 3 clock cycles -- als je dat net zo snel wilt doen als op een intel waar de instructie een latency heeft van 1 cycle - heb je dus een 6 GHz CPU opcode rewriter nodig.

Nu kan je hier wel truuks uithalen, zoals meerdere rewriters die in parallel de instructies weghalen. Dat geeft sowieso weer problemen op het multi-core probleem, maar daarnaast verplaatst het alleen het probleem naar de CPU zelf.

Ten derde: Hoe zouden ze omgaan met vectorizatie? Je kan natuurlijk een AVX2 32-bit Add instructie omschrijven naar 8 32-bit Add instructies -- maar daarmee gaat het (ondanks dat de architectuur dan flexibeler is) wel een stukje langzamer. Analoog aan eerste punt geeft vectorizatie over meerdere CPU's weer synchronizatieproblemen.

Kortom, ik zou ook wel graag iets meer details hebben. En ben serieus wel geinteresseerd in welke performance ze hiermee halen tov. een Intel CPU. Specifiek ben ik wel nieuwsgierig naar instructie latency/bandwidth en performance voor cache-intensieve applicaties.

[Reactie gewijzigd door atlaste op 26 juli 2024 01:40]

[Toettoetdaan]

Hier is meer uitleg: http://semiaccurate.com/2...isc-architecture-details/

[atlaste]

Dank je voor de link. Ik begin het beter te begrijpen. Ik ga het proberen simpel uit te leggen...

Multi-core tasks:

Basically wat ze doen is de L1 cache op een bijzondere manier sharen en L2 cache sharen. L3 cache hebben ze niet. De bijzondere manier van sharen houdt in dat ze (waarschijnlijk 64-bits aan) data kunnen delen in iets minder dan 1 kloktick.

When tasks are split across cores it adds a cycle to the scheduling and execution portions of the processor but that seems like a small price to pay especially if it is only intermittently needed.

Dat betekent dat je deze grap kunt uithalen:

-> worload: add, add, add
-> core 1: add & share, yield, add
-> core 2: yield, add&share.

(voor het gemak zijn fetch & store weggehaald).

Kortom, als synchronizatie mechanisme kunnen ze yields (wacht 1 kloktick) gebruiken omdat ze weten dat een cache-sync minder dan 1 kloktick duurt. Dit is leuk, omdat je nu de 'yields' kan invullen met andere instructies die ook 1 kloktick duren -- en daarvan gaat het harder. Deze grap werkt omdat de verschillende cores allemaal dezelfde klok gebruiken.

Ik verwacht dat de microcode als gevolg allemaal instructies heeft van 1 kloktick; dat scheduled gewoon makkelijk (en het is prima om complexe instructies om te schrijven; AMD en Intel doen dat ook al jaren via microcode).

Next up is a question of scaling, how high can things go for core counts? Soft Machines says that the Shasta architecture can go to 4/8 cores, basically double what they have now, without taking a latency hit.

4 cores klinkt logisch, omdat je de L1 cache zo kan positioneren dat de cores op gelijke afstand zitten (en dan werkt het bovenstaande mechanisme). Bij meer cores verwacht ik een flinke latency hit -- want dan moet je alsnog via L2 cache. Basically krijg je dan deze situatie (die ik ook beschrijf in de eerdere reactie):

The best they could do is get the data from a shared L2 or L3 which would both pollute the L1s and/or slow things down to the point where any gains from splitting the task would be lost and then some.

Single-core tasks:

Ook hier geeft het artikel een antwoord op:

Occasionally this software will need to do something more complex but the bulk of the work is basically a big lookup table. [...] They don’t emulate code, they just translate it to the native ISA, a 32-bit add is a 32-bit add on both native and emulated hardware, but probably have differing opcodes.

Basically is dit wat de standaard translation table in je processor ook doet. Een instructie levert N andere "RISC" instructies op die door de processor worden afgehandeld. Dat is meestal een 1:1 vertaling, maar kan ook iets lastigers zijn (zoals bijv. bij DIV).

Het enige verschil is dat je dit ding kan programmeren, analoog aan microcode firmware upgrades. Kortom, het is mogelijk de processor on-par te krijgen met "normale" Intel processoren, mits de microcode genoeg instructies aankan.

Voorzichtige conclusie:

De grootste innovatie van VISC is het L1 cache sharing mechanisme, wat kan worden gebruikt om synchronizatie problemen tussen processoren op te lossen. Dat geeft nieuwe mogelijkheden met hyperpipelining, wat je hiermee kan schalen van 2 threads naar 4 (zij claimen 4/8 als max) -- en dat is precies waar ze reclame mee maken. Nice, hebben ze goed verzonnen.

Dat je er meerdere instructiesets op kan draaien zie ik niet heel erg het nut van in voor consumenten of bedrijven. Dit zie ik vooral een middel om "interface completeness" en "patches" te kunnen ondersteunen -- wat het een nuttige feature maakt voor bedrijven als Intel/AMD en adoptie makkelijker maakt.

[robvanwijk]

In mijn ogen lijkt het een beetje op Intel's huidige (x86) CISC implementatie en HyperThreading

Disclaimer: ik heb erg weinig informatie om op af te gaan; het zit er dik in dat op zijn minst enkele details fout zijn. Heeft iemand een link naar een fatsoenlijke uitleg over hoe VISC precies werkt...!?

Het doet mij juist meer denken aan een Bulldozer module, om precies te zijn, hoe de FPU gedeeld wordt tussen twee cores (in tegenstelling tot de ALUs, die elk specifiek bij één core horen).

Het klinkt alsof deze nieuwe processor een (enorm??) aantal ALUs, FPUs, etc. heeft, die elk gebruikt kunnen worden door meerdere (alle??) cores. Dit zou verklaren waarom single-threaded performance beter is; die kan worden uitgevoerd door een core met de beschikking over veel meer functional units dan je normaal gesproken in een enkele core zou stoppen. Van een "core" blijft dan, denk ik, niks anders over dan de register files...?

[NLsandman]

http://www.softmachines.c...MI_Dual_SW_Threads-04.png

Plaatje laat zien hoe het werkt.

Door de virtualisatie laag kunnen ze bv bij single thread van 2 cores 1 virtuele maken met 6 virtuele hardware threads

[necessaryevil]

Met HyperThreading doet één core meerdere taken tegelijk. Wat in het artikel beschreven wordt is andersom: één taak wordt over meerdere cores verdeeld.

[Damic]

Blijkbaar wel, alles lijkt virtueel te zijn kwa machine code.

[blorf]

Volgens mij wel maar op een heel laag niveau. Ik denk dat het bij deze technologie erom gaat om met software op hardware-level de prestatie van hetzelfde maar dan in fysieke hardware te bereiken, wat CPU's in een keer erg flexibel en aanzienlijk minder complex zou maken. Ze kunnen een deel van zichzelf virtualiseren wat dus niet fysiek aanwezig hoeft te zijn.

[gekkie]

Klinkt als transmeta ?

[svenvv2]

Bijna

Uit de link van Fartman:
"This may remind you of Transmeta, whose Code Morphing Engine translated x86 ops into a VLIW-compatible structure that the CPU could execute, but Soft Machines stresses that VISC is actually the opposite approach. Instead of an incredibly complex and difficult translation engine that relies on software execution, the work of extracting ILP and scheduling the code to run across hardware is done on-chip."

[field33P]

Is dat niet wat zowel Intel als AMD doen sinds de Pentium/K5?

[MSalters]

Bija goed, de Pentium is nog een native x86 ontwerp. De AMD K5 was de eerste x86-naar-RISC CPU. Overigens was de Pentium wel de eerste CPU met parallele Execution Engines binnen 1 core. U en V pipelines, als ik het me goed herinner. Dat vereiste dus ook al een instruction scheduler.

Het is natuurlijk vrij vanzelfsprekend dat je geen grote doorbraken kunt verwachten van zo'n klein team in een veld waar al zo lang door zoveel mensen aan is gewerkt. Een instruction rewriter in hardware in plaats van software i(zoals Transmeta) s geen bijzonder creatief idee. Misschien zit die creativiteit wel in de uitwerking, maar dat kunnen we nog niet zeggen op basis van dit artikel.

Overigens is die "incredibly complex and difficult translation engine that relies on software execution" juist een argument vóór software. Dat soort complexiteit in hardware kan best pijnlijk zijn; denk aan de FDIV bug in de Pentium hardware.

[Quetensky]

Wat is VISC?

http://www.extremetech.co...ugh-weve-been-waiting-for

[letatcest]

Zie ook de tweede link in het artikel zelf ;-)

[beerse]

VISC: Variable Instruction Set Computing. Het bericht hier boven heeft de term niet uitgeschreven staan maar heeft het wel veelvuldig over virtueel, dat zette mij op het verkeerde been, de V is van Variable, niet van Virtueel.

[Reactie gewijzigd door beerse op 26 juli 2024 01:40]

[Harry_Sack]

Het is wel interessant, je hebt geen cross-compiler nodig, schijnbaar. Is het voor industriële toepassingen, telefoons, thin clients?

[leuk_he]

Aangezien het prototype veel instucties pee clock draait, maar op relatief langzame clocksnelheid, komen als eerste mobiele toepassingen in zicht.

[SuperDre]

Is zie daar niet zo het nut van hoor.. Liever nog steeds gewoon native gecompileerd dan via zo'n emulatielaag.. een applicatie is toch altijd geschreven voor een bepaald OS, en dat OS draait OF op de 1ne instructie set OF of op de andere, en als het op meerdere kan draaien, dan zie ik toch het liefst dat bij installatie de applicatie gecompileerd/geoptimaliseerd wordt voor de betreffende instructieset waar het OS op dat moment op draait..

[Taghorn]

Weet je compile time de load van je app en de load van de andere apps op het target platform? Dat kan alleen het OS/Hardware RUN time bepalen. Het idee is dat die taak van load balancing runtime geregeld word voor je, zonder dat je als programmeur erover hoeft na te denken.
Voor de applicatie richtingen die ze noemen (telefoons, machine hardware, etc) is de energie-prestatie verhouding van belang en het draaien van meerdere apps (ok, kies wel de juiste applicaties, maar een meet en regelsysteem dient bijvoorbeeld het e.a. tegelijk te doen en aub weinig stroom te kosten).

Voor je Desktop waarop 1 spelletje vol gas alle performance mag opslurpen klopt je argument trouwens volledig. Optimaliseren en eigenlijk al het andere weg drukken.

[Singular1ty]

Ik vraag me af hoe snel we dan apparatuur op basis van deze chip voor consumenten zullen zien! Een compleet nieuwe speler op de processormarkt is toch best interessant, het is bepaald geen breed bezaaid veld.

[dragnar12]

Onder de investeerders in het bedrijf zit bijvoorbeeld AMD
(AMD, Samsung and Globalfoundries Invest in a Brand New CPU Architecture For The Next Era of Computing
Soft Machines has already accumulated over $125 million in funding. Leading investors are Samsung Ventures, AMD and Mubadala, the Abu Dhabi owned parent company of AMD’s ex-manufacturing arm Globalfoundries.
)

denk dat amd er zelf wel iets in ziet

[Reactie gewijzigd door dragnar12 op 26 juli 2024 01:40]

[RoyK]

Hoe moet ik dit nu zien vs een bekende intel CPU als een i5 of een i7? Zijn dit dan processors die door de hoeveelheid per cycle sneller zijn dan de gevestigde orde?

[leuk_he]

Nog niet. Het draait nu in prototype op 350 mhz. Wel meerdere ipc. Vergelijkbaar met een liw end telefoon. Het punt us dat ze beweren nog veel ruimte te hebben.

[JDTeunis]

Toch wel gaaf die virtualisatie, straks draaien we virtuele machines (bijv. Java Virtual Machine) op virtuele servers (VPS) die weer op virtuele cores draaien. Steeds verder dan de fysieke hardware af naar abstractere systemen, komt waarschijnlijk het programmeergemak wel ten goede.

[Reactie gewijzigd door JDTeunis op 26 juli 2024 01:40]

[Vale vista]

Idd, talen als C# (en in mindere mate Java) zijn super voor n programmeur qua gemak, zeker mbt tot multithreading enz. maar het is zo jammer dat je geen manueel geheugen management kan doen wanneer je dat nou net nodig hebt.

[Reactie gewijzigd door Vale vista op 26 juli 2024 01:40]

[o_f_course]

niets weerhoud je om C, C++ oid te gebruiken op het moment dat je dat nodig hebt en dat te integreren in je .NET programma, toch?

[Vale vista]

Ware het niet de marshalling costs waardoor het zeker on het geval waarvoor ik het gebruikte, noet remdabel meer is te doen door de overhead.

[o_f_course]

yep, idd, dan moet je iets meer daarin doen om zo min mogelijk te laten marshallen. bytheway: je kunt met pointers etc werken in unsafe unmanaged code, zoals ocf81 ook al zei: https://msdn.microsoft.com/nl-nl/library/y31yhkeb.aspx

Zo zijn we ook een stuk software aan het omzetten van een oude niet-.net taal naar .NET. op ten duur faseren we het waarschijnlijk uit en stappen over op .NET FW classes, wetende dat we aantal procenten verliezen, maar wel een veel grotere community erbij hebben.

[ocf81]

*kuch* unmanaged code *kuch*

[ro8in]

Ik vind dit wel intressant. Zo kan je gewoon je normale dingen draaien en toch gebruik maken van de betere visc architectuur. Ik ben erg benieuwd naar die beestje!

[Marctraider]

Houdt dit in dat single threaded apps die nu gelimiteerd zijn aan IPC x Clockspeed wordt weggenomen?

[Icelus]

Tijd terug over gelezen en benieuwd naar de IPC die gehaald zou worden.
Ze claimen 2,1 IPC bij twee cores (Apple A7 = 1,0 en Haswell = 1,39 bij één core).

http://3.f.ix.de/imgs/18/...VISC-1cd3e93794d870c0.png
http://www.heise.de/newst...re-Prozessor-2435023.html