ML fokus skifter mod software

Nye maskinlæringsarkitekturer (ML) tiltrækker fortsat en enorm mængde opmærksomhed, da løbet fortsætter med at levere de mest effektive accelerationsarkitekturer til skyen og kanten, men opmærksomheden begynder at flytte sig fra hardwaren til softwareværktøjerne.

Det store spørgsmål er nu, om en softwareabstraktion i sidste ende vil vinde over hardwaredetaljer ved at afgøre, hvem de fremtidige vindere er.

"Maskinlæring er historisk set kommet fra et sted, hvor der var lagt vægt på specifikke slutapplikationer, såsom objektdetektion til automotive eller naturlig sprogforståelse ved hjælp af stemme," sagde Sree Harsha Angara, produktmarketingchef for IoT, computere og sikkerhed hos Infineon. "Nu er ML begyndt at forgrene sig til flere typer applikationer, som lægger mere vægt på designværktøjer og softwareramme."

Designere af maskinlæringssystemer begynder at kræve mere af maskinlæringssoftwareudviklingssættene (SDK'er), og nogle leverandører bruger deres software til at begrave hardwaredetaljerne. I sidste ende kan mindre optimal hardware med god software lykkes frem for bedre hardware med mindre software.

Vi har været her før
Compilere og andre udviklingsværktøjer har længe været taget for givet på softwaresiden. Men når det kom til hardware i de tidlige 80'ere, forventedes designere at lave deres design stort set manuelt. Selvom dette har ændret sig i dag, tog det en stenet vej at komme dertil. Og markedet for programmerbar logik var et af de første steder, hvor designsoftware gjorde en stand.

I starten tjente PLD-softwaren blot til at eliminere travlt arbejde. I de tidlige dage med programmerbare logiske enheder (PLD'er), ville ingeniører udarbejde deres logik og derefter finde ud af, hvilke forbindelser der var nødvendige i de programmerbare arrays. Disse ville bogstaveligt talt være håndskrevne i "sikringskort", som derefter kunne indtastes i programmeringsudstyr til fysisk at konfigurere en enhed.

En stor ændring skete med introduktionen af ​​programmerbar array-logik, eller PAL'er, af Monolithic Memories. To ting øgede PLD-industrien generelt. Først var en arkitektonisk ændring, der reducerede omkostningerne og øgede hastigheden. Men mere indflydelsesrigt så det den første udgivelse af en såkaldt PAL assembler, døbt PALASM.

Dette eliminerede den kedelige proces med at kortlægge forbindelserne. I stedet kunne man indtaste boolske ligninger - meget mere naturligt for ingeniører at arbejde med - og lade værktøjet finde ud af programmeringsdetaljerne. Dette var med til at skabe et seriøst vendepunkt i forretningen.

Et par år efter det dukkede nye aktører på PLD-markedet op, hvilket gav mere arkitektonisk programmerbarhed. Der har altid været logik, som sådanne enheder ikke kunne implementere, så kapløbet var i gang med at komme op med de mest fleksible arkitekturer, der stadig var hurtige og billige.

Et væsentligt vendepunkt kom, da Altera frigav sin nye arkitektur med MAX-PLUS designsoftware. Ingeniører kæmpede for at finde grænserne for, hvad den arkitektur kunne gøre, og blev positivt overrasket. Ligninger, der forventedes at mislykkes ved kompilering, virkede faktisk, fordi softwaren nu gjorde mere end blot at konvertere boolske ligninger til forbindelser. I stedet transformerede det også de boolske ligninger ved blandt andet at anvende DeMorgans teorem at konvertere ting, der ikke kunne lade sig gøre, til ting, der kunne lade sig gøre.

Dette var en game changer, og det øgede indsatsen markant for softwaresiden af ​​virksomheden. Prøv som du kunne at påpege arkitektoniske svagheder i hardwaren, så længe softwaren maskerede disse svagheder, var det et tabende argument.

Forretningen var indtil det tidspunkt blevet domineret af hardwarevirksomheder, hvor AMD var førende (har erhvervet Monolithic Memories). Men hardwarevirksomheder var ikke gode til at lave software, og de kunne ikke lide at gøre det. Så i stedet for at kæmpe med software outsourcede AMD arbejdet til et lille softwarefirma. Det viste sig at være en strategisk fejl, og virksomheden gik i sidste ende konkurs og solgte noget teknologi til AMD's nyligt udvundne Vantis-datterselskab (hvilket i sidste ende ikke var vellykket), og noget til Xilinx, der dengang var en nykommer på scenen med sin fancy FPGA'er (som var vildt succesfulde).

I sidste ende var det softwaren, der afgjorde vinderen. Hardwarefunktioner fulgte et springmønster, og værktøjerne viste sig at være differentiatoren.

"Historien er fyldt med bemærkelsesværdige FPGA-hardwarearkitekturer, som alle snublede og ikke eksisterer mere, delvist på grund af manglen på en effektiv værktøjskæde," sagde Stuart Clubb, hovedproduktchef hos Siemens EDA. "Det er lige meget, hvor god en hardwareplatform er, hvis du ikke har softwaren til effektivt og effektivt at udnytte den platform."

En parallel til maskinlæring?
I dag er alle øjne rettet mod kunstig intelligens, og virksomheder forsøger at finde den bedste arkitektur til maskinlæringsacceleratorer, der fungerer enten i skyen eller på kanten. Mens skyforekomster har domineret, kantimplementeringer - med deres hårde kraft- og omkostningskrav - har ansporet meget mere kreativitet.

Men det er blevet stadig sværere at forstå virkningen af ​​forskellene mellem disse arkitekturer. Det føles næsten, som om de store ideer er bag os, hvor virksomheder presser og trækker på forskellige parametre for at finde et sweet spot for ydeevne, kraft og omkostninger.

"Problemet, som folk løber ind i, er, at de har disse hardwareløsninger og ikke er i stand til at optimere dem eller få det udnyttelsesniveau, som de ønsker," sagde Dana McCarty, vicepræsident for salg og marketing, inferensprodukter hos Flex Logix.

Maskinlæring har altid haft et softwareelement i sig, da hele ideen med at træne og implementere en maskinlæringsløsning ikke er nogen ringe bedrift. Eksistensen af ​​tidlige maskinlæringsrammer som Caffe og TensorFlow gjorde AI-applikationer praktiske og tilgængelige for et større antal udviklere.

Alligevel er der meget arbejde involveret i at skabe et komplet design - især til kantapplikationer. Fordelagtigste givet et eksempel på brug af AI på testdata - en applikation, der for eksempel er langt mindre fremtrædende end vision.

"Vi får dette store urensede datasæt, og det vil tage flere uger at gå igennem det manuelt og anvende værktøjer manuelt," sagde Keith Schaub, vicepræsident for teknologi og strategi hos Advantest. "Du har hundredvis af funktioner, nogle gange 1,000 funktioner eller mere, og du forsøger at finde ud af de vigtigste funktioner, der korrelerer med din forudsigelse. De kommer frem til dem gennem regressionsmetoder og [hovedkomponentanalyse]. Og så har du denne statiske model med 12 funktioner."

Og det er bare funktionsteknik på højt niveau. Den næste del er at kortlægge denne model effektivt på en specifik enhed, hvor en konkurrencefordel kan opstå. "Du skal være i stand til at bygge bro over den model effektivt på din accelerator, og den virksomhed, der kan lave den brobygning, vil vinde," sagde Sam Fuller, seniordirektør for marketing hos Flex Logix.

Mens cloud-baserede motorer stort set kan stole på fuld flydende-komma-hardware, sparer megen kanthardware strøm og omkostninger ved at fokusere på heltalsimplementeringer. Det betyder at tage et design og de trænede parametre og kvantisere dem - at konvertere dem fra flydende komma til heltal. Det introducerer nogle fejl, som kan skade slutningsnøjagtigheden, så det kan være nødvendigt at genoptræne med det ønskede heltalsformat. Sigende nok er det med tiden blevet lettere at træne direkte til heltal.

At reducere størrelsen og energiforbruget af disse designs har også krævet arbejde. Man kan gå gennem designet og identificere parametre, der sandsynligvis var for små til at betyde noget, og derefter beskære dem væk. Dette var oprindeligt en manuel proces, som krævede at revurdere nøjagtigheden for at sikre, at den ikke var blevet alt for dårligt kompromitteret af beskæringsprocessen.

Så er der spørgsmålet om at tilpasse software "kerner" til den type processor, der bruges. Dette er ofte bare-metal kode skrevet for hver node i netværket. Nogle arkitekturer vælger behandlingselementer, der kun fokuserer på de almindelige instruktioner, der bruges til slutninger. Andre opretholder "fuld programmerbarhed", så de kan bruges mere fleksibelt ud over slutninger.

Og hvis du tilfældigvis har en dataflow-arkitektur, skal du muligvis partitionere hardwaren og tildele forskellige lag og noder til forskellige regioner.

Dette er blot nogle få af de ting, der skal håndteres for at implementere en fuldt funktionel maskinlæringsapplikation. Noget af det har været manuelt, men mængden af ​​softwareautomatisering er gradvist blevet skruet op.

Den næste fase: at holde hardware hemmelig
I løbet af det sidste år er en forandring blevet synlig i branchen. Ved konferencer såsom Linley Processor-konferencerne eller Hot Chips har virksomheder annonceret nye tilbud med mere diskussion af softwaren. Og især i nogle tilfælde taler de virkelig ikke om den underliggende hardware.

Det kan selvfølgelig ske på offentlige fora som konferencer. Nogle gange videregiver virksomheder kun detaljerne under NDA til legitime salgsmuligheder. Men tenoren i samtalerne ser ud til at have bevæget sig mere og mere i retning af at sige: ”Du skal ikke bekymre dig om detaljerne. Softwaren vil tage sig af det."

Det ændrer salgsdiskussioner markant fra at forsøge at overbevise en kunde om, at subtile arkitektoniske forskelle vil have meningsfulde resultater, til en, hvor designerfaring giver beviset. Kan du implementere et prøvedesign hurtigere, end du har været i stand til før? Ramper du dine mål for ydeevne - omkostninger, hastighed, kraft, nøjagtighed osv. - med minimal manuel iteration? Kan du opnå en god implementering med lidt eller ingen manuel indgriben?

Hvis svaret på alle disse er ja, betyder det så noget, hvordan hardwaren opnåede det? Hvis softwaren hurtigt kan udføre transformationer efter behov, betyder det så noget, om de underliggende porte havde en begrænsning, der krævede softwaretransformation? Hvis en anden arkitektur har langt flere klokker og fløjter, men det kræver meget mere indsats at færdiggøre et design, er disse ekstra funktioner den indsats værd?

Virksomheder, der er afhængige af deres værktøjer til at tale, satser på, at deres kunder virkelig er ligeglade med, hvad der er under motorhjelmen – så længe den, parret med god software, kan udføre det ønskede arbejde og den nødvendige hastighed, kraft, nøjagtighed og omkostninger .

Vil historien gentage sig selv med maskinlæring?
Ligesom mennesker har virksomheder en tendens til at have personligheder. Nogle er hardware-orienterede, mens andre er software-orienterede. Nogle af begge er klart påkrævet for ethvert maskinlæringstilbud, men det føles som om, at kanten kan bevæge sig mod dem med en softwareorientering. Det betyder, at man holder software foran og i centrum som en stjerne i tilbuddet, ikke som en irriterende, men nødvendig comeo walk-on. Det betyder også, at hardwaren og softwaren skal designes sammen.

Behovet for software til at buffere detaljerne er sandsynligvis større med ML, end det var med FPGA'er. Selv med værktøjer er FPGA'er designet af hardwareingeniører. ML-modeller er på den anden side designet af dataforskere, som er mange niveauer væk fra hardwaren. Så værktøjer skal bygge bro over abstraktionsgabet.

"Medmindre du taler deres sprog, har du ikke en chance," sagde Nick Ni, direktør for produktmarkedsføring for AI og software hos Xilinx. "Alle leverandører taler om TensorFlow og Python-support, fordi de ikke har nogen anden måde. Kan man lide det eller ej, man skal støtte det. Men for at understøtte så høje rammer, skal man gøre alt derimellem.”

En anden fiasko i PLD-industrien var at designe smarte arkitekturer for efterfølgende at opdage, at software var ekstremt svært at bygge til det. De mest succesrige hardware- og softwareteams arbejdede sammen, og hardwaren blev justeret efter behov for at muliggøre glatte og kraftfulde softwarealgoritmer.

Fig. 1: Udviklingen af ​​designværktøjer, begyndende med manuelle designs og fremskridt gennem eliminering af kedelighed, faktisk evne til at manipulere designs og til sidst at optimere dem. Med sidstnævnte stadier er co-design af hardware/software afgørende for succes. Kilde: Bryon Moyer/Semiconductor Engineering

Dette vil også være sandt for maskinlæring. Hvis et smart hardwaretrick er svært at udnytte i software, vil det sandsynligvis aldrig blive brugt. I sidste ende vil de mest succesrige tilbud sandsynligvis være arkitekturer, der parrer godt med deres værktøjer, og som har fjernet alle funktioner, der ikke kan bruges effektivt af værktøjerne.

"En af virksomhedens grundlæggende præmisser er, at softwarens behov skal drive design af hardwaren," sagde Quadric.io CTO Nigel Drago på sidste efterårs Linley Processor Conference.

På samme konference nævnte Ravi Setty, senior vicepræsident for Roviero, softwarens rolle i at definere virksomhedens arkitektur. "Vi har tilføjet måske 5% kompleksitet i hardwaren for at opnå noget i retning af 90% enkelhed i compileren. Hardwaren er rent agnostisk over for enhver af de neurale netoplysninger. Det er compileren, der har al viden. Og hardwaren – det er bare en udførelsesmotor.”

Selvom værktøjernes rolle vokser, er vi stadig ikke ved det punkt, hvor de begraver hardwaren fuldstændigt. Der er stadig en rig blanding af arkitektonisk udforskning, der endnu ikke har lagt sig. Som med mange designautomatiseringsbaner er vi på vej ind i verden, hvor mange designs vil kunne udføres automatisk, med håndtweaking, der er nødvendig for at få mest muligt ud af hardwaren.

På dette stadium af markedet er der også en spænding mellem mere generaliserede arkitekturer med softwareabstraktion og specialbyggede arkitekturer. "Mens en hardwareløsning til generelle formål, der er softwaredrevet, kan tilbyde større fleksibilitet, taber sådanne løsninger ofte til specialiseret hardware, når en bestemt dimension (areal, effekt, hastighed, omkostninger) er af større betydning," bemærkede Siemens EDA's Clubb.

Dette kan skabe en udfordring for software rettet mod specialiseret hardware. "Hver arkitektur har unikke fordele og er optimeret til specifikke use cases," forklarede Anoop Saha, senior manager, strategi og vækst hos Siemens EDA. "Men udfordringen for brugeren er stadig - hvordan kan de kompilere deres netværk på en bestemt hardwarearkitektur? Og hvis de er i stand til at gøre det, hvordan kan de så optimere det til netop den hardware og udnytte de forskellige tilgængelige komponenter? De hardwarespecifikke optimeringer og fleksibilitet skal håndteres af software på en mere automatisk måde."

Regler værktøjer?
I sidste ende føles det altså som om, at de langsigtede hardwarevindere vil være dem, der giver den bedste designoplevelse, med kun nok hardware eksponeret til at hjælpe udviklere med deres designbeslutninger. Det er bestemt den måde, FPGA'er fungerer på i dag. Faktisk er der i nogle tilfælde ting, som FPGA-hardwaren teoretisk kan gøre, som softwaren ikke tillader.

ML ser ud til at følge en lignende vej. "Innovationer inden for hardware, der giver betydelige fordele i kraft og hastighed, pakker sig ind under en fælles softwareramme eller API," sagde Infineons Angara. "Det betyder, at de giver betydelige gevinster ved at køre ML uden smerten ved 'usofistikeret' software."

Det er stadig uvist, om ingeniører holder op med at tænke på hardwaren. "Kan ML 'kompilatorer' være smarte nok til at målrette generiske hardwareplatforme til det punkt, hvor hardwaren ikke rigtig betyder noget? Sandsynligvis ikke,” sagde Clubb. “ML hardwarespecialisering har helt sikkert fordele og ulemper ved at låse fleksibiliteten og omprogrammerbarheden af ​​løsningen. Opfindsomme arkitekter og hardwaredesignere vil altid skulle udvikle mere effektive løsninger, når den generelle løsning ikke opfylder applikationens behov."

Skalering og størstedelen af ​​markedet kan dog påvirke dette. Da syntese var nyt, var der mange ingeniører, der troede, at de altid kunne gøre et bedre stykke arbejde end et værktøj. Det kunne have været rigtigt, men det blev upraktisk, efterhånden som designs blev skaleret, produktivitetsforventningerne steg, og værktøjerne blev forbedret.

Så selvom hardware altid vil betyde noget til en vis grad, ser det ud som om på lang sigt, ligesom det var med programmerbar logik, softwareværktøjer ofte kunne ende med at blive kongemageren.

Kilde: https://semiengineering.com/ml-focus-shifting-toward-software/