Cliff Click – CTO för Cratus (IoT-sensorer för att förbättra processer), grundare och medgrundare av flera startups (inklusive Rocket Realtime School, Neurensic och H2O.ai) med flera framgångsrika exits. Cliff skrev sin första kompilator vid 15 års ålder (Pascal för TRS Z-80)! Mest känd för sitt arbete med C2 i Java (the Sea of Nodes IR). Denna kompilator visade världen att JIT kan producera kvalitetskoden, vilket var en av faktorerna bakom Java som en av de främsta moderna programplattformarna. Därefter hjälpte Cliff Azul Systems att bygga en 864-kärnig mainframe med programvara i ren Java, som hanterade GC-pausar på 500 gigabyte heap inom 10 millisekunder. Generellt har Cliff arbetat med alla aspekter av JVM.

 
Detta huxleypost är ett stort intervju med Cliff. Vi kommer att diskutera följande ämnen:

• Övergång till lågnivåoptimeringar
• Hur man gör en omfattande omstrukturering
• Kostnadsmodell
• Utbildning i lågnivåoptimeringar
• Praktiska exempel på prestandaförbättringar
• Varför skapa ditt eget programmeringsspråk
• Karriär som prestandingenjör
• Tekniska utmaningar
• Lite om registerallokering och flerkärnighet
• Den största utmaningen i livet

Intervjuas av:

• Andrey Sataryan från Amazon Web Services. Under sin karriär har han arbetat med helt olika projekt: testat distribuerad NewSQL-databas på Yandex, ett molndetekteringssystem på Kaspersky Lab, ett flerspelarspel på Mail.ru och en valutakalkylatorstjänst på Deutsche Bank. Han är intresserad av testning av storskaliga backend- och distribuerade system.
• Vladimir Sitnikov från Netcracker. Han har arbetat i tio år med prestanda och skalbarhet i NetCracker OS – mjukvara som används av telekomoperatörer för att automatisera nätverks- och nätverksutrustningshantering. Han är intresserad av prestandafrågor relaterade till Java och Oracle Database. Författare av mer än ett dussin prestandaförbättringar i den officiella PostgreSQL JDBC-drivern.

Övergång till lågnivåoptimeringar

Andrey: Du är en välkänd person inom JIT-kompilering, Java och arbete med prestanda i allmänhet, eller hur? 

Cliff: Det stämmer!

Andrey: Låt oss börja med allmänna frågor om prestandaarbete. Vad tycker du om valet mellan hög- och låg-nivåoptimeringar som arbete på CPU-nivå?

Cliff: Det är enkelt. Den snabbaste koden är den som aldrig körs. Så det är viktigt att alltid börja på en hög nivå och arbeta med algoritmer. En bättre O-notation slår en sämre O-notation, så länge ingen stor konstant blandar sig i. Låg-nivåarbete kommer sist. Vanligtvis, om du har optimerat hela den andra stapeln tillräckligt väl, och det fortfarande finns något intressant kvar – då är det låg nivå. Men hur börjar man på hög nivå? Hur vet man att man har gjort tillräckligt arbete på hög nivå? Tja… ingen aning. Det finns inga färdiga recept. Du måste förstå problemet, bestämma vad du tänker göra (för att inte göra onödiga steg senare) och först då kan du plocka fram en profilerare som kan säga något användbart. Vid något tillfälle förstår du själv att du har blivit av med onödiga saker och det är dags att börja finjustera på låg nivå. Det är absolut en speciell typ av konst. Många gör onödiga saker, men rusar så snabbt att de inte har tid att tänka på prestanda. Men det är så länge frågan inte blir akut. Oftast är 99% av tiden ingen intresserad av vad jag gör, förrän något viktigt blockerar den kritiska vägen och någon bryr sig. Och då börjar alla ifrågasätta varför det från början inte fungerade perfekt. Det finns alltid något att förbättra i prestandan. Men 99% av tiden har du inga ledtrådar! Du försöker bara få något att fungera och under vägen inser du vad som är viktigt. Du kan aldrig veta i förväg att just den här biten måste vara perfekt, så i grunden måste du vara perfekt i allt. Och det är omöjligt och så gör du inte. Det finns alltid massor av saker att fixa – och det är helt okej.

Hur man gör en omfattande omstrukturering

Andrey: Hur arbetar du med prestanda? Det är ju ett genomgående problem. Har du till exempel varit tvungen att hantera problem som uppstår till följd av att många redan existerande funktioner korsar varandra?

Cliff: Jag försöker undvika det. Om jag vet att prestanda kommer att bli ett problem tänker jag på det innan jag börjar koda, särskilt angående datastrukturer. Men ofta upptäcker du allt detta mycket senare. Och då måste du ta till extrema åtgärder och göra det jag kallar "skriv om och härska": du måste greppa ett tillräckligt stort stycke. En del av koden måste ändå skrivas om på grund av prestandaproblem eller något annat. Oavsett orsak till att skriva om koden, är det nästan alltid bättre att skriva om ett större segment än ett mindre. I det ögonblicket börjar alla darra av rädsla: "Åh nej, vi får inte röra så mycket kod!" Men i själva verket fungerar det nästan alltid mycket bättre. Du måste ta itu med det stora problemet, rita en stor cirkel runt det och säga: allt inom cirkeln kommer jag att skriva om. Gränsen är mycket mindre än det innehåll som ska ersättas. Och om sådan gränssättning gör att arbetet inuti blir perfekt – har du fria händer, gör vad du vill. Så snart du förstår problemet går omprosesseringen mycket smidigare, så ta en stor bit!
Samtidigt, när du gör om ett stort segment och inser att prestanda kommer att bli ett problem, kan du börja oroa dig för det direkt. Vanligtvis blir det till enkla saker som "kopiera inte data, hantera data så enkelt som möjligt, gör dem mindre". Vid stora omskrivningar finns det standardmetoder för att förbättra prestanda. Och de kretsar nästan alltid kring data.

Kostnadsmodell

Andrey: I ett av podcastavsnitten pratade ni om kostnadsmodeller i samband med prestanda. Kan ni förklara vad ni menade med det?

