For to år siden begynte et lite team hos Google å gjøre Swift til det første ordinære språket med globale programmeringsmuligheter og integrert med språk. Omfanget av prosjektet og dets første resultater har vært bemerkelsesverdig, og den generelle brukervennligheten er ikke for langt unna.

Imidlertid har prosjektet ikke generert stor interesse for maskinlæringssamfunnet og er ukjent for de fleste utøvere. Dette er delvis på grunn av språkvalget, som har blitt møtt med overveldende forvirring og likegyldighet gitt at Swift nesten ikke eksisterer i datavitenskapens økosystem og primært ble brukt til å lage iOS-apper.

Dessverre viser til og med et kortvarig blikk på Google-prosjektet at det er en massiv og ambisiøs innsats som Swift kan etablere som en stor aktør i regionen. Selv om vi hovedsakelig jobber med Python på Tryolabs, syntes vi å velge Swift var en utmerket idé, og vi bestemte oss for å skrive dette korte innlegget ™ for å få en ide om Googles planer.

Før vi dykker inn i Swift, men forstår hva begrepet differensial programmering egentlig betyr, la oss først gjennomgå den nåværende situasjonen.

Hva er galt med deg, Python?!

Python er det mest brukte maskinlæringsspråket, og det er mange maskinlæringsbiblioteker og verktøy skrevet i Google. Så hvorfor Swift? Hva er galt med Python? For å være veldig klar, er Python treg. Python egner seg heller ikke til parallellisme. For å omgå disse fakta, kjører de fleste maskinlæringsprosjekter sine beregningsintensive algoritmer gjennom biblioteker skrevet på C / C ++ / Fortran / CUDA-språket og bruker Python til å lime de forskjellige lavnivåprosessene sammen. For det meste har dette vært veldig vellykket, men som med alle abstrakte ideer, kan det oppstå problemer. La oss se gjennom noen av disse.

Eksterne binære filer

Å ringe eksterne binærfiler for beregningskrevende operasjoner begrenser utviklere til å jobbe på en liten del av algoritmens overflate. For eksempel er det ikke tillatt å skrive en tilpasset måte å implementere omgåelsen med mindre utvikleren er villig til å bytte til et språk som C. De fleste programmerere velger mot det fordi de ikke har erfaring med å skrive høy ytelse og lavt nivå kode, eller fordi de bytter mellom et Python-utviklingsmiljø og et språknivå på lavt nivå blir for tungvint til å være garantert.

Dette fører til den uheldige situasjonen der programmerere er motivert til å skrive minst mulig kompleks kode og påkalle eksterne biblioteksoperasjoner som standard. Dette er det motsatte av det som er ønskelig i et dynamisk område som maskinlæring, hvor mye fortsatt er uklart og det er presserende behov for nye ideer.

Hastighet

Bruk av Python + Fast-biblioteker kan i noen tilfeller være treg. Ja, for CNN-er som vurderer bilder, er det veldig raskt å bruke Python og PyTorch / TensorFlow. I tillegg er det lite sannsynlig at koding av hele nettverket ditt i CUDA vil oppnå mye ytelse, siden mesteparten av slutningstiden blir brukt på store konvolusjoner som allerede er laget i godt optimaliserte implementeringer. Dette er imidlertid ikke alltid scenariet.

Nettverk sammensatt av mange små operasjoner er ofte mer sårbare for ytelsesforringelse hvis de ikke implementeres helt på enkelt språk. I et blogginnlegg som erklærer sin kjærlighet for å bruke Swift for dyp læring, rapporterer Jeremy Howard fra Fast.AI at til tross for at han bruker PyTorchs store JIT-kompilator, gjør den fremdeles ikke et spesifikt RNN så raskt som det kan i en ren CUDA.

I tillegg er Python ikke et veldig godt språk for situasjoner der ventetid er viktig eller for svært lave oppgaver som å kommunisere med sensorer. Noen selskaper velger å omgå dette ved først å utvikle modellene sine i PyTorch / TensorFlow Python.