Förra veckan meddelade Soft Machines att deras ‘VISC’-arkitektur var tillgänglig för licensiering, efter tillkännagivandet av de ursprungliga koncepten för över ett år sedan. VISC, i ett nötskal, är designad som en lösning för att förbättra antalet instruktioner per klocka en enskild tråd kan bearbeta under en given tid, vilket potentiellt gör det till en mycket intressant design i en tid där IPC-vinster är svårare och svårare att realisera.
Koncepten bakom deras nya ‘VISC’-arkitektur, som delar upp arbetsbelastningen för en enda linjär tråd över flera kärnor, är spännande och spännande. Men som med alla nya grundläggande förändringar i datorbehandling, föremål för en stor mängd frågor. Vi bjöds in till en presentation och ett samtal med VD och Chief Technical Officer Mohammed Abdallah och VP Marketing and Business Mark Casey, och jag ställde ett antal frågor på analytikers läppar till dem.
Identifiera flaskhalsar med enkel tråds prestanda
Alla diskussioner om processorprestanda under de senaste decennierna har involverat flera faktorer, inklusive att få bättre prestanda genom en ökad effektbudget, en högre frekvens, extrahera instruktionsnivåparallellism (ILP), bli bättre på att minimera förseningar genom bättre grenförutsägelse, eller lägga till fler kärnor och förbättrad trådnivåparallellism (TLP). Var och en av dessa metoder har olika grader av framgång när det gäller att öka prestandan – långtidsläsare kommer ihåg Pentium 4-dagarna när de träffade en frekvens- och kraftvägg som sedan ändrade fokus till effektivitet. Vissa uppgifter, som grafik, är till sin natur parallella och kan dra fördel av flera hundratals eller tusentals kärnor, eller så kan programvaran optimeras. Men karaktären hos de flesta programvarukoder och instruktioner är att de är entrådade av naturen, och deras prestanda beror på hur snabbt instruktionerna kan bearbetas inom en enda tråd.
Det huvudsakliga sättet att öka prestandan, eller i det här fallet instruktionerna per enhetsfrekvens (instruktioner per klocka, eller IPC), är att utöka CPU-arkitekturen så att fler kommandon kan behandlas på en gång. Att flytta från en 3-wide out-of-order-arkitektur till en 5-wide out-of-order-arkitektur möjliggör teoretiskt en 66% ökning av instruktionsgenomströmningen om (och endast om) koden är tillräckligt tät för att extrahera dessa operationer, och de andra funktionerna i arkitekturen kan säkerställa att alla operationer matas varje klockcykel.
Problemet med att flytta till en bredare arkitektur är vanligtvis kraft och designkomplexitet. Som framgår av olika chipdesigner genom åren, ju bredare arkitektur desto mer kisel måste avsättas för tillgångar som buffertar, omordningsfönster och cachning. Om det finns en kiselbudget och tillräckligt med kraftutrymme ser vi design som de sex breda Intel Skylake-kärnorna eller de sju breda NVIDIA Denver-kärnorna som kan extrahera toppprestanda när kod skrivs som matchar hårdvaran. Men den potentiella nackdelen med en bred arkitektur är att den förblir ineffektiv för uppsättningar av instruktioner som bara behöver en 2-bred eller en 3-bred arkitektur. Alternativt, om flera program eller trådar vill använda hårdvaran, är en enda kärna otillgänglig för ytterligare trådar medan den första tråden fortfarande används (även om detta kan undvikas något genom samtidig multithreading eller SMT som låter en annan tråd ha åtkomst när den första har stött på ett stall som att vänta på L1/L2-minne).
Som ett resultat inkluderar modern design också ett antal kärnor för att hantera scenariot med flera trådar/flera program. Generellt sett fungerar detta bra, speciellt med högpresterande kärnor, men det blir lite av ett problem i sig när mycket av världens hårdvara faktiskt består av många kärnor som har dålig enkelgängad prestanda. Äldre Core 2 / Conroe-system, grundläggande Bulldozer- eller ARM Cortex-A7-designer används (fortfarande) i stor utsträckning och levereras ofta med flera kärnor för att möjliggöra flera program samtidigt. Och även om de kan skala upp med ytterligare trådar till antalet kärnor de erbjuder, om någon enstaka eller lätttrådad programvara behöver mer prestanda, används de extra kärnorna inte eller är endast minimala fördelaktiga totalt sett.
Detta för oss till Soft Machines, vars VISC-arkitektur syftar till att förändra detta.
Möt VISC
Jag bör börja med att säga att trots likheterna med andra arkitektoniska namn är VISC ingen akronym. Jag frågade direkt och det är bara ett substantiv i varumärkessyfte. Människor kan tolka det som en “virtuell instruktionsuppsättning datoranvändning” eller något liknande, men företaget använder inte någon akronym på bokstäverna.
Men en virtuell instruktionsuppsättning är en bra beskrivning här. För det mesta byggdes processorarkitekturer traditionellt kring antingen CISC (komplex) eller RISC (reducerad) instruktionsuppsättningar och exekveringsmodeller, medan mer moderna konstruktioner (t.ex. Intel Core) alltmer är en mix, eller så kallad ‘CRISC’-design. Skillnaden mellan CISC och RISC beror på det faktum att enklare design kan vara mer energieffektiva, men komplexa designs kan göra mer komplicerade saker på färre cykler, samtidigt som CRISC i huvudsak möter de två paradigmen i mitten i ett försök att få fördelarna med båda, men inte utan att även ärva några av nackdelarna. VISC, i brist på en bättre beskrivning, är en RISC-design som använder en anpassad instruktionsuppsättning över ett översättningslager som gör att en enda tråd av operationer kan skickas över flera fysiska kärnor. Basdiagrammet ser ut ungefär så här:
Här är ett exempel på en VISC-design med fyra fysiska kärnor. Designen kan också hantera fyra “virtuella kärnor” eller trådar, men det som gör VISC-designen annorlunda är att när den virtuella kärnan har en tråd av instruktioner kan den använda resurserna från vilken fysisk kärna som helst. Således, om varje fysisk kärna är en 4-wide out-of-order design, om en tråd som körs på en virtuell kärna kan utnyttja resurserna för alla fyra kärnor i huvudsak gör en gigantisk 16-wide design, då under VISC kan göra det.
Detta borde omedelbart väcka ett antal frågor om ‘Vad!? Hur?! Varför?! Kraft? Frekvens? Prestanda? Effektivitet? Komplexitet?’ och liksom många andra i branschen hade vi samma frågor.