Cliff: Självklart. Jag föddes i en tid när processorprestanda var oerhört viktigt. Och den eran återvänder – ödet är inte utan ironi. Jag började leva under tiden för åttabitarsmaskiner, min första dator fungerade med 256 byte. Just byte. Allt var väldigt litet. Man var tvungen att räkna instruktioner och så snart vi började avancera uppåt i programmeringsspråkens stack, tog språken på sig mer och mer. Det fanns assembler, sedan Basic, sedan C, och C tog hand om många detaljer, som registreringsfördelning och instruktionstypning. Men där var allt ganska tydligt och om jag gjorde en pekare till en instans av en variabel, då skulle jag få load, och kostnaden för den instruktionen är känd. Hårdvaran ger ett känt antal maskincykler, så hastigheten för att köra olika saker kan beräknas genom att helt enkelt summera alla instruktioner som du tänker köra. Varje compare/test/branch/call/load/store kunde summeras och sägas: här har du körningstiden. När du arbetar med att förbättra prestanda kommer du definitivt att notera vilka siffror som motsvarar de små heta cyklerna. 
Men så snart du växlar till Java, Python och liknande, avlägsnar du dig väldigt snabbt från lågnivåhårdvara. Vad kostar det att anropa en getter i Java? Om JIT i HotSpot gjorde allt rätt inlinat, kommer det att bli load, men om det inte gjorde det – kommer det att bli ett funktionsanrop. Eftersom anropet ligger på den heta cykeln, kommer det att avbryta alla andra optimeringar i denna cykel. Så den verkliga kostnaden kommer att vara mycket högre. Och du förlorar omedelbart förmågan att titta på en kodsnutt och förstå vad det kostar att köra den i termer av processorhastighet, använd minne och cache. Allt detta blir intressant först när du verkligen gräver ner dig i prestanda.
Just nu befinner vi oss i en situation där processorernas hastighet knappt har ökat på ett decennium. Gamla tider återvänder! Du kan inte längre räkna med bra prestanda i enkeltrådar. Men om du plötsligt ger dig in på parallella beräkningar – det är galet komplicerat, alla ser på dig som om du vore James Bond. Tio gånger snabbare prestanda uppstår vanligtvis där någon har missat något. Parallellitet kräver mycket jobb. För att uppnå den där tio gånger snabbare prestandan behöver man förstå kostnadsmodellen. Vad kostar vad? Och för att göra det måste man förstå hur språket ligger över den underliggande hårdvaran.
Martin Thompson har valt ett utmärkt ord för sin blogg Mechanical Sympathy! Man måste förstå vad hårdvaran kommer att göra, hur den kommer att göra det, och varför den överhuvudtaget gör det den gör. Genom att använda detta är det ganska enkelt att börja räkna instruktioner och ta reda på vart exekveringstiden tar vägen. Om du inte har rätt förberedelse, letar du bara efter en svart katt i ett mörkt rum. Jag ser hela tiden folk som optimerar prestanda utan att ha minsta aning om vad de egentligen gör. De kämpar hårt och kommer inte särskilt långt. Och när jag tar samma kodbit, lägger till ett par små hacks och får fem gånger eller tio gånger snabbare prestanda, säger de: tja, det är inte rättvist, vi visste ju att du var bättre. Otroligt. Vad var jag på väg att säga... kostnadsmodellen handlar om den kod du skriver och hur snabbt den i genomsnitt fungerar i det stora hela.

Andrey: Och hur innehåller man en så stor mängd information i huvudet? Det uppnås genom mycket erfarenhet, eller? Var hittar man sådan erfarenhet?

Cliff: Tja, min erfarenhet fick jag inte på ett enkelt sätt. Jag programmerade i assembler på den tiden när man kunde förstå varje enskild instruktion. Det låter kanske dumt, men sedan dess har jag i mitt minne ett för alltid bestående set av Z80-instruktioner. Jag kommer inte ihåg namnen på människor en minut efter samtalet, men jag kommer ihåg kod som skrevs för 40 år sedan. Roligt, det ser ut som ett "idiotens vetenskapsman».

Utbildning i lågnivåoptimeringar

Andrey": Finns det något enklare sätt att komma in på det?

Cliff: Ja och nej. Hårdvaran som vi alla använder har inte förändrats så mycket under denna tid. Alla använder x86, förutom smartphones som kör på Arm. Om du inte sysslar med något hardcore embedded så har du helt enkelt samma sak. Okej, vidare. Instruktionerna har inte heller förändrats på århundraden. Man måste gå och skriva något i assembler. Lite grann, men tillräckligt för att börja förstå. Ni ler, men jag säger det helt seriöst. Man behöver förstå kopplingen mellan språk och hårdvara. Efter det måste man gå och skriva lite kod och skapa en liten leksakskompilator för ett litet leksaksspråk.
Var kan man få en kostnadsmodell? Jo, man kan läsa något, självklart... Men jag tror att det bästa sättet är att agera. Göra en liten kompilator och det skulle vara det bästa sättet att förstå kostnadsmodellen och passa in den i sitt eget sinne. En liten kompilator som skulle fungera för att programmera en mikrovågsugn – det är en uppgift för nybörjare. Jag menar, om du redan har programmeringskunskaper borde det räcka. Allt detta med att parsa en sträng som kommer att vara något slags algebraiskt uttryck, hämta instruktionerna för matematiska operationer i rätt ordning, ta rätt värden från registren – allt detta går att göra ganska lätt. Och medan du gör det kommer det att etsa sig in i hjärnan. Jag tror alla vet vad en kompilator gör. Och detta ger förståelse för kostnadsmodellen.

Praktiska exempel på prestandaförbättringar

Andrey: Vad mer bör man tänka på när man arbetar med prestanda?

Cliff: Datatyper. Förresten, jag har inte hållit de här lektionerna på länge... Rocket School. Det var roligt, men det krävde så mycket energi, och jag har ju ett liv också! Nåväl. Så, på en av de stora och intressanta lektionerna, "Vart tar din prestanda vägen", gav jag studenterna ett exempel: två och ett halvt gigabyte fintech-data lästes från en CSV-fil och nästa steg var att räkna antalet sålda produkter. Vanliga tickande marknadsdata. UDP-paket, omvandlade till textformat, som började på 70-talet. Chicago Mercantile Exchange – olika saker som olja, majs, sojabönor, och liknande. Det var nödvändigt att räkna dessa produkter, antalet affärer, det genomsnittliga beloppet av rörelse av medel och varor, etc. Det är ganska enkel handelsmatematik: hitta produktkoden (detta är 1-2 tecken i en hash-tabell), få summan, lägga till den i en av affärerna, lägga till volym, lägga till kostnad, och några andra saker. Mycket enkel matematik. Den leksaksmässiga implementationen var mycket rak på sak: allt ligger i filen, jag läser filen och går igenom den, delar upp individuella poster i Java-strängar, letar efter de nödvändiga sakerna och lägger ihop enligt ovanstående matematik. Och detta fungerar med en ganska liten hastighet.

