- Володар цілих двох. Перша - за роботу з (Brown University) і друга, свіжіша, - (Virginia Tech University). Премію Дейкстри дають за роботи, значущість та вплив яких були помітні протягом щонайменше десяти років і, очевидно, Моріс — один із найвідоміших фахівців в області. На даний момент він працює професором у Браунівському університеті та має безліч досягнень на цілий абзац завдовжки. Зараз він займається дослідженнями блокчейну у контексті класичних розподілених обчислень.
Раніше Моріс вже приїжджав до Росії на SPTCC () і зробив чудову зустріч спільноти Java-розробників JUG.ru в Пітері ().
Цей хабрапост – велике інтерв'ю з Морісом Херліхи. У ньому обговорюються такі теми:
- Взаємодія академічної сфери та промисловості;
- Фундамент для досліджень блокчейну;
- Звідки беруться проривні ідеї. Вплив популярності;
- PhD під керівництвом Барбари Лисков;
- Світ чекаючи багатоядерності;
- Новий світ – нові проблеми. NVM, NUMA та злом архітектури;
- Компілятори проти процесорів, RISC vs CISC, shared memory vs message passing;
- Мистецтво написання тендітного багатопоточного коду;
- Як навчити студентів написання складного багатопотокового коду;
- Нове видання книги The Art of Multiprocessor Programming;
- Як винаходила транзакційна пам'ять;
- Чому варто проводити дослідження у галузі розподілених обчислень;
- Чи зупинився розвиток алгоритмів і як жити далі;
- Робота у Браунівському Університеті;
- Різниця між дослідженнями в університеті та всередині корпорації;
- Hydra та SPTDC.
Інтерв'ю ведуть:
Віталій Аксьонов — на даний момент пост-док в IST Austria та співробітник кафедри «Комп'ютерні Технології» Університету ІТМО. Займається дослідженнями у сфері теорії та практики конкурентних структур даних. До роботи в IST, він отримав PhD в Університеті Париж Дідро та в Університеті ІТМО під керівництвом професора Петра Кузнєцова.
Олексій Федоров — продюсер JUG Ru Group, російської компанії, яка займається організацією конференцій для розробників. Олексій брав участь у підготовці більш ніж 50 конференцій, а в його резюме є все що завгодно, починаючи від позиції інженера-розробника Oracle (JCK, Java Platform Group), і закінчуючи позицією деврела в компанії Однокласники.
Володимир Ситніков - Інженер в компанії Netcracker. Десять років працює над продуктивністю та масштабованістю NetCracker OS - ПЗ, що використовується операторами зв'язку для автоматизації процесів управління мережею та мережевим обладнанням. Захоплюється питаннями продуктивності Java та Oracle Database. Автор понад десяток покращень продуктивності в офіційному PostgreSQL JDBC-драйвері.
Взаємодія академічної сфери та індустрії
Олексій: Моріс, ви дуже довго працювали в академічному середовищі, і перше питання полягає у взаємодії між академічною та індустріальною сферами. Чи не могли б ви розповісти, як змінилися взаємодії між ними останнім часом? Що було 20-30 років тому і що відбувається зараз?
Моріс: Я завжди намагався тісно співпрацювати з комерційними компаніями, бо мають цікаві завдання. Вони, як правило, не дуже зацікавлені ні в публікації отриманих результатів, ні докладних поясненнях своїх проблем світової громадськості. Вони лише зацікавлені у вирішенні цих проблем. Я деякий час працював у таких компаніях. Я провів п'ять років, працюючи повний робочий день у дослідницькій лабораторії Digital Equipment Corporation, яка раніше була великою комп'ютерною компанією. Я працював один день на тиждень у Sun, у Microsoft, у Oracle, трохи працював у Facebook. Зараз я збираюся вирушити у творчу відпустку (sabbatical leave, професору в американському університеті дозволяється десь раз на шість років брати таку відпустку на рік) і попрацювати в , це така криптовалютна компанія у Бостоні. Працювати в тісному зв'язку з компаніями завжди було приємно, тому що саме так ви дізнаєтесь про нові та цікаві речі. Ви можете бути взагалі першою або другою людиною, яка опублікувала статтю на обрану тему, замість того, щоб займатися поступовим поліпшенням розв'язків задач, над якими і так працюють усі інші.
Олексій: Чи можете детальніше розповісти, як це відбувається?
Моріс: Звісно. Знаєте, коли я працював у корпорації Digital Equipment Corporation, я та Елліот Мосс, ми винайшли транзакційну пам'ять. Це був дуже плідний період, коли всі почали цікавитись інформаційними технологіями. Паралелізмом зокрема, хоча багатоядерні системи ще існували. За часів Sun та Oracle я багато працював над паралельними структурами даних. У Facebook я займався їхнім блокчейн-проектом, про який я не можу говорити, але сподіваюся, він скоро стане публічним. Наступного року, в Algorand, я буду працювати в дослідній групі, вивчаючи смарт-контракти.
Олексій: Останні кілька років блокчейн став дуже популярною темою. Чи допоможе це вашим дослідженням? Можливо, полегшить отримання грантів чи надасть доступ до ресурсів компаній, які працюють в індустрії?
Моріс: Я вже одержав невеликий грант від Ethereum Foundation. Популярність блокчейну дуже корисна для того, щоб надихати студентів на роботу в цій галузі. Вони дуже цікавляться цим і раді взяти участь, але іноді не розуміють, що дослідження, які привабливо звучать зовні, виявляється, включають справді важку роботу. Тим не менш, я дуже радий використати всю цю містику навколо блокчейну, це допомагає залучати студентів.
Але це ще не все. Я перебуваю в консультативній раді кількох блокчейн-стартапів. Деякі з них можуть досягти успіху, деякі з них, можливо, ні, але завжди дуже цікаво бачити їхні ідеї, вивчати їх і консультувати людей. Найцікавіше – коли ви попереджаєте людей не робити щось. Багато чого спочатку здається гарною ідеєю, але чи це так насправді?
Фундамент для досліджень блокчейну
Віталій: Дехто думає, що за блокчейном та його алгоритмами майбутнє. А інші люди кажуть, що це просто чергова бульбашка. Можете поділитися своєю думкою щодо цього?
Моріс: Багато що з того, що відбувається у світі блокчейнів працює неправильно, щось просто шахрайство, багато що переоцінено. Проте я думаю, що для цих досліджень є солідна наукова база. Той факт, що світ блокчейнів сповнений ідеологічних розбіжностей, показує рівень хвилювання та відданості справі. З іншого боку, це особливо вигідно для наукових досліджень. Зараз, якщо ви публікуєте статтю, в якій йдеться про недоліки конкретного алгоритму, отримана реакція не завжди є повною мірою науковою. Найчастіше люди вихлюпують свої емоції. Думаю, що подібний ажіотаж у цій галузі декому може здатися привабливим, але врешті-решт тут є і реальні наукові та інженерні питання, якими тільки належить зайнятися. Тут багато Computer Science.
Віталій: Тобто ви намагаєтеся закласти фундамент для досліджень блокчейну, вірно?
Моріс: Я намагаюся закласти фундамент для жорсткої, науково та математично обґрунтованої дисципліни. І частково проблема в тому, що іноді доводиться суперечити деяким зайво різким позиціям інших людей, ігнорувати їх. Іноді люди запитують, чому я працюю в області, в якій зацікавлені лише терористи та наркоторговці. Така реакція так само безглузда, як і поведінка послідовників, які сліпо повторюють твої слова. Думаю, що істина десь посередині. Блокчейн ще вплине на суспільство і світову економіку. Але, мабуть, це станеться не завдяки сучасним технологіям. Сучасні технології розвиватимуться і те, що в майбутньому називатиметься блокчейном, стане дуже важливим. Можливо, воно навіть не виглядатиме як сучасні блокчейни, це відкрите питання.
Якщо люди будуть винаходити нові технології, вони продовжуватимуть називати це блокчейном. Я маю на увазі, так само, як сьогодні Fortran не має ніякого відношення до мови Fortran з 1960-х років, але всі продовжують називати це Fortran. Те саме для UNIX. Те, що називається блокчейн, ще зробить свою революцію. Але я сумніваюся, що цей новий блокчейн стане схожим на те, що всім так подобається використовувати сьогодні.
Звідки беруться проривні ідеї. Вплив популярності
Олексій: Чи привела популярність блокчейну до нових результатів з наукового погляду? Більше взаємодії, більше студентів, більше компаній у галузі. Чи вже є якісь результати цього зростання популярності?
Моріс: Я зацікавився цим, коли хтось вручив мені офіційну листівку компанії, яка щойно зібрала чимало грошей. У ній писали про , з якою я більш ніж знайомий. Написане у листівці було явно технічно неправильне. Люди, які все це написали, не дуже розуміли модель, що лежить за проблемою… і все ж ця компанія зібрала багато грошей. Згодом компанія непомітно підмінила цю листівку набагато правильнішим варіантом – і я не скажу, як називалася ця компанія. Вони все ще існують і справи у них дуже добре. Цей випадок переконав мене, що, по-перше, блокчейн це просто форма розподілених обчислень. По-друге, поріг входу (принаймні тоді, років чотири тому) був досить низьким. Люди, які працюють у цій галузі, були дуже енергійними та розумними, але наукових праць не читали. Вони намагалися винайти відомі речі і зробили це неправильно. Сьогодні драма зменшилась.
Олексій: Це дуже цікаво, бо кілька років тому ми мали іншу тенденцію. Це трохи схоже на фронтенд-розробку, коли розробники браузерних інтерфейсів винаходили цілі технології, які на той час вже були популярні в бекенді: системи складання, безперервну інтеграцію і таке інше.
Моріс: Згоден. Але це не дивно, адже по-справжньому проривні ідеї завжди приходять ззовні суспільства, що склалося. Визнані дослідники, особливо авторитети в академічному середовищі, навряд чи зроблять щось справді проривне. Легко написати для наступної конференції доповідь про те, як ви трохи покращили результати своїх попередніх робіт. Сходіть на конференцію, зберіться з друзями, поговоріть про все те саме. А люди, що вриваються із проривними ідеями, майже завжди приходять ззовні. Вони не знають правил, не знають мови, але тим не менш… Якщо ж ви всередині спільноти, що сформувалася, раджу звертати увагу на нові речі, на щось, що не вкладається в загальну картину. У певному сенсі можна спробувати об'єднати зовнішні, більш рухливі розробки з методами, які ми вже розуміємо. Як перший крок, спробуйте створити наукову базу, а потім змініть її так, щоб її можна було застосовувати до нових проривних ідей. Думаю, що блокчейн добре підходить на роль нової проривної ідеї.
Олексій: Як вважаєте, чому так відбувається? Тому що люди «зовні» не мають якихось специфічних бар'єрів, властивих спільноті?
Моріс: Тут простежується якась схема. Якщо почитаєте історію імпресіоністів у живописі та мистецтві взагалі, то свого часу відомі художники відкидали імпресіонізм. Вони казали, що це якесь дитинство. Покоління, цей раніше відкинутий вид мистецтва став стандартом. Що я бачу у своїй галузі: винахідники блокчейну не були зацікавлені у владі, у накручуванні публікацій та індексу цитованості вони просто хотіли зробити щось хороше. І ось вони сіли і почали це робити. Їм не вистачало певної технічної глибини, але це можна виправити. Набагато складніше придумати нові творчі ідеї, ніж виправляти та посилювати недостатньо зрілі. Завдяки цим винахідникам мені тепер є чим зайнятися!
Олексій: Це схоже на різницю між стартапами та легасі-проектами. У спадок нам переходить безліч обмежень мислення, бар'єрів, спеціальних вимог тощо.
Моріс: Хороша аналогія – розподілені обчислення. Подумайте про блокчейн як би він був стартапом, а розподілені обчислення - великою усталеною компанією. Розподілені обчислення знаходяться в процесі купівлі та злиття з блокчейном.
PhD під керівництвом Барбари Лисков
Віталій: У нас ще багато запитань! Ми вивчали вашу біографію і натрапили на цікавий факт про ваш докторський ступінь. Так, це було давно, але тема, здається, важлива. Ви отримали PhD під керівництвом самої ! Барбара дуже відома у співтоваристві розробників мов програмування, і взагалі дуже відома особистість. Логічно, що ваші дослідження були у галузі мов програмування. Як ви перейшли на паралельні обчислення? Чому ви вирішили змінити тему?
Моріс: На той час Барбара та її група якраз поглядали на розподілені обчислення, це було дуже новою ідеєю. Були й ті, хто говорив, що розподілені обчислення – нісенітниця, спілкування комп'ютерів між собою безглуздо. Одне з питань, що розглядаються в розподілених обчисленнях, що відрізняє їх від централізованих обчислень - відмовостійкість. Після тривалих досліджень ми вирішили, що в мові програмування для розподілених обчислень потрібно мати щось на зразок атомарних транзакцій, тому що ніколи не можна бути впевненим у успішності віддаленого виклику. Як тільки ви з'явилися транзакції, виникає проблема управління паралелізмом. Потім було багато роботи з одержання високопаралельних трансакційних структур даних. Потім, коли я здобув вищу освіту, я пішов у та почав шукати тему для роботи. Мені спало на думку, що обчислення перейшли від окремих комп'ютерів до мереж комп'ютерів. Природним продовженням прогресу стали б мультипроцесори – слово багатоядерний тоді ще не існувало. Я подумав: який еквівалент атомарним транзакціям для багатоядерної системи? Точно не звичайні транзакції, бо вони надто великі та важкі. І ось так я прийшов до ідеї і саме так я вигадав всю wait-free синхронізацію. Це була спроба відповісти на питання, що є аналогом атомарних транзакцій для багатопроцесорної системи із загальною пам'яттю. На перший погляд, ця робота може виглядати зовсім по-іншому, але насправді це продовження тієї самої теми.
Світ чекаючи багатоядерності
Віталій: Ви згадали, що на той час було зовсім небагато багатоядерних комп'ютерів, га?
Моріс: Їх просто не було. Було кілька так званих симетричних мультипроцесорів, які переважно були підключені до однієї і тієї ж шині. Це не дуже добре працювало, тому що щоразу, коли нова компанія створювала щось подібне, Intel випускала один-єдиний процесор, який перевершував мультипроцесор.
Олексій: Чи це не означає, що в ті давні часи, це було швидше теоретичне дослідження?
Моріс: Це було не теоретичне, а скоріше умоглядне дослідження. Все це було не про роботу з безліччю теорем, швидше ми висували гіпотези про неіснуючу на той момент архітектуру. Саме для цього потрібні дослідження! Жодна компанія не зробила б такого, все це було чимось із далекого майбутнього. Насправді так було до 2004 року, коли з'явилися реальні багатоядерні процесори. Через те, що процесори перегріваються можна зробити процесор ще менше, але не можна зробити швидше. Через це відбувся перехід на багатоядерну архітектуру. І тоді це означало, що раптово з'явилося застосування всім концепцій, які ми розробили у минулому.
Олексій: Як ви вважаєте, чому багатоядерні процесори з'явилися лише у двохтисячних? То чому так пізно?
Моріс: Це з апаратними обмеженнями. Intel, AMD та інші компанії дуже хороші у підвищенні швидкості процесора. Коли рано чи пізно процесори стали досить маленькими і вони більше не могли збільшувати тактову частоту, тому що процесори почали б згоряти. Можна зробити їх менше, але не швидше. Що в їх силах – замість дуже маленького процесора, помістити вісім, шістнадцять чи тридцять два процесори у той самий об'єм корпусу, де раніше містився лише один. Тепер у вас багатопоточність та швидка комунікація між ними, тому що вони спільно використовують кеші. Але ви не можете змусити їх працювати швидше – цілком конкретне обмеження швидкості. Їх продовжують потроху покращувати, але вже не так сильно. На шляху покращень стали закони фізики.
Новий світ – нові проблеми. NUMA, NVM та злом архітектури
Олексій: Звучить дуже розумно. Із новими багатоядерними процесорами прийшли нові проблеми. Чи очікували ви та ваші колеги цих проблем? Може, ви вивчали їх заздалегідь? У теоретичних дослідженнях часто не дуже легко передбачати такі речі. Коли проблеми все ж таки трапилися – наскільки вони відповідали вашим очікуванням та очікуванням ваших колег? Чи вони були абсолютно новими, і ви з колегами повинні були витрачати багато часу на вирішення проблем у міру їхньої появи?
Віталій: Додам до питання Олексія: чи правильно ви спрогнозували архітектуру процесорів, поки що займалися теорією?
Моріс: Не всі 100%. Але я думаю, що ми з колегами добре попрацювали, прогнозуючи багатоядерність із загальною пам'яттю. Думаю, ми правильно передбачили складнощі в розробці паралельних структур даних, що працюють без блокувань. Такі структури даних були важливими для багатьох програм, хоч і не для всіх, але часто вам дійсно потрібна структура даних без блокування. Коли ми винаходили їх, багато хто стверджував, що це нісенітниця, що і з блокуваннями все відмінно працює. Ми досить добре передбачали, що з'являться готові рішення для багатьох проблем програмування та структур даних. Існували і складніші проблеми, такі як - Нерівномірний доступ до пам'яті. Насправді вони навіть не розглядалися до винаходу багатоядерних процесорів, оскільки були занадто специфічні. Дослідницька спільнота працювала над питаннями, які були загалом передбачувані. Деяким апаратним проблемам, пов'язаним із конкретними архітектурами, довелося почекати свого часу – власне, появи цих архітектур. Наприклад, ніхто особливо не працював над структурами даних, специфічними для GPU, тому що тоді GPU не існувало. Незважаючи на те, велика робота була зроблена над Ці алгоритми були готові до застосування відразу ж, як з'явилося відповідне залізо. Проте передбачити все неможливо.
Олексій: Якщо я правильно розумію, NUMA є своєрідним компромісом між вартістю, продуктивністю та деякими іншими речами. Чи є ідеї, чому NUMA з'явилася так пізно?
Моріс: Думаю, що NUMA існує завдяки проблемам із залізом, що використовується для виробництва пам'яті: чим далі знаходяться компоненти, тим повільніше доступ до них. З іншого боку, друга цінність цієї абстракції – рівномірність пам'яті. Тому однією з характеристик паралельних обчислень і те, що це абстракції злегка зламані. Якби доступ був ідеально рівномірним, вся пам'ять була б рівновіддаленою, але це економічно, а може навіть фізично неможливо. Тому виникає цей конфлікт. Якщо ви пишете свою програму так, ніби пам'ять була рівномірною, то швидше за все, вона буде коректною. У тому сенсі, що вона не видаватиме неправильних відповідей. Але й продуктивність у неї зірок із неба не схопить. Так само, якщо ви пишете без розуміння ієрархії кешів, саме блокування буде коректним, але про продуктивність можна забути. В якомусь сенсі, ви повинні писати програми, що живуть поверх дуже простої абстракції, але ви повинні перехитрити людей, які цю абстракцію вам надали: ви зобов'язані знати, що під абстракцією лежить ієрархія пам'яті, що є шина між вами і цією пам'яттю, і так далі. Таким чином, існує якийсь конфлікт між корисними поодинці абстракціями, що призводить до дуже конкретних і прагматичних проблем.
Віталій: Що щодо майбутнього? Чи можна передбачити, як процесори будуть розвиватися далі? Є ідея, що однією з відповідей є транзакційна пам'ять. Мабуть, у вас є ще щось у запасі.
Моріс: Попереду є кілька основних проблем. Одна з них полягає в тому, що когерентна пам'ять – чудова абстракція, але вона починає ламатися у спеціальних випадках. Так, наприклад, NUMA є живим прикладом чогось, де можна продовжувати вдавати, що існує рівномірна пам'ять. Насправді ні, продуктивність змусить вас заплакати. У якийсь момент архітекторам доведеться відмовитися від ідеї про єдину архітектуру пам'яті, не можна прикидатися вічно. Знадобляться нові моделі програмування, досить прості у використанні і досить потужні, щоб обладнання, що нижче лежить, було ефективним. Це дуже складний компроміс, адже якщо ви покажете програмістам ту архітектуру, яка насправді використовується в залозі, вони збожеволіють. Це дуже складно і не переноситься. Якщо ж ви представите занадто простий інтерфейс, продуктивність буде поганою. Таким чином, потрібно досягти безліч дуже непростих компромісів, необхідних для забезпечення корисних моделей програмування, застосовних до справді великих багатоядерних процесорів. Я не впевнений, що хтось, крім вузького фахівця, здатний програмувати на 2000-ядерному комп'ютері. І якщо ви не робите дуже спеціалізовані чи наукові обчислення, криптографію чи щось таке – все ще зовсім не зрозуміло, як це правильно робити.
Іншим подібним напрямом є спеціалізовані архітектури. Графічні прискорювачі існують вже давно, але вже стали своєрідним класичним прикладом того, як можна взяти спеціалізований тип обчислень і запустити їх на виділеному чіпі. Це додає власні проблеми: як ви спілкуєтеся з таким пристроєм, як ви його програмуєте. Я нещодавно працював над завданнями в області . Ви берете невеликий процесор і приклеюєте його до величезного шматка пам'яті, тому пам'ять працює на швидкості L1-кешу, а потім відбувається зв'язок з пристроєм на зразок – процесор займається завантаженням нових завдань у ваше ядро пам'яті. Розробка структур даних та протоколів зв'язку для такого роду речей – ще один цікавий приклад. Таким чином, спеціалізовані процесори та апаратне забезпечення будуть піддаватися покращенням протягом досить довгого часу.
Олексій: Що щодо енергонезалежної пам'яті ()?
Моріс: О, це ще один чудовий приклад! NVM дуже змінить наш погляд на такі речі, як, наприклад, структури даних. Енергонезалежна пам'ять, у певному сенсі, обіцяє справді все прискорити. Але воно не зробить життя простіше, тому що більшість процесорів, кеші та регістри все ще енергозалежні. Коли ви починаєте роботу після збою, ваш стан і стан вашої пам'яті не буде точно тими ж, що були до збою. Я дуже вдячний людям, які займаються NVM - довгий час дослідникам буде чим зайнятися, намагаючись з'ясувати умови коректності. Обчислення коректні, якщо можуть пережити збій, у якому загубився вміст кешів і регістрів, але основна пам'ять залишилася незмінною.
Компілятори проти процесорів, RISC vs CISC, shared memory vs message passing
Володимир: Що ви думаєте про проблему «компілятори проти процесорів» з точки зору набору команд? Поясню для тих, хто не в темі: якщо ми перейдемо до нерівномірної пам'яті або чогось подібного, ми могли б застосувати дуже простий набір команд і попросити компілятор згенерувати складний код, здатний використовувати переваги, що відкрилися. Або ми можемо піти іншим шляхом: реалізувати складні інструкції та попросити процесор переупорядкувати інструкції та проводити з ними інші маніпуляції. Що ви думаєте про це?
Моріс: У мене справді немає відповіді на це запитання. Ця дискусія продовжується протягом чотирьох десятиліть. Був час, коли між набором команд та набором команд велися громадянські війни. Якийсь час вигравали RISC-ові люди, але потім Intel перебудували свої движки так, щоб усередині використовувався скорочений набір інструкцій, а назовні експортувався повний. Напевно, це та тема, в якій кожне нове покоління має знайти власні компроміси та ухвалити власні рішення. Дуже важко передбачити, яка з цих речей виявиться кращою. Тому будь-яке передбачення, яке я зроблю, буде вірним протягом певного часу, а потім якийсь час знову стане хибним, а потім знову вірним.
Олексій: Наскільки взагалі для галузі звичайної є така ситуація, що деякі ідеї виграють упродовж кількох десятиліть та програють у наступних? Чи є інші приклади таких періодичних змін?
Моріс: У темі розподілених обчислень є люди, які вірять у і люди, які вірять у . Спочатку у розподілених обчисленнях паралельні обчислення означають передачу повідомлень. Потім хтось виявив, що з пам'яттю, що розділяється, програмувати куди простіше. Протилежна сторона заявила, що пам'ять, що розділяється, - штука занадто складна, тому що там потрібні блокування тощо, тому варто перейти на мови, де нічого крім передачі повідомлень просто не існує. Хтось подивився, що з цього вийшло і каже: «ого, ця реалізація обміну повідомленнями виглядають дуже схоже на пам'ять, що розділяється, тому що ви створюєте багато-багато цих маленьких модулів, вони відправляють повідомлення один одному, і всі вони , - давайте краще зробимо базу даних з пам'яттю, що розділяється! ». Все це повторюється знову і знову, і неможливо сказати, що одна із сторін однозначно має рацію. Одна зі сторін завжди домінуватиме, тому що, як тільки одна з них майже перемагає, люди знову і знову винаходять способи покращити протилежну.
Мистецтво написання тендітного багатопоточного коду
Олексій: Це дуже цікаво. Наприклад, коли ми пишемо код, неважливо якою мовою програмування, зазвичай доводиться створювати абстракції на кшталт осередків, які можна читати і писати. Але насправді, на якомусь фізичному рівні це може виглядати як відправлення повідомлення апаратною шиною між різними комп'ютерами та іншими пристроями. Виходить, відбувається робота одразу на обох рівнях абстракції.
Моріс: Абсолютно вірно, що пам'ять, що розділяється, побудована на передачі повідомлень - шини, кеші і так далі. Але з використанням передачі повідомлень важко писати програми, тому залізо навмисно бреше, вдаючи, що у вас є якась рівномірна пам'ять. Так вам буде простіше писати прості коректні програми, доки продуктивність не почне падати. Тоді ви скажете: схоже, настав час потоваришувати з кешем. І ось тоді ви починаєте турбуватися про місцезнаходження кешу, і далі пішло-поїхало. У певному сенсі ви зламуєте абстракцію: ви знаєте, це не просто плоска рівномірна пам'ять і збираєтеся скористатися цими знаннями для написання дружніх програм до кешу. Це те, що доведеться робити у реальних завданнях. Цей конфлікт між милою простою приємною абстракцією, яку вам видали, та жахливо складною реалізацією нижчого заліза – це те, де кожен піде на власний компроміс. У мене є книга про мультипроцесори та синхронізацію, і одного разу я збирався написати розділ про структури даних у java.util.concurrent. Якщо ви подивитеся на них, на речі на зразок – це дивовижні витвори мистецтва. (Примітка редакції: тим, хто знайомий з мовою Java, варто хоч раз поглянути на реалізацію ConcurrentSkipListMap, за посиланнями можна подивитися на и ). Але на мій погляд, було б безвідповідально показувати їх студентам, адже така структура даних свого роду хлопець у цирку, що біжить канатом над ведмежою ямою. Якщо ви зміните хоч одну маленьку деталь, звалиться вся конструкція. Цей код дуже швидкий та елегантний лише тому, що він ідеально написаний, але найменша зміна призведе до повного провалу. Якщо я поставлю цей код як приклад студентам, вони одразу скажуть: я теж можу так робити! І тоді якийсь літак упаде або ядерний реактор вибухне, і я винен у тому, що не вчасно надав їм занадто багато інформації.
Олексій: Коли я був трохи молодшим, то багато разів я намагався вивчати вихідний код Дага Лі, наприклад, java.util.concurrentадже це відкритий вихідний код, його дуже легко знайти і спробувати зрозуміти, що там відбувається. Виходило не дуже: часто, зовсім неясно, чому Даг вирішив щось зробити саме таким чином, коли всі інші роблять інакше. Як ви пояснюєте своїм студентам такі речі? Чи особливий правильний спосіб описувати конкретні деталі хардкорного алгоритму, наприклад? Як вам це вдається?
Моріс: У викладачів малюнка є кліше, яке вони згадують насамперед: якщо ви хочете малювати, як Пікассо, потрібно спочатку навчитися малювати прості реалістичні картинки, і лише коли ви знаєте правила, можна починати їх порушувати. Якщо одразу розпочати з порушення правил, вийде безлад. Спершу я навчаю студентів як писати простий коректний код, не переймаючись продуктивністю. Я говорю: тут ховаються складні проблеми синхронізації, тому не турбуйтеся про кеші, не турбуйтеся про моделі пам'яті, просто переконайтеся, що все правильно працює. Це вже досить складно: сучасне програмування непросте саме собою, особливо нових студентів. І ось коли у них з'являється інтуїція про те, як писати правильні програми, я кажу: подивіться на ці дві реалізації спинлока: одна дуже повільна, а друга теж не дуже, але вже краще. Тим не менш, математично ці два алгоритми збігаються. Насправді, один із них використовує локальність кешу. Один з них крутиться на локально кешованих даних, а інший здійснює багаторазово операції, що йдуть через шину. Не можна написати ефективний код, якщо ви не розумієте його суті, не знаєте, як порушити абстракцію та подивитися на структуру, що знаходиться нижче. Але ви не зможете одразу почати так робити. Є люди, які починають так робити відразу і вірять у власну геніальність, зазвичай це погано закінчується, тому що вони не розуміють принципів. Ніхто не малює як Пікассо і не пише програми як Даг Лі, щойно вступивши до університету, в перший же тиждень. Потрібні роки, щоб досягти такого рівня знань.
Олексій: Виходить, ви поділяєте проблему на дві частини: перша – коректність, друга – продуктивність?
Моріс: Саме. До того ж, саме в такому порядку. Частина проблеми полягає у тому, що нові студенти не розуміють, що досягти коректності складно. Вони з першого погляду кажуть: це, мабуть, коректно, залишилося лише прискорити. Тому іноді я розповідаю їм про спочатку некоректний алгоритм, ніби він був коректним.
Як навчити студентів написання складного багатопотокового коду
Олексій: Щоб просто перевірити, чи зможуть вони відчути каверзу?
Моріс: Я завжди попереджаю заздалегідь, що іноді пропонуватиму неправильні алгоритми. Не варто дурити людей. Я пропоную їм скептично ставитись до інформації. Якщо я щось розповідаю та кажу: «дивіться, це очевидно правильно» — це сигнал, що десь тебе намагаються обдурити, і слід почати запитувати. Далі я намагаюся підтримати студентів, щоб вони не переставали ставити запитання, а потім підказую: «що станеться, якщо ми залишимо все як є?». І вони одразу бачать помилку. Але переконати студентів, що їм потрібно потурбуватися про коректність, набагато складніше, ніж здається на перший погляд. Багато хто з цих студентів приходять з досвідом програмування у старших класах, хтось встиг влаштуватися на роботу і займався програмуванням там, і всі вони сповнені впевненості у собі. Це щось армійське: доводиться спочатку переламати їхній настрій, щоб переконати терпляче підходити до вирішення проблем, що виникають. Або може це як у буддистських ченців: спочатку вони вчаться розмірковувати про коректність і як тільки вони усвідомлюють способи міркувань про коректність, їм дозволяється перейти на наступний рівень і почати турбуватися про продуктивність.
Олексій: Тобто іноді ви показуєте студентам неробочі приклади, завдяки чому отримуєте зворотний зв'язок, що показує, чи розуміють вони суть проблеми, чи можуть знайти неправильний код і неправильний результат. Ну і як, студенти зазвичай радують чи засмучують?
Моріс: Майже завжди студенти, зрештою, знаходять помилку. Якщо вони шукають надто повільно, я ставлю питання, і тут важливо зрозуміти, що якщо їх ніколи не обманювати – вони почнуть бездумно сприймати твої слова як істину в кінцевій інстанції. Потім їм стане нудно і вони почнуть засинати, читаючи Facebook на ноутбуці під час заняття. Але коли ви заздалегідь повідомляєте, що їх спробують обдурити, і вони будуть виглядати безглуздо, якщо не відчують каверзи, вони стають куди більш пильними. Це добре у різних сенсах. Хочеться, щоб студенти не лише ставили під сумнів своє розуміння питання, а й ставили під сумнів авторитет викладача. Ідея в тому, щоб студент міг у будь-який час підняти руку і сказати: гадаю, те, що ви зараз сказали – не так. Це важливий інструмент навчання. Я не хочу, щоб хтось із студентів сидів і мовчки про себе думав: все це здається повним маренням, але підняти руку надто страшно, та й взагалі, він же професор, значить все, що він каже – істина. Тому якщо заздалегідь попередити, що не все розказане обов'язково є правдою, у них з'являється стимул приділяти більше уваги матеріалу. Я явно промовляю, що піднімати руку і ставити запитання – це нормально. Ваше питання може прозвучати безглуздо чи наївно, але найчастіше саме так постають найкращі питання.
Олексій: Дуже цікаво. Зазвичай люди мають свого роду психологічний бар'єр, який дозволяє ставити питання професору. Особливо якщо в кімнаті багато людей, і всі бояться, що обговорення твого безглуздого питання забере у всіх цих людей час. Чи є якісь хитрощі, як із цим впоратися?
Моріс: Я часто зупиняюся і ставлю класичні питання. Чи буде правильним якесь твердження, чи вони вирішили обговорювану проблему. Це ключова дія, особливо на початку заняття, коли люди соромляться сказати навіть зовсім небагато. Ви ставите питання студентам і далі нічого не кажете. Настає тиша, всі трохи напружуються, напруження зростає, потім раптом хтось не витримує, зривається і каже відповідь. Так ви розгортаєте ситуацію: продовжувати мовчати стає складніше та незручніше, ніж відповісти! Це стандартний педагогічний трюк. Кожен учитель у світі повинен знати, як це зробити.
Олексій: Тепер ми маємо відмінну назву для цього інтерв'ю: «простіше відповісти, ніж продовжувати мовчати».
Віталій: Давайте ще запитаю. Ви працюєте над топологічними доказами. Як ви взагалі в це вплуталися, адже розподілені обчислення та топологія – взагалі різні речі!
Моріс: Там є прихований взаємозв'язок. Коли я був студентом і навчався математики, я вивчав чисту математику. У мене не було реального інтересу до комп'ютерів, поки навчання не добігло кінця, і я виявив себе перед нагальною необхідністю шукати роботу. Ще студентом я вивчав топологію алгебри. Багато років по тому, працюючи над завданням під назвою Для моделювання проблеми я використовував графи і, як тоді здавалося, знайшов рішення. Треба було просто сісти та обійти граф. Спробувати знайти на цьому графі відповідь. Але мій алгоритм не спрацював: виявилося, що він вічно бігатиме по колу. На жаль, все це не можна було пояснити формальною мовою теорії графів – тією, яку знають усі фахівці в галузі інформатики. А потім я згадав, що багато років тому, ще на заняттях з топології ми використовували поняття , є узагальненням графів більш високі размерности. Тоді я запитав: що буде, якщо переформулювати проблему в термінах симпліціальних комплексів? Це стало ключовим моментом. При використанні потужнішого формалізму, проблема раптово стає набагато простіше. Люди довго боролися з нею, використовуючи графи, але не змогли нічого. Та й зараз не можуть - правильною відповіддю виявився не алгоритм, а доказ неможливості вирішення завдання. Тобто такий алгоритм просто не існує. Але засновано або на симпліціальних комплексах, або на речах, які люди вдавали не вважати симпліційними комплексами. Від того, що ти назвав щось новим ім'ям, своєї сутності воно не втрачає.
Віталій: Виходить, вам просто пощастило?
Моріс: Окрім удачі, це ще й готовність. Мається на увазі, ви не повинні забувати «непотрібні» речі, вивчені раніше. Чим більше непотрібних речей ви дізнаєтеся, тим більше ідей ви зможете отримати, зіткнувшись з новою проблемою. Такий інтуїтивний патерн-матчинг важливий, тому що… Давайте так, це ланцюжок: спочатку я виявив, що графи не зовсім працюють чи зовсім не працюють, це нагадало щось із подій восьмирічної давності та студентські роки, коли ми вивчали всі ці симпліційні комплекси . У свою чергу, це дозволило знайти мій старий підручник з топології і завантажити його назад в голову. Але якби не ті старі знання, я ніколи не просунувся б у вирішенні початкової проблеми.
Нове видання книги The Art of Multiprocessor Programming
Олексій: Ви сказали кілька слів про свою книгу. Напевно, це не найстрашніша таємниця, що ви написали найвідомішу у світі книгу з багатопоточності, . Їй уже близько 11 років і з тих часів вийшов лише . Чи буде друге видання?
Моріс: Це добре, що ви спитали! Буде зовсім скоро, місяці за три чи близько того. Є ще два автори, ми додали набагато більше матеріалу, покращили розділ про fork/join-паралелізм, написали розділ про MapReduce, додали багато нового та викинули непотрібне – те, що на момент написання першого видання було дуже цікаво, а сьогодні вже ні. Вийшла дуже серйозно перероблена книга.
Олексій: Все вже зроблено, лишилося тільки випустити?
Моріс: Кілька голів все ще потрібно доопрацьовувати. Наш видавець (думаю, він нас уже ненавидить) все ще намагається донести, що нам варто працювати швидше. Ми дуже відстали від графіка. Теоретично ми могли б зробити цю книгу на кілька років раніше.
Олексій: Чи є шанси отримати нову версію книги перед Різдвом?
Моріс: Це і є наша ціль! Але я пророкував перемогу так багато разів, що ніхто мені більше не вірить. Вам, напевно, теж не варто мені довіряти в цьому питанні.
Олексій: У будь-якому разі це фантастична новина. Перше видання книги мені дуже сподобалося. Можна сказати, що я фанат.
Моріс: Сподіваюся, і нове видання виявиться гідно вашого гарячого ентузіазму, дякую!
Як винаходила транзакційна пам'ять
Віталій: Наступне питання про транзакційну пам'ять. Наскільки я зрозумів, ви піонер у цій галузі, ви винайшли її в той час, коли ніхто й не замислювався над такими речами. Чому ви вирішили перейти до цієї області? Чому транзакції видалися вам важливими? Чи думали ви, що колись їх втілять у залізі?
Моріс: Я знав про транзакції з часів досліджень в аспірантурі.
Віталій: Так, але ж це інші транзакції!
Моріс: Я працював з Елліоттом Моссом над збіркою сміття, що не блокує. Наша проблема була в тому, що нам хотілося атомарно змінювати кілька слів у пам'яті і тоді алгоритми стали б дуже простими, і принаймні деякі з них стали б ефективнішими. Використовуючи для , що надається паралельною архітектурою, зробити щось можна, але це дуже неефективно і потворно, тому що вам довелося б займатися рівнями непрямості. Я хочу змінити слова пам'яті і мені потрібно перемикатися, тому що я можу змінити лише один покажчик, тому вказувати їм потрібно якусь структуру, схожу на каталог. Ми говорили про те, як чудово було б, якби ми могли так змінити залізо, щоб воно змогло робити одночасний запис. Здається, це зауважив Елліот: якщо подивитися на протоколи когерентності кешу, вони вже надають більшу частину необхідної функціональності. В оптимістичній транзакції, протокол когерентності кешу помітить наявність конфлікту синхронізації та кеш стане . Що буде, якщо спекулятивно запустити транзакцію на своєму кеші та використати механізми протоколу когерентності для виявлення конфліктів? Спекулятивну апаратну архітектуру було легко спроектувати. Так ми й написали ту про транзакційну пам'ять. У той же час компанія, в якій я працював, Digital Equipment Corporation, створювала новий 64-розрядний процесор під назвою Alpha. І ось я пішов і зробив презентацію для групи розробників Alpha про нашу чудову транзакційну пам'ять і вони запитали: який додатковий дохід отримає наша компанія, якщо ми додамо все це прямо в процесор? І в мене не було абсолютно жодної відповіді на це, тому що я – технолог, я не фахівець із маркетингу. Мені справді не було чого відповісти. Вони не дуже вразилися тим, що нічого не знаю.
Віталій: Мільярди! Просто кажіть «мільярди»!
Моріс: Так, це я й мав сказати. Тепер, в епоху стартапів і всього, я знаю, як написати бізнес-план. Що можна трохи збрехати про розмір потенційного прибутку. Але в ті дні це здавалося наївним, тому я просто сказав: не знаю. Якщо ви подивіться історію публікації про транзакційну пам'ять, то зауважте, що за рік з'явилося кілька посилань на неї, а потім близько десяти років ніхто взагалі не цитував цю статтю. Цитати з'явилися приблизно 2004 року, коли з'явилася справжня багатоядерність. Коли люди відкрили для себе, що написання паралельного коду може давати гроші, почалися нові дослідження. Раві Раджвар , до певної міри познайомила мейнстрім з поняттям транзакційної пам'яті. (Примітка редакції: у статті є друга версія, випущена у 2010 році та вільно доступна ). Раптово люди усвідомили, як саме все це можна використовувати, як можна прискорювати традиційні алгоритми з блокуваннями. Хороший приклад чогось, що у минулому здавалося лише цікавою академічною проблемою. І так, якби ви в ті часи запитали мене, чи я вважаю, що все це виявиться важливим у майбутньому, я б сказав: звісно, але коли саме – незрозуміло. Можливо, років через 50? Насправді це виявилося лише десятиліття. Дуже приємно, коли ти щось робиш, і лише за десять років люди це помічають.
Чому варто проводити дослідження в галузі розподілених обчислень
Віталій: Якщо говорити про нові дослідження, щоб ви порадили читачам — розподілені обчислення чи багатоядерність і чому?
Моріс: У наш час легко отримати багатоядерний процесор, але складніше налаштувати справжню розподілену систему. Я почав працювати над ними, бо хотів зробити щось, що відрізняється від моєї кандидатської дисертації. Це порада, яку я завжди даю новачкам: не пишіть продовження дисертації – спробуйте йти у новому напрямку. А ще багатопоточність – це просто. Я можу проводити експерименти над власним форком, запущеним на ноутбуці, не встаючи з ліжка. Але якби я раптом хотів створити справжню розподілену систему, довелося б провернути велику роботу, залучити студентів тощо. Я людина лінива і хотів би працювати над багатоядерністю. Експерименти над багатоядерними системами теж робити простіше, ніж над розподіленими, бо навіть у дурній розподіленій системі є дуже багато чинників, які потрібно контролювати.
Віталій: Чим ви самі зараз займаєтесь, досліджуєте блокчейн? На які статті варто звернути увагу насамперед?
Моріс: Нещодавно з'явилася , яку я написав разом зі своїм студентом, Вікрамом Сарафом, спеціально для виступу на у Парижі три тижні тому. Це стаття про корисні на практиці розподілені системи, в якій ми пропонуємо зробити Ethereum багатопоточним. Наразі смарт-контракти (код, що запускається на блокчейні) виконуються послідовно. Ми ще раніше написали статтю, в якій йшлося про спосіб використання спекулятивних транзакцій для прискорення процесу. Ми взяли багато ідей із програмної транзакційної пам'яті та сказали, що якщо ви зробите ці ідеї частиною віртуальної машини Etherium, тоді все почне працювати швидше. Але для цього необхідно, щоб у контрактах не було конфліктів за даними. А потім ми припустили, що у реальному житті таких конфліктів справді немає. Але ми не мали можливості це з'ясувати. Потім нам спало на думку, що у нас на руках майже десять років історії реальних контрактів, тому ми вивантажили блокчейн Etherium і запитали: що б сталося, якби ці історичні записи виконувались паралельно? Ми виявили суттєвий приріст швидкості. У перші дні життя Etherium швидкість підвищилася дуже сильно, але сьогодні дещо складніше, тому що контрактів стало менше і вище стала ймовірність конфліктів за даними, що вимагають серіалізації. Але це – експериментальна робота з реальними історичними даними. Що приємно в блокчейні - він пам'ятає все і назавжди, тому можна повернутися в минуле і вивчити, що сталося б, якби ми використовували інші алгоритми для запуску коду. Як людям там, у минулому, припала б до смаку наша нова ідея. Такі дослідження робити куди простіше та приємніше, адже є штука, яка за всім стежить і все записує. Це вже щось більше схоже на соціологію, ніж розробку алгоритмів.
Чи зупинився розвиток алгоритмів і як жити далі
Віталій: Час останнього теоретичного питання! Чи є відчуття, що зрушення в галузі конкурентних структур даних скорочуються щороку? Як ви думаєте, ми підійшли до плато у нашому розумінні структур даних чи будуть якісь серйозні покращення? Може, є якісь хитрі ідеї, які можуть повністю змінити всі?
Моріс: Можливо ми досягли плато в структурах даних для традиційних архітектур. Але структура даних для нових архітектур все ще дуже перспективна область. Якщо ви хочете створювати структури даних, скажімо, для апаратних прискорювачів, структури даних для GPU сильно відрізняються від структур даних для CPU. Коли ви розробляєте структури даних для блокчейнів, потрібно хешувати шматочки даних і потім укладати щось на зразок , для запобігання підробкам. У цій галузі останнім часом спостерігається сплеск активності, багато хто робить дуже хорошу роботу. Але я думаю, трапиться так, що нові архітектури та нові додатки приведуть до нових структур даних. Старі програми та традиційна архітектура – можливо, там уже не так багато простору для досліджень. Але якщо ви зійдете з торованої доріжки, і подивіться за край, ви побачите божевільні речі, які мейнстрім не сприймає всерйоз - ось де всі захоплюючі речі і відбуваються насправді.
Віталій: Тому, щоб бути дуже відомим дослідником, я мав винайти свою власну архітектуру 🙂
Моріс: Можна "вкрасти" чужу нову архітектуру - здається, це набагато простіше!
Робота у Браунівському Університеті
Віталій: Не могли б ви детальніше розповісти про , у якому ви працюєте? Про нього в контексті інформаційних технологій відомо не так вже й багато. Менше, ніж про MIT, наприклад.
Моріс: Браунівський Університет – один із найстаріших університетів у Сполучених Штатах. Я думаю, що тільки Гарвард трохи старший. Браун є частиною так званої , яка є зборами восьми найстаріших університетів. Гарвард, Браун, Корнелл, Єль, Колумбія, Дартмут, Пенсільванія, Прінстон. Це свого роду старий, маленький та трохи аристократичний університет. Основна увага приділяється гуманітарній освіті. Він не намагається бути схожим на MIT, MIT дуже спеціалізований та технічний. Браун - відмінне місце для вивчення російської літератури або класичної грецької мови, і, звичайно ж, Computer Science. Він зосереджений всебічному освіті. Більшість наших студентів йдуть у Facebook, Apple, Google – тому, гадаю, у наших студентів немає проблем влаштуватися і в індустрії. Я пішов працювати до Брауна, тому що до цього працював Digital Equipment Corporation у Бостоні. Це була компанія, яка винайшла багато цікавого, але заперечувала важливість персональних комп'ютерів. Компанія з непростою долею, засновники якої колись були молодими революціонерами, вони нічого не навчилися і нічого не забули, і тому вони перетворилися з революціонерів на реакціонерів протягом приблизно десятка років. Вони любили жартувати, що персональним комп'ютерам місце у гаражі – у покинутому гаражі, звісно. Цілком очевидно, що вони були знищені більш гнучкими компаніями. Коли стало ясно, що у компанії проблеми, я зателефонував своєму другові з Брауна, який знаходиться приблизно за годину їзди від Бостона. Я не хотів їхати з Бостона на той час, адже в інших університетах було не так багато вакансій. Це був час, коли в області Computer Science не було так багато вакансій, як зараз. А у Брауна була вакансія, мені не потрібно було переїжджати зі свого будинку, не треба було перевозити сім'ю, та й мені дуже подобається жити у Бостоні! Так я і вирішив піти до Брауна. Мені сподобалося. Студенти чудові, тому я ніколи навіть не намагався піти ще кудись. На творчій відпустці я працював у Microsoft протягом року, на рік йшов у Technion у Хайфі, зараз буду в Algorand. У мене скрізь багато колег і тому фізичне розташування наших навчальних класів не так вже й важливо. А ось найголовніше – студенти, вони тут найкращі. Я ніколи не намагався піти кудись ще, тому що цілком щасливий і тут.
Проте, незважаючи на популярність Брауна у Сполучених Штатах, він напрочуд невідомий за кордоном. Як бачите, зараз я роблю все можливе, щоб виправити цей стан речей.
Різниця між дослідженнями в університеті та всередині корпорації
Віталій: Добре, наступне питання про Digital Equipment. Ви були там дослідником. У чому різниця між роботою в R&D-відділі великої компанії та роботою в університеті? Які переваги та недоліки?
Моріс: За двадцять років я встиг попрацювати в Microsoft, тісно взаємодіяв із співробітниками Sun Microsystems, Oracle, Facebook, а тепер Algorand. На підставі цього хочу сказати, що можливо проводити першокласні дослідження і в компаніях, і в університеті. Важлива відмінність у тому, що у компанії ви працюєте з колегами. Якщо в мене раптом з'явилася ідея неіснуючого поки що проекту, я мушу переконати рівних собі колег, що це хороша ідея. Якщо я в Брауні, то можна сказати своїм студентам: давайте працювати над антигравітацією! Вони або підуть до когось іншого, або візьмуться за проект. Так, мені потрібно буде знайти фінансування, мені потрібно буде написати заявку на грант і таке інше. У будь-якому випадку завжди знайдеться безліч студентів, і ви зможете в односторонньому порядку приймати рішення. Але в університеті ви, швидше за все, не працюватимете з людьми вашого рівня. У світі промислових досліджень спочатку доведеться переконувати всіх, що за ваш проект варто братися. Я не можу нікому нічого наказати. І обидва ці способи роботи цінні, адже якщо ви працюєте над чимось справді божевільним і ваших колег важко переконати, легше переконати аспірантів – особливо якщо ви їм і платите. Якщо ви працюєте над чимось, що потребує великого досвіду та глибокої експертизи, то вам потрібні колеги, які зможуть сказати «ні, так сталося, що я розумію в цій галузі і твоя ідея погана, нічого не вийде». Це дуже корисно з погляду марнування часу. А ще, якщо у промислових лабораторіях ви витрачаєте купу часу на написання звітів, то в університеті ви витрачаєте цей час на те, щоб знайти гроші. Якщо я хочу, щоб студенти змогли кудись з'їздити, я маю знайти на це гроші в якомусь іншому місці. І чим важливіше у вас становище в університеті, тим більше часу доводиться проводити, збираючи гроші. Тож тепер ви знаєте, ким я працюю – професійним жебракам! Як один із тих ченців, які ходять з тарілкою для пожертвувань. Загалом ці два види діяльності доповнюють один одного. Ось чому я намагаюся жити і стояти на ногах в обох світах.
Віталій: Здається, переконати компанію складніше, ніж переконати вчених.
Моріс: Складніше і набагато. Причому в різних галузях по-різному: хтось проводить повномасштабні дослідження, а хтось сфокусований на своїй темі. Якби я пішов у Microsoft або Facebook і сказав: давайте зробимо антигравітацію, вони навряд чи це оцінили б. Але якби я сказав у точності те саме своїм аспірантам, вони швидше за все взялися б за роботу миттєво, хоча проблеми тепер були б вже у мене – адже треба знайти на це гроші. Але поки що ви хочете робити щось, що відповідає цілям компанії, така компанія може бути дуже хорошим місцем для проведення досліджень.
Hydra та SPTDC
Віталій: Мої питання добігають кінця, тому давайте поговоримо трохи про майбутню подорож до Росії.
Моріс: Так, я з нетерпінням чекаю на повернення до Петербурга.
Олексій: Для мене велика честь, що ви з нами цього року. Ви вже вдруге в Пітері, правда?
Моріс: Вже третій!
Олексій: Зрозумів, але на - точно другий. Минулого разу школа називалася , зараз ми змінили одну літеру (C на D, Concurrent на Distributed), щоб підкреслити, що напрямів, які стосуються саме розподілених обчислень, цього року побільшало. Можете сказати пару слів про ваші доповіді на Школі та ?
Моріс: На Школі я хочу розповісти про основи роботи блокчейну і що з ним взагалі можна робити. Хочеться показати, що блокчейни дуже схожі на знайоме нам багатопотокове програмування, але зі своїми нюансами, і ці відмінності важливо розуміти. Якщо ви припуститеся помилки у звичайному веб-додатку – це просто неприємно. Якщо ви напишете код у фінансовому додатку, хтось точно вкраде всі ваші гроші. Це зовсім різний рівень відповідальності та наслідків. Я трохи поговорю про proof-of-work, про смарт-контракти, про транзакції між різними блокчейнами.
Поряд зі мною працюватимуть інші спікери, яким теж є що сказати про блокчейн, і ми домовилися скоординуватись між собою, щоб наші історії добре стикувалися. А ось для інженерної доповіді я хочу розповісти зрозуміле широкій аудиторії пояснення, чому не варто вірити всьому, що ви чуєте про блокчейни, чому блокчейни – це чудова область, як вона стикується з іншими відомими ідеями, і чому нам варто сміливо дивитися у майбутнє.
Олексій: На додачу хочу сказати, що проходити це буде не у форматі мітапу чи групи користувачів, як це було два роки тому. Ми вирішили зробити поряд зі школою невелику конференцію. Причина в тому, що після спілкування з Петром Кузнєцовим ми усвідомили, що школа обмежена лише сотнею, може бути 120 людьми. При цьому є багато інженерів, які хочуть з вами поспілкуватися, побувати на доповідях, і взагалі цікавляться темою. Задля цього ми створили нову конференцію . До речі, є ідеї, чому саме Гідра?
Моріс: Бо на ній буде сім спікерів? І їм можна відрізати голови, і на їхньому місці виростуть нові спікери?
Олексій: Відмінна ідея вирощування нових спікерів. Але насправді тут є історія. Пам'ятайте легенду про Одіссея, там де він мав пропливти між ? Гідра - це щось на зразок Харібди. Історія в тому, що якось я виступав на конференції і розповідав про багатопотоковість. На цій конференції було лише два треки. На початку доповіді я сказав слухачам у залі, що вони тепер мають вибір між Сціллою та Харібдою. Моєю тотемною твариною стала Харібда, тому що у Харібди безліч голів, а в мене тема – багатопотоковість. Так і з'являються назви конференцій.
У будь-якому випадку, у нас закінчилися питання та час. Так що, дякую, друзі, за відмінне інтерв'ю, та зустрінемося на школі SPTDC та конференції Hydra 2019!
Продовжити спілкування з Моріс можна буде на конференції Hydra 2019, яка пройде 11-12 липня 2019 року в Санкт-Петербурзі. Він приїде з доповіддю . Квитки можна придбати .
Джерело: habr.com