Med en sådan metod är det uppenbart vad som händer, och parallella beräkningar hjälper inte här, eller hur? Det visar sig att fem gånger ökad prestanda kan uppnås enbart genom att välja rätt datastrukturer. Detta överraskar till och med erfarna programmerare! I mitt specifika fall var fokus att man inte bör allokera minne i den heta loopen. Nåväl, det är inte hela sanningen, men i stort sett – man bör inte allokera "varje X", när X är tillräckligt stort. När X är två och en halv gigabyte, bör man inte allokera något "per bokstav", eller "per rad", eller "per fält"; inget sådant. Det är just detta som tar tid. Hur fungerar det egentligen? Föreställ dig att jag gör anropet String.split() eller BufferedReader.readLine(). Readline gör en sträng av en uppsättning bytes som kom över nätverket, en gång för varje rad, för var och en av hundratals miljoner rader. Jag tar den här strängen, analyserar den och kastar bort den. Varför kastar jag bort den – ja, jag har redan bearbetat den, det räcker. Så, för varje byte som läses från dessa 2.7G kommer två tecken att skrivas till strängen, vilket ger 5.4G, och de behövs inte längre, så de kastas bort. Om man ser på minnesbandbredden, så laddar vi 2.7G som går genom minnet och minnesbussen i processorn, och sen skickas dubbelt så mycket in i strängen som ligger i minnet, och allt detta bearbetas vid skapandet av varje ny sträng. Men jag måste läsa den, hårdvaran läser den, även om allt senare kommer att bearbetas. Och jag måste skriva den, för jag har skapat en sträng och cacheminnena är överfulla – cachen kan inte rymma 2.7G. Så, för varje läst byte läser jag två ytterligare bytes och skriver två ytterligare bytes, vilket ger ett förhållande på 4:1 – på detta sätt slösar vi bort minnesbandbredden. Och det visar sig att om jag gör String.split() – så gör jag det långt ifrån för sista gången, det kan finnas ytterligare 6-7 fält inuti. Därför leder klassisk CSV-läsning med efterföljande radparsing till förluster i minnesbandbredd på omkring 14:1 jämfört med vad man egentligen skulle vilja ha. Om man slänger bort dessa allokeringar kan man uppnå fem gånger hastighetsökning.

Och det är inte särskilt svårt. Om du ser på koden från rätt vinkel blir allt ganska enkelt, så snart du inser essensen av problemet. Du bör inte sluta allokera minne överhuvudtaget: problemet är bara att du allokerar något och det dör omedelbart, vilket bränner en viktig resurs, som i det här fallet är minnesbandbredden. Och allt detta leder till prestandafall. På x86 behöver du vanligtvis aktivt bränna processortakter, men här har du bränt all minne mycket tidigare. Lösningen är att minska antalet allokeringar. 
En annan del av problemet är att om du kör en profilerare när minnesbandbredden är slut, precis i det ögonblick det händer, förväntar du dig vanligtvis att cache-minnet ska återvända, eftersom det är fullt av skräp som du just har skapat, alla dessa strängar. Därför blir varje load eller store-operation långsam, eftersom de leder till cache-missar – hela cachen blev långsam, medan den väntade på att skräpet skulle lämna. Så profileraren kommer bara att visa ett varmt, slumpmässigt brus som är utspritt över hela cykeln – det kommer inte att finnas någon specifik het instruktion eller plats i koden. Bara brus. Och om du tittar på GC-cykler, kommer de alla att vara i Young Generation och super snabba – mikrosekunder eller millisekunder högst. För all denna minne dör omedelbart. Du allokerar miljarder gigabyte, och den skär, och skär, och skär igen. Allt detta sker mycket snabbt. Så det finns billiga GC-cykler, varmt brus över hela cykeln, men vi vill ha en 5-faldig acceleration. Vid det ögonblicket borde något klicka i huvudet och låta som: 'Varför är det så?!'. Överskridande av minnesbandbredden visas inte i en klassisk debugger, du måste köra en debugger för hårdvaruövervakning av prestanda och se det direkt och personligen. Inte direkt kan det misstänkas från dessa tre symptom. Det tredje symptomet är när du ser vad du allokerar, frågar profileraren, och den svarar: 'Du har gjort en miljard strängar, men GC har arbetat gratis'. Så fort detta inträffar, förstår du att du har skapat för många objekt och bränt hela minnesbandbredden. Det finns ett sätt att förstå detta, men det är inte uppenbart. 

Problemet ligger i datakonstruktionen: den råa strukturen bakom allt som pågår är för stor, det är 2,7G på disken, så att göra en kopia av den här saken är mycket oönskat – det är bättre att ladda den direkt från det nätverksbytebuffret till registren, så att man inte behöver läsa och skriva fram och tillbaka fem gånger. Tyvärr ger Java dig som standard inte ett sådant bibliotek i JDK. Men det är ju trivialt, eller hur? I praktiken handlar det om 5-10 rader kod som går till att implementera en egen buffrad radladdare, som upprepar beteendet hos klasssträngar, men som ändå är en omslutning kring den underliggande bytebuffern. Resultatet blir att du arbetar nästan som om du hade att göra med strängar, men i själva verket flyttas pekarna på bufferten, och råa byte kopieras ingenstans, och på så sätt återanvänds samma buffrar gång på gång, och operativsystemet är lyckligt över att hantera de saker som det är avsett för, som dold dubbel buffring av dessa bytebuffrar, och du själv maler inte längre en oändlig ström av onödiga data. Förresten, förstår ni, när man arbetar med GC garanteras det att varje minnesallokering inte kommer att synas av processorn efter den senaste GC-cykeln? Så, allt detta kan inte vara i cachen, och sen inträffar en 100%-ig garanti på en miss. När man arbetar med en pekare tar det 1-2 cykler att läsa en register från minnet i x86, och så snart detta sker, betalar du, betalar du, betalar du, för allt minne är på NIO-cache – och detta är kostnaden för minnesallokering. Den verkliga kostnaden.

Med andra ord är datastrukturer det som är svårast att ändra. Och så snart du inser att du har valt fel datastruktur, som senare kommer att påverka prestandan negativt, krävs det vanligtvis en betydande arbetsinsats för att korrigera detta. Om du inte gör det, kommer det bara att bli värre. Främst måste man tänka på datastrukturer, det är viktigt. Den största kostnaden här infaller med tunga datastrukturer, som man börjar använda med tanken "jag kopierade datastrukturen X till datastrukturen Y, för Y tilltalar mig mer estetiskt". Men kopieringsoperationen (som verkar billig) tar faktiskt upp minnesbandbredd, och här ligger allt förlorad exekveringstid. Om jag har en enorm sträng med JSON och jag vill omvandla den till ett strukturerat DOM-träd av POJO eller något liknande, så blir parsningen av den strängen och konstruktionen av POJO, och sedan nya referenser till POJO kostsamma – det är ingen billig affär. Utom när du kommer att arbeta med POJO mycket oftare än med strängen. I stället kan man överväga att avkoda strängen och dra ut det som behövs, utan att förvandla det till några POJO. Om allt detta sker i en situation där maximal prestanda krävs, är det bäst att undvika POJO – man behöver på något sätt gräva direkt i strängen.

Varför skapa ditt eget programmeringsspråk

Andrey: Du sa att för att förstå kostnadsmodellen behöver man skriva ett litet eget språk…

Cliff: Inte ett språk, utan en kompilator. Ett språk och en kompilator är olika saker. Den största skillnaden ligger i ditt eget sinne. 

Andrey: För övrigt, så vitt jag vet, experimenterar du med att skapa egna språk. Varför?

Cliff: För jag kan! Jag är delvis pensionerad, så det här är min hobby. Jag har hela mitt liv realiserat andras språk. Jag har också arbetat mycket med kodningsstil. Dessutom ser jag problem i andra språk. Jag ser att det finns bättre sätt att göra vanliga saker. Och jag skulle använda dem. Jag är bara frustrerad över att se problem hos mig själv, i Java, i Python, i vilket annat språk som helst. Just nu skriver jag i React Native, JavaScript och Elm som en hobby, som inte handlar om pensionering, utan om aktivt arbete. Och jag skriver också i Python och kommer troligtvis fortsätta arbeta med maskininlärning för Java-backends. Det finns många populära språk och alla har intressanta egenskaper. Varje språk har något unikt och man kan försöka sammanfoga alla dessa funktioner. Så jag studerar intressanta saker, språkets beteende, försöker komma på rimlig semantik. Och hittills lyckas jag! Just nu arbetar jag med minnessemantiken, för jag vill ha den som i C och Java, och få en stark minnesmodell och minnessemantik för laddningar och lagringar. Samtidigt vill jag ha automatisk typutdragning som i Haskell. Så jag försöker blanda Haskell-liknande typutdragning med minne som fungerar som i C och Java. Det är vad jag har sysslat med de senaste 2-3 månaderna, till exempel.

Andrey: Om du bygger ett språk som tar de bästa aspekterna från andra språk, har du tänkt på att någon skulle kunna göra det motsatta: ta dina idéer och använda dem i sitt sinne?

Cliff: Just så här föds nya språk! Varför liknar Java C? För att C hade en bra syntax som alla förstod, och Java inspirerades av den syntaxen, medan den lade till typ-säkerhet, gränskontroller för arrayer, GC, och de förbättrade även vissa saker från C. De lade till sina egna. Men de var ganska inspirerade, eller hur? Alla står på axlarna av jättar som kom före dig – det är så framsteg görs.

Andrey: Som jag förstår det kommer ditt språk att vara säkert när det gäller användning av minne. Har du funderat på att implementera något liknande som borrow checker från Rust? Har du tittat på det, vad tycker du om det?

Cliff: Ja, jag har programmerat i C i en evighet, med alla dessa malloc och free, och jag hanterar minneslivscykeln manuellt. Ni vet, 90-95% av den manuella hanteringen av livscykeln har samma struktur. Och det är väldigt, väldigt smärtsamt att göra detta för hand. Jag önskar att compilern bara kunde berätta vad som händer och vad jag har åstadkommit med mina handlingar. För vissa saker gör borrow checker det här direkt. Dessutom borde det automatiskt generera information, förstå allt och inte ens belasta mig med att behöva formulera den förståelsen. Det borde åtminstone göra en lokal escape-analys, och först om det misslyckas, då måste man lägga till typannoteringar som beskriver livscykeln – och en sådan schema är mycket mer komplicerad än borrow checker, eller överhuvudtaget vilken befintlig minneskontroller som helst. Valet mellan 'allt är bra' och 'jag förstod ingenting' – nej, det borde finnas något bättre. 
Som en person som har skrivit mycket kod i C anser jag att ha stöd för automatisk livscykelhantering är avgörande. Dessutom har jag tröttnat på hur mycket Java använder minne, och huvudsakligt klagomål är på GC. När minne allokeras i Java får du inte tillbaka det minne som var lokalt under den senaste GC-cykeln. I språk med mer exakt minneshantering är det inte så. Om du kallar malloc får du direkt minne som vanligtvis just har använts. Oftast gör du tillfälliga saker med minnet och returnerar det omedelbart. Och det returneras direkt till malloc-poolen, och nästa malloc-cykel drar upp det igen. Därför minskar det verkliga minnesanvändandet till de aktiva objekten vid en viss tidpunkt, plus läckor. Om du inte har läckor på ett helt oacceptabelt sätt, så lagras det mesta av minnet i cachar och processorn, och det fungerar snabbt. Men det kräver mycket manuell minneshantering med malloc och free, anropade i rätt ordning och på rätt ställen. Rust kan hantera detta korrekt själv och i många fall ge till och med bättre prestanda, eftersom minnesförbrukningen begränsas till aktuella beräkningar – till skillnad från att vänta på nästa GC-cykel som ska frigöra minne. I slutändan har vi fått ett mycket intressant sätt att förbättra prestanda. Och ganska kraftfullt – jag har arbetat med sådana saker vid databehandling för fintech, och det gjorde det möjligt att uppnå ungefär femfaldig hastighetsökning. Det är en ganska stor ökning, särskilt i en värld där processorer inte blir snabbare, medan vi fortfarande väntar på förbättringar.

Karriär som prestandingenjör

Andrey: Jag skulle också vilja fråga lite om karriären i stort. Du blev känd genom ditt arbete med JIT i HotSpot och flyttade sedan till Azul – och det är också ett JVM-företag. Men du har jobbat mer med hårdvara än mjukvara. Och sedan plötsligt bytte du till Big Data och Maskininlärning, och sedan till bedrägeridetektion. Hur kom det sig? Det är väldigt olika utvecklingsområden.

Cliff: Jag har sysslat med programmering ganska länge och har hunnit med många olika projekt. Och när folk säger: „åh, du är den som gjorde JIT för Java!“, så är det alltid roligt. Men innan dess var jag involverad i en klon av PostScript – det språket som Apple en gång använde för sina laserskrivare. Innan dess gjorde jag en implementation av språket Forth. Jag tror att ett gemensamt tema för mig är utveckling av verktyg. Jag har alltid skapat verktyg som hjälper andra att skriva sina fantastiska program. Men jag har också varit involverad i utvecklingen av operativsystem, drivrutiner, kärndebuggers, språk för operativsystem som började enkelt men med tiden blev mer och mer komplexa. Men det huvudsakliga temat är ändå verktygsutveckling. En stor del av mitt liv har ägnats åt Azul och Sun, och det handlade om Java. Men när jag började med Big Data och Maskininlärning tog jag återigen på mig min festhatt och sa: „Åh, nu har vi ett icke-trivialt problem, och här händer det verkligen massor av intressanta saker och människor som gör något.“ Det är en fantastisk väg för utveckling som är värd att gå.

Ja, jag älskar verkligen distribuerade beräkningar. Mitt första jobb var under studietiden med C, på ett reklamprojekt. Det handlade om distribuerade beräkningar på Zilog Z80-chip som samlade data för analog optisk teckenigenkänning, utförd av en riktig analog analysator. Det var ett coolt och helt galet ämne. Men det fanns problem; vissa delar kände inte igen rätt, så man var tvungen att ta fram bilden och visa den för en person som redan sett på den och rapportera vad den sa. Därför fanns det jobb med data, och dessa jobb hade sitt eget språk. Det fanns en backend som hanterade allt detta – parallella Z80:or som körde vt100-terminaler – en per person, och det fanns en modell för parallell programmering på Z80. En gemensam minnesdel som alla Z80 delade inom en stjärnkonfiguration; backplane delades och hälften av RAM delades inom nätverket, medan den andra hälften var privat eller gick till något annat. En meningsfullt komplex parallell distribuerad system med delad... halvdelad minne. När var det… Redan svårt att minnas, någon gång i mitten av 80-talet. Ganska länge sedan. 
Ja, vi kan anse att 30 år är ganska länge. Utmaningar relaterade till distribuerade beräkningar har funnits länge; människor har kämpat mot dem i åratal. Beowulf-kluster. Dessa kluster ser ut som... Till exempel: det finns Ethernet och din snabba x86 är ansluten till detta Ethernet, och nu vill du få fake shared memory, eftersom ingen kunde syssla med kodning av distribuerad beräkning då, det var för svårt, och därför fanns det fake shared memory med sidminnesskydd på x86, och om du skrev till denna sida, så sa vi till de andra processorerna att om de fick tillgång till samma shared memory, måste den laddas från dig, och på så sätt skapades något som liknar ett protokoll för cache-kohärens och mjukvara för detta. En intressant koncept. Det verkliga problemet var förstås ett annat. Allt detta fungerade, men du fick snabbt prestandaproblem, eftersom ingen förstod prestandamodellen på tillräckligt bra nivå – vilka åtkomstmönster för minnet det fanns, hur man skulle se till att noderna inte oändligt pingade varandra, och så vidare.

I H2O kom jag på följande: utvecklarna själva ansvarar för att definiera var parallellism gömmer sig och var den inte finns. Jag har kommit på en kodningsmodell som gör det enkelt och lätt att skriva högpresterande kod. Men att skriva långsam kod är svårt, den kommer att se dålig ut. Det krävs en seriös insats för att skriva långsam kod; man måste använda ovanliga metoder. Långsam kod syns vid första ögonkastet. Som en följd av detta skrivs kod som vanligtvis fungerar snabbt, men man måste ta reda på vad man ska göra vid delad minne. Allt detta är knutet till stora arrayer, och beteendet där liknar icke-volatile stora arrayer i Java parallellkörning. Tänk dig att två trådar skriver till en parallell array, en av dem vinner, och den andra förlorar, och du vet inte vem som är vem. Om de inte är volatila kan ordningen vara vad som helst – och det fungerar verkligen bra. Människor bryr sig verkligen om operationsordning; de placerar volatile korrekt och förväntar sig problem med prestanda, relaterade till minnet. Annars skulle de bara skriva kod som loopar från 1 till N, där N är några triljoner, i hopp om att alla komplexa fall automatiskt blir parallella – och det fungerar inte där. Men i H2O är det varken Java eller Scala, man kan kalla det 'Java minus minus', om man vill. Det är en väldigt lättförståelig programmeringsstil och liknar skrivandet av enkel kod i C eller Java med loopar och arrayer. Men man kan också hantera terabyte av minne. Jag använder fortfarande H2O. Ibland använder jag det i olika projekt – och det är fortfarande den snabbaste saken, tiotals gånger snabbare än konkurrenterna. Om du arbetar med Big Data med kolumnära data är det mycket svårt att överträffa H2O.

Tekniska utmaningar

Andrey: Vad har varit den största utmaningen under din karriär?

Cliff: Diskuterar vi den tekniska eller icke-tekniska delen av frågan? Jag skulle säga att de största utmaningarna är icke-tekniska. 
När det kommer till tekniska utmaningar. Jag övervann dem enkelt. Jag vet knappt vilken som var den största, men det fanns flera ganska intressanta som tog en hel del tid och mental kamp. När jag började på Sun var jag säker på att jag skulle skapa en snabb kompilator, medan en massa seniorer sa att jag aldrig skulle lyckas. Men jag fortsatte på den vägen, skrev en kompilator hela vägen till registerallokatorn, och den blev ganska snabb. Den var lika snabb som den moderna C1, men då var allokatorn mycket långsammare, och när jag ser tillbaka var det ett problem med den stora datakonstruktionen. Jag behövde den för att skriva en grafisk registerallokator och jag förstod inte dilemmat mellan kodens uttrycksfullhet och hastighet, som var relevant på den tiden och väldigt viktigt. Det visade sig att datakonstruktionen vanligtvis översteg cache-storleken på x86 från den tiden, så om jag ursprungligen antog att registerallokatorn skulle stå för 5-10 procent av den totala tid som JIT:ade, så blev det i verkligheten 50 procent.

Tiden gick, kompilatorn blev allt mer tydlig och effektiv, slutade generera avskyvärt kod i fler fall, och prestandan började allt oftare likna det som C-kompilatorn levererade. Om du förstås inte skrev skräp som ens C inte kunde optimera. Om du skrev kod som i C, fick du också prestanda som i C i fler fall. Ju längre tiden gick, desto oftare fick jag kod som asymptotiskt överensstämde med C-nivå, registerallokatorn började likna något färdigt... oavsett om din kod kördes snabbt eller långsamt. Jag fortsatte att arbeta på allokatorn så att den skulle göra bättre allokeringar. Den blev långsammare och långsammare, men levererade allt bättre prestanda i de fall där ingen annan lyckades. Jag kunde dyka ner i registerallokatorn, gräva ner en månads arbete där, och plötsligt började hela koden köra 5% snabbare. Det hände gång på gång och registerallokatorn blev som ett konstverk – alla älskade eller hatade den, och akademikerna ställde frågor som "varför görs allt på det här sättet", varför inte. linjär skanning, och vad är skillnaden. Svaret är fortfarande detsamma: en allokerare baserad på grafmålning plus mycket noggrant arbete med buffertkoden är ett vinnande verktyg, den bästa kombinationen som ingen kan besegra. Och detta är en ganska subtil sak. Allt annat som där görs av kompilatorn är ganska väldokumenterade saker, även om de också har förfinats till en konstform. Jag har alltid gjort saker som skulle omvandla kompilatorn till ett konstverk. Men inget av detta har varit extraordinärt – förutom registerallokeraren. Poängen är att man måste vara noggrann såga av under belastning, och om det händer (jag kan förklara mer om det om det är intressant) innebär det att man kan inlinera mer aggressivt, utan risk för att överskrida brytpunkten för prestandadiagrammet. På den tiden fanns det massor av fullfjädrade kompilatorer, överbelamrade med gimmickar och pryttlar, som hade registerallokerare, men ingen kunde någonsin göra det på nytt.

Problemet är att om du lägger till metoder som ska inlineas, och ökar inlineområdet, så överstiger uppsättningen av använda värden genast antalet register, och du måste börja spilla. Den kritiska nivån inträffar vanligtvis när allokatorn ger upp, och en bra kandidat för spilling är lika med en annan, och du börjar spilla riktigt vilda saker. Värdet av inlining här är att du förlorar en del overhead, overhead för anrop och bevarande; du kan se värdena inuti och du kan optimera dem vidare. Kostnaden för inlining är att det skapas ett stort antal levande värden, och om din registerallokator spillar mer än nödvändigt, förlorar du direkt. Därför har de flesta allokatorer ett problem: när inlining passerar en viss gräns börjar allt i världen att spilla, och prestandan kan svämmas bort i toaletten. De som implementerar kompilatorn lägger till vissa heuristik: till exempel, att stoppa inlining efter en viss tillräckligt stor storlek, eftersom allokeringarna förstör allt. Det skapas en böjning i prestandadiagrammet – du inlinear, inlinear, prestandan ökar långsamt – och sedan bang! – den faller ner snabbt som en domkraft, för du har inlineat för mycket. Så har det fungerat fram till Java. Java kräver mycket mer inlining, så jag var tvungen att göra min allokator mycket mer aggressiv, så att den jämnades ut istället för att falla, och om du inlinear för mycket – börjar den spillas, men sedan kommer ändå ett ögonblick där det inte finns mer spilling. Det är en intressant observation och den kom till mig helt plötsligt, inte uppenbar, men väl värd insatsen. Jag började med aggressiv inlining och det ledde mig till platser där prestandan för Java och C går hand i hand. De är faktiskt ganska lika – jag kan skriva Java-kod som är betydligt snabbare än C-kod och liknande, men i det stora hela är de ungefär jämförbara. Jag tror att en del av denna förtjänst kommer från registerallokatorn, som låter mig inlinea på ett rätt primitivt sätt. Jag inlinear helt enkelt allt jag ser. Frågan här är om allokatorn fungerar bra, och om det resulterande koden är rimligt fungerande. Det var en stor utmaning: att förstå allt detta och få det att fungera.

Lite om registerallokering och flerkärnighet

Vladimir: Problem som registreringsallokering verkar vara ett evigt ämne. Det är intressant att fråga sig om det fanns någon idé som verkade lovande men sedan misslyckades i praktiken?

Cliff: Självklart! Registreringsallokering är ett område där du försöker hitta heuristik för att lösa ett NP-fullständigt problem. Och du kommer aldrig att kunna uppnå en perfekt lösning, eller hur? Det är helt enkelt omöjligt. Tänk på Ahead of Time-kompilering – den fungerar också dåligt. Här talar vi om genomsnittliga fall. Om typisk prestanda, så du kan gå och mäta något som du anser vara bra typisk prestanda – i slutändan arbetar du ju med att förbättra den! Registreringsallokering är ett ämne helt ägnat åt prestanda. Så snart du har en första prototyp som fungerar och målar det som behöver målas, börjar arbetet med prestanda. Du måste lära dig att mäta ordentligt. Varför är detta viktigt? Om det finns tydliga data kan du titta på olika områden och se: aha, det hjälpte här, men där bröts allt ihop! Det dyker upp bra idéer, du lägger till en ny heuristik och plötsligt fungerar allt i genomsnitt lite bättre. Eller inte. Jag har haft många fall där vi kämpade för fem procent prestanda som skiljde vår utveckling från den tidigare allokatorn. Och varje gång ser det ut så här: någonstans vinner, någonstans förlorar. Om du har bra verktyg för prestandaanalys kan du hitta de förlorande idéerna och förstå varför de förlorar. Kanske är det värt att låta allt vara som det är, eller så kanske vi behöver ta ett mer seriöst grepp om finjusteringen, eller gå och fixa något annat. Det handlar om en hel uppsättning saker! Jag gjorde den här coola hack, men jag behöver också det, och det, och det – och den sammanlagda kombinationen ger vissa förbättringar. Enskilda insatser kan misslyckas. Sådan är naturen av att arbeta med prestanda för NP-fullständiga problem.

Vladimir: Det känns som om frågor som målning i allokatorer är ett redan löst problem. Tja, för er tycks det löst, baserat på vad ni berättar, så är det ens värt…

Cliff: Det är inte varken löst eller olöst. Det är du som måste göra det till "löst". Det finns tunga uppgifter och de måste lösas. När detta är gjort, kommer det dags att fokusera på prestanda. Man måste förhålla sig till detta arbete på rätt sätt – utföra benchmarktester, samla in mätvärden, förklara situationer när en rollback till en tidigare version får din gamla hack att fungera igen (eller tvärtom, sluta fungera). Och ge inte upp förrän du har uppnått något. Som jag nämnde, finns det fantastiska idéer som inte fungerade, men inom registerallokeringsområdet är idéer i princip oändliga. Man kan till exempel läsa vetenskapliga publikationer. Även om detta område nu rör sig långsammare och har blivit tydligare än på sin ungdom, arbetar en oändlig mängd människor inom detta område, och alla deras idéer är värda att pröva; alla väntar på sitt tillfälle. Och du kan inte säga hur bra de är om du inte prövar dem. Hur väl de integreras med allt annat i din allokerare, eftersom allokeraren gör många saker, och vissa idéer kommer inte att fungera i din specifika allokerare, men kanske fungerar de i en annan. Huvudstrategin för en allokerare är att ta bort långsamma sekvenser från den primära vägen och tvinga uppdelning vid gränserna för de långsamma vägarna. Därför, om du vill starta GC, följa den långsamma vägen, deoptimera, kasta undantag, allt sådant – du vet att dessa saker är relativt sällsynta. Och de är faktiskt sällsynta, jag har kollat. Du gör extra arbete och därmed försvinner många begränsningar på dessa långsamma vägar, men det spelar inte så stor roll eftersom de är långsamma och sällan används. Till exempel, en nullpekaresituation – det händer aldrig, eller hur? Du behöver ha flera vägar för olika situationer, men de ska inte kollidera på den primära vägen. 

Vladimir: Vad tycker du om flerkärniga processorer när det finns tusentals kärnor? Är det något användbart?

Cliff: Framgången för GPU:er visar att det faktiskt är ganska användbart!

Vladimir: De är ganska specialiserade. Vad sägs om allmänna processorer?

Cliff: Ja, det var affärsmodellen för Azul. Svaret kom under en tid när människor verkligen uppskattade förutsägbar prestanda. Det var ganska svårt att skriva parallellkod då. H2O-kodningsmodellen är välskalbar, men den är inte en allmän användningsmodell. Kanske något mer generell än när man använder GPU. Pratar vi om svårigheterna med att utveckla något sådant eller svårigheterna med att använda det? Till exempel, en intressant läxa som Azul lärde mig, ganska oväntad: små cachar är bra. 

Den största utmaningen i livet

Vladimir: Hur är det med icke-tekniska utmaningar?

Cliff: Den största utmaningen var att inte vara... snäll och bra mot folk. Som en följd hamnade jag ständigt i extremt konfliktfyllda situationer. I de som jag visste gick snett, men jag visste inte hur jag skulle gå vidare med att lösa dessa problem och kunde inte hantera dem. Många långvariga problem som pågått i årtionden uppkom just på det sättet. Att det finns C1- och C2-kompilatorer i Java är en direkt följd av detta. Att det inte fanns något flernivåkompilering i Java under ett decennium är också en direkt följd. Det är uppenbart att vi behövde ett sådant system, men inte uppenbart varför det inte fanns. Jag hade problem med en ingenjör... eller en grupp ingenjörer. Långt tillbaka, när jag började arbeta på Sun, var jag... Okej, inte bara då, jag har alltid min egen åsikt om allt. Och jag ansåg att jag kunde ta den här min sanningen och framföra den rakt på sak. Speciellt eftersom jag var chockerande rätt merparten av tiden. Och om du inte gillar det förhållningssättet... särskilt om du uppenbarligen har fel och gör dumheter... Ja, få människor kunde tolerera den typen av kommunikation. Men vissa kunde, till exempel jag. Jag har byggt hela mitt liv på meritoriska principer. Om du visar mig något fel, vänder jag mig genast om och säger: du sa något dumt. Givetvis ber jag om ursäkt, och allt det där, jag erkänner meriterna om det finns några, och jag gör andra korrekta handlingar. Å andra sidan har jag chockerande rätt en chockerande stor procent av tiden. Och det fungerar inte särskilt bra i relationer med människor. Jag strävar inte efter att vara trevlig, utan ställer frågan på sin spets. "Det här kommer aldrig att fungera, för att ett, två och tre." Och de säger: "Oj!". Det fanns andra konsekvenser också, som kanske är bättre att hoppa över: till exempel de som ledde till skilsmässa från min fru och ett decennium av depression efter det.

Utmaningen handlar om att kämpa mot människor och deras uppfattningar om vad du kan eller inte kan göra, vad som är viktigt och vad som inte är det. Det har funnits många utmaningar kring kodningsstil. Jag skriver fortfarande mycket kod, och under den tiden var jag tvungen att sakta ner, eftersom jag gjorde för många parallella uppgifter och gjorde dem dåligt, istället för att fokusera på en enda. När jag ser tillbaka skrev jag hälften av koden för Java JIT-teamet och C2-teamet. Nästa snabbaste kodare skrev hälften så snabbt, den efter honom ännu långsammare och det var en exponentiell nedgång. Den sjunde personen i raden var väldigt, väldigt långsam – så är det alltid! Jag har rört vid en massa kod. Jag har sett vad alla skriver, utan undantag, jag har granskat deras kod, och jag fortsatte fortfarande att skriva mer än någon av dem. Denna metod fungerar inte så bra med människor. Vissa gillar inte det. Och när de inte kan hantera det, börjar alla möjliga klagomål. Till exempel sa någon till mig en gång att jag skulle sluta skriva kod, eftersom jag skrev för mycket kod, och det hotade teamet. För mig lät allt detta som ett skämt: om hela kvarvarande teamet försvinner och jag fortsätter skriva kod, förlorar du bara hälften av teamet. Å andra sidan, om jag fortsätter skriva kod och du förlorar hälften av teamet – det låter som väldigt dålig ledarskap. Jag har aldrig tänkt särskilt mycket på det, aldrig pratat om det, men det var ändå någonstans i mitt huvud. En tanke som snurrade runt i bakhuvudet: "Är ni på riktigt?". Så den största problemen var jag och mina relationer med människor. Nu förstår jag mig själv mycket bättre, jag har länge varit teamledare för programmerare, och nu säger jag rakt ut till folk: du vet, jag är den jag är, och ni får hantera mig – är det okej om jag står här? Och när de började hantera det, började allt fungera. Jag är faktiskt varken dålig eller bra, jag har inga dåliga avsikter eller själviska strävanden, det är bara min natur, och man måste på något sätt leva med det.

Andrey: Nyligen har alla börjat prata om självmedvetenhet för introverta och om mjuka färdigheter överlag. Vad kan man säga om det?

CliffJa, det var en insikt och en läxa som jag fick ut av min skilsmässa från min fru. Det jag lärde mig av skilsmässan – är förståelsen för mig själv. Så började jag förstå andra människor. Förstå hur denna interaktion fungerar. Det ledde till insikter en efter en. Jag blev medveten om vem jag är och vad jag representerar. Vad jag gör: antingen är jag fokuserad på uppgiften, eller så undviker jag konflikt, eller något annat – och denna nivå av självkännedom hjälper verkligen till att hålla mig lugn. Efter det går allt mycket lättare. En sak som jag har upptäckt, inte bara hos mig själv utan också hos andra programmörer – är oförmågan att verbalisera tankar när man är i ett tillstånd av känslomässig stress. Till exempel, du sitter och kodar, är i ett flödesläge, och plötsligt kommer någon springande och börjar skrika i panik om att något har gått sönder, och att extrema åtgärder nu kommer att tillämpas. Och du kan inte få fram ett ord, för du befinner dig i ett tillstånd av känslomässig stress. Den förvärvade kunskapen gör att du kan förbereda dig för detta ögonblick, överleva det och gå över till en reträttplan, efter vilket du kan börja agera. Så ja, när du börjar förstå hur allt det här fungerar – är det en enorm livsförändrande händelse. 
Jag kunde själv inte hitta de rätta orden, men jag minns handlingssekvensen. Poängen är att denna reaktion är lika fysisk som verbal, och du behöver utrymme. Sådant utrymme, i zen-sinne. Det är precis detta som måste förklaras, och sedan omedelbart backa – rent fysiskt backa. När jag är tyst med ord, kan jag bearbeta situationen på en känslomässig nivå. När adrenalin når hjärnan och slår om dig till "slå eller fly"-läget, kan du inte längre säga något, nej – nu är du en idiot, en ingenjör för att bli slagen, oförmögen till ett värdigt svar eller ens för att stoppa attacken, och angriparen kan fritt attackera igen och igen. Först måste du bli dig själv igen, återfå kontrollen, och komma ut ur "slå eller fly"-läget.

Och för detta behövs ett verbalt utrymme. Bara en fri plats. Om man överhuvudtaget ska säga något, kan man just påstå detta och sedan gå ut och faktiskt hitta sitt "utrymme": ta en promenad i parken, stänga in sig i duschen – spelar ingen roll. Det viktiga är att temporärt koppla bort från situationen. Så snart du ens för en kort stund kopplar bort, kommer kontrollen tillbaka, och du börjar tänka klart. "Okej, jag är inte någon idiot, jag gör inte dumma saker, jag är en rätt så nyttig person." Så snart du har övertygat dig själv, är det dags att gå vidare till nästa steg: förstå vad som har hänt. Du blev attackerad, attacken kom från ett oväntat håll, det var en orättvis och skamlig fälla. Det är dåligt. Nästa steg är att förstå varför angriparen behövde göra det. Verkligen, varför? Kanske för att han själv är rasande? Varför är han rasande? Till exempel för att han själv har misslyckats och inte kan ta ansvar? På detta sätt behöver du noggrant bearbeta hela situationen. Men för detta behövs utrymme för manövrering, ett verbalt utrymme. Det första steget är att bryta det verbala kontakten. Gå bort från diskussionen verbalt. Avbryt det, kom bort så snabbt som möjligt. Om det är ett telefonsamtal – lägg bara på luren – detta är en färdighet jag fick från att prata med min exfru. Om samtalet inte leder till något bra, säg bara "hejdå" och lägg på. På andra sidan röret: "bla-bla-bla", du svarar: "aha, hejdå!" och lägger på. Du avbryter samtalet. Fem minuter senare, när du får tillbaka din förmåga att tänka klart, har du svalnat lite, blir det möjligt att tänka igenom vad som verkligen hände och vad som ska hända härnäst. Och börja formulera ett genomtänkt svar, istället för att bara reagera känslomässigt. För mig har det varit en genombrott i självmedvetande att inse att jag inte kan prata i situationer med känslomässig stress. Att ta sig ur detta tillstånd, tänka igenom och planera hur man ska svara och kompensera för problemen – det är de rätta stegen när man inte kan prata. Det enklaste sättet är att springa bort från situationen där den känslomässiga stressen uppstår och bara sluta delta i den stressen. Efter det återfår du förmågan att tänka, när du kan tänka, dyker möjligheten att prata upp, och så vidare.

För att vara ärlig, i domstolen försöker motpartens advokat använda detta mot dig – nu förstår du varför. För att han har möjlighet att trycka ner dig till en punkt där du inte ens kan uttala ditt eget namn, till exempel. I bokstavlig mening, kan du inte prata. Om detta händer dig och om du vet att du kommer att befinna dig på en plats där verbala strider pågår, som i en domstol, kan du ta med dig din advokat. Advokaten kommer att stå upp för dig och avbryta den verbala attacken, och han gör det helt lagenligt, och ditt förlorade zenutrymme kommer att återvända. Till exempel, jag behövde ringa min familj ett par gånger, domaren var helt vänlig, men motpartens advokat skrek och skrek på mig, jag kunde inte ens få in ett ord. I sådana fall fungerar användningen av en medlare bäst för mig. Medlaren stoppar allt detta tryck som flödar över dig från en oavbruten ström, du återfinner det nödvändiga zenutrymmet, och med det kommer förmågan att prata tillbaka. Det är ett helt kunskapsområde, där det finns mycket att lära sig, mycket att upptäcka inom sig själv, och allt detta förvandlas till högkvalitativa strategiska beslut, som är olika för olika människor. Vissa har inte de ovan beskrivna problemen, vanligtvis har de inte problem, personer som arbetar professionellt med försäljning. Alla dessa människor som lever på sina ord – kända sångare, poeter, religiösa ledare och politiker, de har alltid något att säga. De har inte dessa problem, men jag har dem.

Andrey: Det var… oväntat. Bra, vi har redan pratat mycket och det är dags att avsluta denna intervju. Vi kommer definitivt att träffas på konferensen och kan fortsätta denna dialog. Vi ses på Hydra!

Det kommer att vara möjligt att fortsätta kommunicera med Cliff på konferensen Hydra 2019, som kommer att äga rum den 11-12 juli 2019 i Sankt Petersburg. Han kommer att delta med en presentation «The Azul Hardware Transactional Memory experience». Biljetter kan köpas på den officiella sajten.

Källa: habr.com