Хабрахабр

«Эмпирические результаты лишь для публикации, реальные мотивы работ — эстетические». Большое интервью с Майклом Скоттом

Он занимается исследованиям в области параллельного и распределённого программирования и дизайна языков и обучает этому студентов. Майкл Скотт — уже 34 года как профессор Computer Science в Рочестерском университетe, а в родном универститете Wisconsin–Madison был деканом в течение пяти лет.

Также вы можете знать его как автора того самого алгоритма Майкла-Скотта. Мир знает Майкла по учебнику «Programming Language Pragmatics», а работа «Algorithms for scalable synchronization on shared-memory multiprocessors» получила премию Дейкстры как одна из наиболее известных в области распределённых вычислений.

Внедрение «dual data structures» в JavaSE 6 позволило в 10 раз улучшить производительность ThreadPoolExecutor. Вместе с Дагом Ли разработал те неблокирующие алгоритмы и синхронные очереди, на которых работают библиотеки Java.

Содержание:

  • Начало карьеры, Рочестерский университет. Проект Charlotte, язык Lynx;
  • IEEE Scalable Coherent Interface, блокировка MCS;
  • Выживание в постоянно меняющемся мире;
  • Становятся ли студенты глупее? Глобальные тренды, интернационализация;
  • Эффективная работа со студентами;
  • Как не отстать при подготовке новых курсов и книг;
  • Связь между бизнесом и академией;
  • Практическая реализация идей. MCS, MS, CLH, JSR 166, работа с Дагом Ли и многое другое;
  • Транзакционная память;
  • Новые архитектуры. Близкая победа транзакционной памяти;
  • Энергонезависимая память, Optane DIMM, сверхбыстрые устройства;
  • Следующий большой тренд. Dual data structures. Hydra.

Занимается исследованиями в области теории и практики конкурентных структур данных. Виталий Аксенов — на данный момент пост-док в IST Austria и сотрудник кафедры «Компьютерные Технологии» Университета ИТМО. До работы в IST, он получил PhD в Университете Париж Дидро и в Университете ИТМО под руководством профессора Петра Кузнецова.

Алексей участвовал в подготовке более чем 50 конференций, а в его резюме есть всё что угодно, начиная от позиции инженера-разработчика в Oracle (JCK, Java Platform Group), и заканчивая позицией деврела в компании Одноклассники. Алексей Федоров — продюсер в JUG Ru Group, российской компании, которая занимается организацией конференций для разработчиков.

Десять лет работает над производительностью и масштабируемостью NetCracker OS — ПО, используемого операторами связи для автоматизации процессов управления сетью и сетевым оборудованием. Владимир Ситников — инженер в компании Netcracker. Автор более десятка улучшений производительности в официальном PostgreSQL JDBC-драйвере. Увлекается вопросами производительности Java и Oracle Database.

Прямо до неприличия. Алексей: Для начала я хотел рассказать вам, что мы в России все очень любим Сomputer Science, Data Science и алгоритмы. Поэтому предстоящая конференция, школа и само это интервью должны пользоваться большой популярностью. Мы все читали книгу Cormen, Leiserson и Rivest. Пользуется ли Computer Science такой же любовью в США? Нам поступило множество вопросов для этого интервью от студентов, программистов и членов сообщества, поэтому мы очень благодарны вам за эту возможность.

Но факт в том, что благодаря ей за последние 30 лет произошли колоссальные изменения в бизнесе, промышленности, искусстве и обществе в целом. Майкл: Наша область настолько разносторонняя, в ней так много направлений, и она влияет на общество такими различными способами, что мне сложно ответить вам однозначно.

Во многих университетах наблюдается нечто вроде специализации на одном определённом направлении. Виталий: Давайте начнём с чего-нибудь отдаленного. А есть ли подобного рода специализация в Рочестерском университете? Для университета Карнеги-Меллона это параллельные вычисления, для MIT — криптография, роботы и многопоточность.

На нашей кафедре всегда больше всего внимания уделялось искусственному интеллекту. Майкл: Если честно, я бы сказал, что CMU и MIT специализируются по всем направлениям. Но когда я учился в университете, у меня не было курсов по ИИ, и я никогда в этой области не работал. Половина работающих у нас людей занимаются ИИ или человеко-компьютерным взаимодействием — эта доля больше, чем на других кафедрах, и так было всегда. Утешением служит то, что вторая по важности для нашей кафедры проблема — это параллельное и многопоточное программирование, то есть моя специализация. Так что моя кафедра специализируется на проблеме, к которой я отношения не имею.

По списку ваших публикаций видно, что первые работы касались достаточно широкого спектра вопросов: управление памятью в многопоточных системах, распределенные файловые системы, операционные системы. Виталий: Вы начали заниматься Computer Science, когда область многопоточного программирования только зарождалась. Вы пытались найти своё место в исследовательском сообществе? Почему такая разносторонность?

Там я работал вместе с Рафаэлем Финкелем (Raphael Finkel) и Марвином Соломоном (Marvin Solomon). Майкл: Будучи студентом, я участвовал в проекте Charlotte в университете Висконсина, в рамках которого разрабатывалась одна из первых распределенных операционных систем. Я создал язык программирования Lynx, который должен был упростить создание серверов для распределенной операционной системы со слабым связыванием. Моя диссертация была посвящена разработке языка для системного софта для распределенных систем — сейчас про нее все уже забыли, и слава богу. Но в Рочестере университет был очень маленький, и из-за этого разные группы там очень тесно общались друг с другом. Поскольку на тот момент я в основном занимался операционными системами, то предполагал, что и моя карьера будет в основном связана с ними. Мне это очень нравилось, быть универсалом — большое преимущество для меня. Там не было десятка других специалистов по операционным системам, с которыми я мог бы общаться, так что все контакты были с людьми, которые работали в совершенно других областях. Если же говорить конкретно о многопоточных структурах данных и алгоритмах синхронизации, то ими я начал заниматься совершенно случайно.

Виталий: Можно немного подробней об этом?

Она произошла на конференции ASPLOS в Бостоне — это было в конце 80-х или в начале 90-х. Майкл: Это забавная история, которую я не устаю всем рассказывать. Я был с ним знаком, но мы до этого не вели совместных исследований. На конференции присутствовал Джон Меллор-Крамми (John Mellor-Crummey), выпускник нашего факультета. В этом Multicube на уровне железа был механизм синхронизации, который назывался Q on Sync Bit, а позднее он был переименован в Q on Lock Bit, потому что так его можно было произносить как название сыра Colby, то есть это был такой каламбур. Мэри Вернон (Mary Vernon) из Висконсина выступала с докладом о многопроцессорной системе, которую они разрабатывали в Висконсине: Wisconsin Multicube. Это был механизм блокировки, который создавал указатели из одного кэша на другой на уровне железа, чтобы каждый держатель блокировки знал, чья за ним очередь. Если вы интересуетесь механизмами многопоточности, вы, наверное, знаете, что Colby в конченом итоге стал механизмом синхронизации стандарта Scalable Coherent Interface от IEEE. Разве нельзя того же самого добиться при помощи compare-and-swap? Когда Джон и я об этом услышали, мы переглянулись и сказали: а зачем это делать на уровне железа? В последствии мы её реализовали, поэкспериментировали, идея оказалась удачной, и мы опубликовали статью. Мы взяли один из блокнотов, лежавших в аудитории, и набросали на нём блокировку MCS, пока Мэри продолжала свой доклад. Но затем возникла другая проблема в том же направлении, и в конечном итоге синхронизация, многопоточность и структуры данных стали моей основной специальностью. Тогда для меня эта тема казалась лишь забавным отвлечением, после которого я планировал вернуться к операционным системам. Как видите, произошло это всё по случайности.

Виталий: Я давно знаком с блокировкой MCS, но до текущего момента я не знал, что это Ваша работа, и не понимал, что это акроним от Ваших фамилий.

Алексей: У меня есть вопрос по связанной теме. 30 или 40 лет назад было больше свободы в разных специальностях. Хочешь начать карьеру в многопоточности или распределенных системах — пожалуйста, хочешь заняться операционными системами — никаких проблем. В каждой области было очень много открытых вопросов и мало экспертов. Сейчас появились узкие специализации: нет просто экспертов по операционным системам в целом, есть специалисты по отдельным системам. То же самое с многопоточностью и распределенными системами. Но проблема в том, что наши жизни не бесконечные, каждый может посвятить исследованиям лишь несколько десятилетий. Как выжить в этом новом мире?

Мне повезло, что я начал работать в Computer Science, когда эта сфера была в «подростковом» возрасте. Майкл: Мы в этом плане не особенные, всё то же самое происходило когда-то и в других областях. Такая возможность появляется нечасто. Некоторые основы уже были заложены, но все было еще очень незрелое. Но это не значит, что в математике никто больше не делает интересных открытий. Электротехника существует уже очень давно, физика — еще дольше, математика — чуть ли не с начала времён. Вы верно заметили, что сейчас значительно больше специализаций, чем было раньше, но это лишь значит, что мы оказались в той же ситуации, что и большинство остальных областей человеческой деятельности. Открытых проблем по-прежнему множество, но в то же время и учиться нужно больше.

У меня математическое образование, и во время учёбы я часто посещал конференции и работал над различными научными темами. Алексей: Меня здесь интересует более практический аспект вопроса. В высокоуровневых темах это не так, но как только начинаешь во что-либо углубляться, аудитория за тобой перестаёт успевать. Я обнаружил, что мои доклады никто в аудитории не понимал, и точно так же, доклады других людей были понятны только для них самих. Как вы с этим боретесь?

Недавно я подготовил доклад, в котором ушёл слишком глубоко в технические подробности. Майкл: Не всегда успешно. Слайды было уже не изменить, так что получилось не слишком удачно — поэтому, вообще говоря, я стараюсь слайды не использовать. По ходу доклада стало видно, что большая часть аудитории меня не понимает, так что мне пришлось приспосабливаться к ситуации на ходу. Нужно знать, к кому вы обращаетесь, какой у них уровень знаний и что им нужно услышать, чтобы оценить вашу работу. В целом, мой совет такой — учитывайте свою аудиторию.

Виталий: А вы не могли бы намекнуть, о чём была эта лекция?

Суть в том, что мы часто погружаемся слишком глубоко в тонкости той проблемы, над которой работаем, поэтому нам становится сложно объяснить в начале доклада, почему эта проблема интересна и важна и как она связана с вопросами, которые слушатели уже знают. Майкл: Если честно, я предпочёл бы на эту тему не распространяться, чтобы оставить анонимными тех людей, о которых идёт речь. И это же было слабой стороной моего недавнего доклада. По моим наблюдениям, студентам этот навык даётся тяжелее всего. Насколько технической будет эта вступительная часть, зависит от аудитории. Правильно построенный доклад должен с самого начала найти контакт с аудиторией, объяснить ей, в чём именно заключается проблема и как она соотносится с уже известными ей темами. Вступление должно быть доступно всем, а к концу часть, возможно, уже не будет за вами успевать, но люди, относительно знакомые с вашей областью, смогут разобраться во всём. Если она совсем разношёрстная, то доклад может быть многоступенчатым.

Алексей: Вы наблюдаете за студентами уже несколько десятков лет. Становятся ли студенты глупее или умнее от десятилетия к десятилетию или от года к году? В России профессоры постоянно жалуются, что студенты с каждом годом глупеют, и прямо-таки непонятно, что с этим делать.

Подсознательно у нас есть склонность ожидать, что студенты освоят весь тот 30-летний опыт, который уже есть у нас. Майкл: От нас, стариков, действительно можно услышать много негатива. Наверное, потому что им 20 лет, как вам такое? Если у меня есть более глубокое понимание, чем в 1985 году, то почему его нет у студентов? Раньше канадцев было много, поскольку мы находимся очень близко к границе с Канадой, и студенты оттуда могут ездить домой на выходных. Думаю, наиболее существенные изменения в последние десятилетия касаются демографического состава: у нас сейчас значительно больше международных студентов, за исключением канадцев. Но сейчас в Канаде много хороших университетов, и канадцы предпочитают учиться у себя, в США их стало ездить значительно меньше.

Алексей: Как вы думаете, это местный тренд или глобальный?

Наша область стала значительно более интернациональной. Майкл: Не помню точно кто, но кто-то сказал, что мир плоский. Ещё в большей степени эти изменения коснулись IEEE, поскольку она всегда была более интернациональной организацией, чем ACM. Конференции ACM раньше проходили исключительно внутри США, потом решили раз в 4 года проводить их в других странах, а сейчас они проходят по всему миру. А руководители программ (program chairs) есть из Китая, Индии, России, Германии и многих других стран, потому что везде сейчас очень много чего происходит.

Алексей: Но, вероятно, есть какие-то негативные стороны такой интернационализации?

Когда-то главной проблемой был тот факт, что США крали самых умных и талантливых людей у стран во всём мире. Майкл: Я бы сказал, что все негативные стороны касаются не техники, а политики. А сейчас основная проблема — это политические игры между разными странами вокруг виз и иммиграции.

Понятно. Алексей: То есть барьеры и тому подобные вещи.

Есть ведь разные варианты: можно стараться в первую очередь вдохновить их попробовать что-то новое, а можно больше внимания уделять подробностям того, как устроена определенная технология. Владимир: Лично мне интересно, какого подхода вы придерживаетесь, когда преподаете новый предмет студентам. Что предпочитаете вы?

Алексей: И как найти чёртов баланс между первым и вторым?

Обычно я заранее даю студентам материал для чтения, чтобы они в него вникли, по мере сил разобрались и сформулировали вопросы по тем местам, которые понять не удалось. Майкл: Проблема в том, что занятия не всегда проходят так, как мне хотелось бы. Это то, как мне больше всего нравится вести занятия. Тогда в классе можно сосредоточиться именно на наиболее трудных моментах и исследовать их всем вместе. В итоге приходится уделять общему пересказу материала значительно больше времени, чем хотелось бы. Но с учётом той нагрузки, которая сейчас лежит на студентах, мне далеко не всегда получается сделать так, чтобы они подготовились заранее. В противном случае проще один раз записать видео, которое студенты могут затем смотреть у себя дома. Несмотря на это, я стараюсь, чтобы наши занятия были интерактивными. На занятиях я предпочитаю пользоваться не слайдами, а мелом и доской, за исключением отдельных случаев, когда какая-нибудь диаграмма слишком сложная, чтобы её изобразить на доске. Смысл живых занятий — в человеческом взаимодействии. Поскольку нет строго определенного порядка, в котором я даю материал, это позволяет адаптироваться к аудитории в зависимости от вопросов, которые я получаю. Благодаря этому мне нет необходимости придерживаться жёсткого плана занятия. В общем, я стараюсь, чтобы занятия были как можно более интерактивными, чтобы излагаемый мной материал зависел от вопросов, которые мне задают.

По моему опыту довольно сложно добиться от слушателей вопросов. Владимир: Это очень здорово. Как вы с этим справляетесь? Даже если заранее просишь задавать любые вопросы, не важно, глупые или умные, они всё равно молчат.

Или можно задать простой технический вопрос с ответом «да» или «нет», чтобы определить, поняли ли люди, о чём только что шла речь. Майкл: Вы будете смеяться, но если достаточно долго молча стоять, то рано или поздно всем станет неудобно, и кто-нибудь да задаст вопрос. Кто считает, что да? Например, есть ли в приведённом примере гонка данных? Кто вообще ничего не понимает, потому что в общей сложности поднялась только половина рук? Кто считает, что нет?

Виталий: И если ты ответил неверно, вылетаешь из класса 🙂

Я должен понять, что именно студенту нужно знать, чтобы ответить на вопрос, который я только что задал. Майкл: Если ты не ответил ничего, то должен задать вопрос. Я готов подстроиться под них, чтобы они разобрались в проблеме. Нужно, чтобы они помогли мне помочь им. И если достаточно долго не давать студентам покоя, то в итоге иногда они задают правильные вопросы, то есть такие, благодаря которым я вижу, что именно происходит в головах у студентов.  Но если я не знаю, что происходит у них в голове, я не могу этого сделать.

Бывают ли они неожиданными? Алексей: Наталкивают ли иногда эти вопросы на идеи, о которых вы сами раньше не думали? Позволяют ли взглянуть на какую-то проблему в новом свете?

Часто бывают вопросы, которые приводят к интересным проблемам, о которых я не планировал говорить. Майкл: Бывают вопросы, благодаря которым открывается новый способ подачи материала. И, согласно им, очень часто это бывает наиболее интересная часть занятия. Студенты мне часто говорят, что у меня есть склонность уходить от темы занятия, когда такое происходит. Это значительно чаще происходит в беседах со студентами, а не во время занятий, но изредка было и во время занятий.  Совсем редко, буквально несколько раз, студенты задавали вопросы, которые наталкивали на новое направление в исследовании и вырастали в статью.

Алексей: То есть студенты задавали вам вопросы, на основе которых потом можно было опубликовать статью?

Майкл: Да. 

Когда они хотят узнать больше, чем было рассказано во время занятия? Виталий: Насколько часто у вас происходят такие беседы со студентами?

У меня их где-то 5 или 6 человек, и мы всё время с ними что-то обсуждаем. Майкл: С моими аспирантами — постоянно. Хотя хотелось бы, чтобы это происходило чаще. А разговоры такого рода со студентами, которые просто посещают мои занятия — не слишком часто. Каждый семестр некоторым студентам удаётся преодолеть этот психологический барьер, и с ними всегда очень интересно говорить после занятий. Подозреваю, что они просто боятся приходить на факультет в часы приёма. Так что, возможно, всё работает так, как надо.  Правда, если бы все студенты были настолько же смелыми, у меня просто не хватило бы времени.

Насколько я знаю, в США у преподавателей очень много работы — заявки на гранты и тому подобное.  Виталий: Как вам удаётся находить время для общения со студентами?

Так что мотивации к этому у меня достаточно. Майкл: Честно говоря, работа со студентами — это тот аспект моей деятельности, который мне нравится больше всего. Сейчас лето, поэтому график менее плотный, но во время учебного года каждый день с 9 до 17 у меня всё забито. Большая часть времени, которое я провожу в своём офисе, уходит на всякого рода встречи. Исследовательская работа, рецензии, гранты — для всего этого остаются только вечера и выходные. 

Алексей: Продолжаете ли вы сейчас читать какие-либо курсы, которые вы читаете на протяжении длительного времени? Что-нибудь вроде введения в Computer Science.

Майкл: Первое, что здесь приходит в голову — курс языков программирования. 

Возможно, тут более интересны не подробности отдельного курса, а общий тенденции. Алексей: Насколько сильно отличается сегодняшний вариант этого курса от того, который был 10, 20, 30 лет назад?

Я стал читать его в конце 1980-х, заменив моего коллегу, Дага Болдуина (Doug Baldwin). Майкл: Мой курс языков программирования был несколько необычен в то время, когда я его создал. Мне не нравился ни один из существовавших тогда учебников, поэтому я в конечном итоге сам написал учебник для этого курса. Тема курса лишь косвенно относилась к моей специализации, но когда он ушёл, я оказался лучшим кандидатом для проведения этого курса. Мой подход необычен в том плане, что в нём сознательно смешиваются проблемы проектирования языка и его реализации, и большое внимание уделяется взаимодействию между этими аспектами во всех возможных областях. (Примечание редакции: речь идёт о книге «Programming Language Pragmatics») Сейчас он используется в более чем 200 университетах по всему миру. А вот набор языков, при помощи которого эти понятия демонстрируются, поменялся целиком. Основной подход остался неизменным, как и многие базовые понятия: абстракции, пространство имён, модульность, типы. Зато они знают Swift, Go, Rust, поэтому я должен говорить о языках, которые в ходу сегодня. Когда курс был только создан, в нём было множество примеров на Pascal, а сегодня многие мои студенты о таком языке даже не слышали. Сейчас же нужно много материала о Python, Ruby и даже Perl, потому что это то, на чём в наши дни пишут код, в этих языках происходит множество интересных вещей, в том числе в области проектирования языков.  Кроме того, сейчас студенты хорошо разбираются в скриптовых языках, а когда я начинал преподавать этот курс, он целиком был посвящен компилируемым языкам.

Как не отстать в этой области? Виталий: Тогда мой следующий вопрос будет связан с предыдущим. Как вам это удаётся? Я подозреваю, что обновлять такой курс требует большого объема работы — нужно разбираться в новых языках, понимать основные идеи.

Но чаще всего я просто делаю то, что делают все остальные — читаю интернет. Майкл: Я не могу похвастаться, что у меня это всегда на 100% получается. Это по части вещей, происходящих в коммерческой разработке. Если я хочу разобраться в Rust, я вбиваю его в Google, иду на страницу Mozilla и читаю выложенное там руководство. Если же говорить о науке, то здесь нужно следить за докладами на главных конференциях. 

Виталий: Давайте поговорим о связи между бизнесом и научными исследованиями. В списке ваших работ я нашел несколько статей о согласованности кэша (cache coherence). Насколько я понимаю, во время их публикации алгоритмы согласованности кэша были нестабильными? Или недостаточно распространёнными. Насколько общепринятыми были ваши идеи на практике?

Я довольно много работы проделал с моими студентами Биллом Болоски (William Bolosky) и Леонидасом Контотанассисом (Leonidas Kontothanassis) в начале 1990-х над управлением памятью машин Неймана. Майкл: Я точно не уверен, о каких именно публикациях вы говорите. Билл и Леонидас оба работали в этой области и исследовали подходы без удалённой загрузки кэша. В то время в бизнесе ещё не было понимания того, как правильно сделать многопроцессорную систему: стоит ли создавать поддержку доступа к удалённой памяти на уровне железа, стоит ли делать память распределённой, можно ли выполнять загрузку кэша из удалённой памяти, или необходимо перемещать страницы в операционной системе. В общем, Билл и Леонидас проделали важную работу, хотя и не наиболее влиятельную в это области — в то время над этим же трудилось много других людей. Это напрямую не относилось к согласованности кэша, но всё же это была работа над управлением памятью NUMA, и впоследствии из этого выросли современные подходы к page placement в современных операционных системах. Группа, вместе с которой я работал над этой проблемой, получила в итоге несколько патентов. Позднее я занимался темой, связанной с согласованностью кэша в контексте аппаратной транзакционной памяти (hardware transactional memory). Так или иначе, мне сложно судить об их прибыльности.  За ними стоят довольно интересные идеи, но я не думаю, что они в итоге получат практическую реализацию.

Или вы не думаете об этом? Алексей: В этой связи более личный вопрос: насколько для вас важно, чтобы ваши идеи были реализованы на практике?

Мне не кажется, что на этот вопрос есть правильный ответ. Майкл: Я обожаю задавать этот вопрос в интервью с другими людьми, абитуриентами или кандидатами, желающими работать на факультете. Меня проблемы привлекают, потому что они лично мне кажутся интересными, а не из-за их практической пользы. У людей, делающих классные вещи, может быть самая разная мотивация. Так что тут всё непросто. Но с другой стороны, когда какая-нибудь интересная штука всё-таки находит себе применение, мне это очень нравится. Если в итоге она даст практическую отдачу — отлично.  Но в начале работы всё-таки мной движет не идея конечного использования в мире, а стройность идеи и желание её исследовать и посмотреть, что из неё выйдет.

Вы можете сравнить их и определить, что с чем лучше работает. Алексей: Благодаря вашему образованию и опыту вы лучше многих способны оценить ценность чужих идей. Насколько с вашей точки зрения правилен курс, которым идут эти компании? Я уверен, что у вас есть мнение о вещах, используемых сейчас на практике крупными производителями вроде Intel.

Моя работа в основном заканчивается публикациями, а в области операционных систем они оцениваются по показателям производительности: скорость, потребление энергии, размер кода. Майкл: Практика всегда вращается вокруг того, что может иметь коммерческий успех, то есть создавать прибыль, и об этом вам лучше спросить кого-нибудь другого. Исследователи оценивают решения с художественной стороны, им важно, насколько идеи элегантны, и они стараются создать нечто лучше, чем уже существующие подходы. Но мне всегда казалось, что эти эмпирические результаты добавляются в статьи только для того, чтобы их можно было опубликовать, а реальные мотивы для работы у людей эстетические. Но в самой статье об этом не напишешь, для программного комитета эти вещи не являются аргументами. Исследователями движут личные, субъективные, эстетические мотивы. Мы вместе с десятком моих коллег обсуждали эту тему где-то 15 лет назад и в итоге написали написали об этом статью. К счастью, элегантные решения чаще всего также оказываются быстрыми и дешёвыми. Это единственная статья, в которой я автор вместе с Сашей Фёдоровой, так что если вы сделаете поиск её имени в моём списке публикаций, то найдёте то, что нужно. Думаю, сейчас её ещё можно найти, она называется «How to evaluate systems research» или что-то в таком роде, у неё больше десятка авторов. Там говорится об оценке исследований систем и о том, насколько важна элегантность. 

В науке оценивается производительность, энергопотребление, TDP, простота реализации и многое другое. Алексей: То есть между стандартом того, что считается хорошим результатом в науке и в бизнесе, существует разница. Есть ли у вас лаборатория с разными машинами и разными архитектурами, в которой можно было ставить эксперименты? Есть ли у вас возможность вести такого рода исследования в университете?

Чаще всего они маленькие, у нас есть небольшой кластер и много многопроцессорных систем с разными ускорителями. Майкл: Да, у нашей кафедры очень много разных интересных машин. В нём около тысячи узлов и двадцати тысяч ядер, всё на Linux. Кроме того, на кампусе есть огромный вычислительный центр, который обслуживает учёных из нескольких десятков различных дисциплин. Так что с железом у нас существенных ограничений нет.  Если возникает потребность, то всегда можно купить немного AWS.

Тогда проблемы были? Алексей: А как обстояло дело тридцать лет назад?

В середине-конце 1980-х считалось, что науке не хватает вычислительных ресурсов. Майкл: Тогда было несколько иначе. Задачей этой программы было предоставить вычислительную инфраструктуру для кафедр Computer Science, и она добилась существенных изменений. Чтобы исправить эту ситуацию, Национальный научный фонд (National Science Foundation) создал программу координированных экспериментальных исследований (Coordinated Experimental Research, CER). На тот момент это был самая большая в мире многопроцессорная система с общей памятью. На предоставленные ею деньги мы в Рочестерском университете купили в 1984 году 128-узловый BBN Butterfly, это было за год до моего появления там. Каждый процессор имел мегабайт памяти, 128 мегабайт оперативной памяти в то время было невообразимым количеством. У неё было 128 процессоров, каждый на отдельной материнской плате, она занимала четыре стойки. На этой машине мы впервые реализовали блокировку MCS. 

Алексей: То есть если я правильно вас понял, то на данный момент проблема с железом решена? 

Есть несколько оговорок: во-первых, если вы занимаетесь архитектурой компьютера на уровне микросхем, то в академической среде это делать сложно, поскольку в бизнесе для этого существуют гораздо более совершенные инструменты. Майкл: В общем и целом — да. В этой области значительно проще быть исследователем в Intel. Если вам нужно что-либо меньше 10 нанометров, то это придётся заказывать у кого-то на стороне. Например, Стивен Свансон (Steven Swanson) создал такое товарищество для новых технологий памяти. Если вы работаете над оптическими связями на чипах или над твердотельной памятью, то вы найдёте в бизнесе технологии, которых пока нет в науке, так что приходится создавать союзы. Кроме того, в науке тяжелее идет развитие наиболее мощных вычислительных систем. Эта форма не всегда работает, но в некоторых случаях она может быть весьма успешной. Самые масштабные проекты с суперкомпьютерами, которые сейчас есть в США, Японии и Китае, все сосредоточены в бизнесе. 

Виталий: Вы уже рассказали о том, как начали работать над алгоритмами синхронизации. У вас есть две очень известных статьи о блокировке MCS и очереди Майкла-Скотта (MS), которые в определённом смысле были реализованы в Java. (Примечание редакции: все публикации можно посмотреть по ссылке). Там эта блокировка была реализована с некоторыми изменениями и получилась блокировка CLH, а очередь была реализована как и задумывалась. Но между публикацией ваших статей и их практическим применением прошло много лет. 

Алексей: Кажется, около 10 лет в случае с очередью.

Майкл: Прежде чем эти фичи появились в стандартной библиотеке Java?

Что вы сделали для того, чтобы это произошло? Виталий: Да. Или ничего не делали?

За несколько лет до её появления я работал с группой Марка Мойерса (Mark Moyers) из Sun Microsystems в их лаборатории под Бостоном. Майкл: Я могу рассказать вам, как очередь MS попала в Java 5. Там я впервые встретил Дага Ли (Doug Lea). Он организовал семинар для своих знакомых, занимавшихся интересными проблемами в многопоточности, поскольку он хотел найти темы, которые можно было бы продать их компании. По ходу дела Даг сказал, что он хотел бы использовать очередь MS, но для этого ему был необходим счётчик количества элементов в очереди для интерфейса. Даг, я и ещё где-то 25 других людей из Sun вместе обсуждали презентацию Дага о JSR 166, который впоследствие стал java.util.concurrent. Я предложил просто добавить серийные номера к узлам, взять номер первого узла и последнего и отнять один от другого. То есть это должен был делать отдельный метод, атомарный, точный и быстрый. Мы обсуждали с ним реализацию этого подхода в библиотеке, но большую часть работы Даг сделал сам. Даг почесал голову, сказал «почему бы и нет», и в итоге так и поступил. В итоге ему удалось наладить отличную поддержку многопоточности в Java. 

Алексей: То есть если я правильно понимаю, метод .size() должен был входить в стандартный интерфейс очереди, и у него должна была быть алгоритмическая сложность O(1)?

Майкл: Да, и помимо этого необходим отдельный счётчик.

Понятно, спасибо. Алексей: Потому что если вызвать метод .size() в Java, ожидается, что результат будет доступен сразу же, а не в зависимости от реального размера коллекции.

Даг подошёл к нам и сказал, что они пригодились бы ему в Java Executor Framework. Майкл: Несколькими годами позже я работал над двойными структурами данных (dual data structures) с моим студентом Биллом Шерером (Bill Scherer) — собственно, о них будет мой доклад на Hydra. Я консультировал их по этому проекту, хоть и не участвовал в написании собственно кода. Вместе с Биллом они создали две реализации, так называемые честные и нечестные очереди (fair and unfair queues). В итоге скорость executors существенно увеличилась. 

Вообще практика должна совпадать с теорией, но достаточно часто они отличаются. Владимир: Сталкивались ли вы с неверными реализациями ваших алгоритмов или с просьбами добавить новые фичи? Были ли у вас такие ситуации? Предположим, вы написали алгоритм, и на бумаге он работает, но люди, которые занимаются реализацией, стали просить у вас больше фич или какой-либо настройки алгоритма.

Но было несколько случаев, когда в соответствии с практическими нуждами вносились интересные изменения. Майкл: Единственный пример, в котором ко мне подошли и спросили «как реализовать» — это вопрос Дага, о котором я уже рассказывал. Благодаря этому стандартному интерфейсу идея, красивая в теории, стала работать на практике. Например, команда K42 из IBM конвертировала блокировку MCS и сделала стандартный интерфейс, благодаря которому не было необходимости передавать туда и обратно узел очереди подпрограммам acquire и release. Замысел был прекрасным, и я при возможности стараюсь о нём рассказывать.  Удивительно, что они так и не опубликовали об этом статью, а патент хоть и получили, но потом от него отказались.

Например, в очереди MS есть двухэтапный механизм установки, а это значило, что на критическом пути очереди было два CAS. Были и другие случаи, когда люди вносили улучшения в опубликованные мной алгоритмы. В последнее время Intel и другие производители неплохо их оптимизировали, но когда-то это были инструкции с 30 циклами, поэтому больше одной на критическом пути иметь было нежелательно. На старых машинах CAS были довольно дорогими. Это достигалось благодаря тому, что в течение определённого промежутка времени операция могла занять O(n) времени, а не O(1). В результате была разработана отличная очередь, которая была похожа на очередь MS, но у которой была только одна атомарная операция на критическом пути. Происходило это из-за того, что в определённые моменты алгоритм совершал обход очереди с начала и до текущего положения в этой очереди. Это было маловероятно, но возможно. Насколько я знаю, он не очень широко используется, отчасти потому, что атомарные операции требуют значительно меньше ресурсов, чем раньше. В целом, алгоритм получился очень удачный. Мне также очень нравится работа Дейва Дайса (Dave Dice) из Oracle. Но идея была отличная. Он приложил руку к значительной части NUMA-aware алгоритмов синхронизации и многопоточных структур данных.  Всё, что он делает, очень практично, и он очень ловко использует железо.

Сообществу нужно какое-то время, чтобы ознакомиться, скажем, с новой статьей. Владимир: Когда вы пишете алгоритмы или учите студентов, результат работы виден не сразу. Новый алгоритм далеко не сразу находит себе применение. 

Думаю, было бы интересно провести исследование статей, завоевавших награды на конференциях. Майкл: Далеко на сразу понятно, окажется ли статья значимой или нет. Нужно попробовать посчитать по количеству ссылок и по влиянию на бизнес, насколько эти статьи действительно оказалась влиятельными через 10, 20, 25 лет. То есть посмотреть на статьи, которые люди в программных комитетах в своё время сочли самыми лучшими. Она не будет нулевая, но, скорее всего, она будет значительно слабее, чем хотелось бы. Я сомневаюсь, что между этими двумя параметрами была бы сильная корреляция. Например, возьмём транзакционную память. Многие идеи в течение долгого времени остаются невостребованными, прежде чем получают распространение. А до появления этой памяти в коммерческих продуктах — и все 20. С момента публикации изначальной статьи до того времени, когда люди действительно стали создавать машины с ней, прошло больше 10 лет. Заранее это предсказать было бы сложно. Очень долго на статью никто не обращал внимания, а потом резко выросло количество ссылок на неё. Несколько лет назад я написал статью вместе с Джо Израелевичем (Joe Izraelevitz) для DISC, в которой было предложено новое формальное определение правильности для персистентных структур данных, которые могли бы использоваться после сбоя работающего с ними компьютера. С другой стороны, иногда идеи находят реализацию сразу же. Ей воспользовалось несколько различных групп, и в итоге она стала стандартным определением персистентных структур. Статья мне нравилась с самого начала, но она оказалась значительно более популярной, чем я ожидал. Что, конечно, приятно.

Пытаетесь ли вы вообще оценивать свои статьи, своих студентов? Владимир: А есть ли какие-то приёмы, которые вы используете для оценки? В плане того, идёт ли человек, которого вы учили, в правильном направлении.

Опять-таки, как и все, я изредка проверяю Google Scholar и смотрю, цитируются ли мои прошлые статьи, но это скорее из любопытства. Майкл: Как и все, я больше внимания уделяю тому, чем занимаюсь в данный момент. Что касается оценки текущей работы, то отчасти тут работают соображения эстетики, что элегантно, а что — нет. В основном я поглощён тем, что мои студенты делают сейчас. Например, ко мне приходит студент с графиком неких результатов, и мы пытаемся понять, откуда взялось некоторое странное поведение графика. А на повседневном уровне большую роль играют открытые вопросы. В целом, в нашей работе мы постоянно пытаемся разобраться в вещах, которые пока не понимаем. 

Виталий: Может, немного поговорим о транзакционной памяти?

Это тема, по которой у меня больше публикаций, чем по любой другой. Майкл: Думаю, стоит сказать хотя бы немного, потому что я вложил в это очень много усилий. На мой взгляд, статья Херлихи и Мосса (M. Но при этом, как это ни странно, я всё время был весьма скептично настроен по отношению к транзакционной памяти. E. Herlihy, J. Moss) была опубликована раньше своего времени. B. То есть это было бы подспорье для Дагов Ли, занимающихся своими JSR 166. В начале 1990-х они предположили, что транзакционная память могла бы помочь талантливым программистам, работающим над многопоточными структурами данных, чтобы эти структуры затем в качестве библиотек могли бы использоваться обычными программистами. А ведь её именно так стали воспринимать в начале 2000-х, когда она получила распространение. Но транзакционная память не предназначалась для того, чтобы сделать многопоточное программирование простым. Этот подход мне всегда казался безнадежным. Её рекламировали как способ решить проблему параллельного программирования. Этого она, как мне кажется, и достигла.  Транзакционная память могла только упростить написание параллельных структур данных.

Алексей: Очень интересно. Кажется, есть определённый барьер между обычными программистами и теми, кто может писать многопоточный код. В прошлом году я несколько раз общался с людьми, которые занимались реализацией некоторого алгоритмического фреймворка. Например, с Мартином Томсоном, а также с программистами, работающими над многопоточными библиотеками.  (Примечание редакции: Мартин Томпсон — очень известный разработчик, он написал Disruptor и Aeron. А ещё у него есть доклад на нашей конференции Joker 2015, видеозапись доступна на YouTube. Он же открывал эту конференцию, запись кейноута тоже достуна). По их словам, главная трудность в том, чтобы алгоритмы были одновременно быстрыми и простыми в использовании. То есть они пытаются как раз преодолеть этот барьер и привлечь как можно больше людей в эту область. Что вы об этом думаете?

Майкл: Это главная проблема многопоточности: как добиться высокой производительности, не увеличивая сложности системы. 

Алексей: Потому что когда они пытаются избежать сложности, алгоритм становится менее универсальным.

Мне кажется, что это вообще главное для компьютерных систем как области. Майкл: Здесь главное — правильно спроектированные абстракции. Простых технологий сегодня не существует. Этот термин любит употреблять Батлер Лэмпсон (Butler Lampson), и нас он называет «торговцами абстракциями». При этом ISA значительно проще процессора, поскольку мы очень долго работали над тем, чтобы обеспечить для неё высокую производительность и относительно простой интерфейс. В процессорах, которые мы используем, по 10 миллиардов транзисторов — о простоте тут речи быть не может. Та же проблема с ускорителями, которые сейчас появляются на рынке. Но и с ней не всё гладко. Как сделать интерфейс, который обеспечит простоту использования инструмента и скроет сложность? Возникают вопросы — как сделать правильный интерфейс для GPU, механизм шифрования, сжатие, механизм перекодирования, механизм линейной алгебры или даже более гибкую FPGA. Не избавится от неё, а именно скроет от простого программиста. 

Возьмём модель памяти, на нашем этапе развития науки и техники это одна из главных абстракций. Алексей: Я так понимаю, что у нас есть ещё барьер в понимании абстракций. Благодаря ей все программисты делятся на две группы: большая часть — это те, кто её не понимают, и меньшая — те, кто понимают, или думают, что понимают. 

Майкл: Это хороший вопрос — действительно ли кто-либо из нас понимает модель памяти.

Виталий: В особенности в C++.

Это один из самых умных людей, которых я знаю, ведущий эксперт по моделям памяти. Майкл: Поговорите как-нибудь с Хансом Бёмом (Hans Boehm). Но если возвращаться к вопросу абстракций, то, на мой взгляд, самая важная мысль в области моделей памяти за последние 30 лет была высказана в диссертации Сарита Адве. Он вам сразу же скажет, что он очень многого там не понимает. (Примечание редакции: полный список публикаций есть по ссылке).

Алексей: Мой вопрос такой: происходит ли этот барьер из самой природы понятия? 

Сарита пришёл к выводу, что при правильном подходе можно успешно скрыть всю сложность, получить высокую производительность и дать программисту простой API. Майкл: Нет. Я считаю, что это правильная модель. И если следовать этому API, то можно добиться последовательной согласованности. Конечно, для того, чтобы уменьшить вероятность гонок, нужны специальные инструменты, но это уже другой вопрос.  Пишете код без гонок данных и получаете последовательную согласованность.

Например, в теории можно факторизовать любое число или определить, является ли любое число простым. Владимир: Были ли в вашей карьере случаи, когда проблема, которая казалась решённой, вдруг оборачивалась целой катастрофой, или выяснялось, что эта проблема нерешаема? Происходило ли нечто подобное с вами? Но на практике это бывает сложно сделать, с существующим сейчас железом сложно факторизовать числа.

Бывало, когда мне казалось, что в некоторой сфере делать уже нечего, а потом там происходило что-то новое и интересное. Майкл: Сходу ничего подобного не вспоминается. После нескольких улучшений для очереди MNS ничего особенного уже не происходило. Например, я думал, что в области неограниченных очередей уже достигнута зрелость. Стало ясно, что возможна неограниченная многопоточная очередь, у которых большую часть времени на критическом пути была только инструкция fetch-and-increment. А потом Моррисон (Adam Morrison) и Афек (Yehuda Afek) изобрели очередь LCRQ. Не то что бы мы не знали, что fetch-and-increment очень полезная вещь. И это позволяло добиться на порядок лучшей производительности. Моррисон и Афек смогли использовать fetch-and-increment в неограниченной очереди. Эрик Фрейдентал (Eric Freudenthal) писал об этом в своей работе об Ultracomputer c Аланом Готтлибом (Allan Gottlieb) в конце 1980-х, но там речь шла об ограниченных очередях.

Владимир: Следите ли вы за новыми архитектурными решениями, которые могли бы быть полезны для алгоритмов? 

Майкл: Конечно, есть множество вещей, которые мне хотелось бы, чтобы были реализованы. 

Владимир: А какие, например?

В особенности мне хотелось бы, чтобы не-транзакционные только что произошедшие load и store были сразу же доступны внутри транзакций. Майкл: В первую очередь — несколько простых расширений для нашей транзакционной памяти аппаратного уровня в процессорах Intel и IBM. Но если поддерживать уровни абстракции, существует множество очень интересных вещей, которые можно сделать за пределами транзакции, пока она происходит. Они сразу же приводят к циклам в последовательности happens-before, так что с ними могут быть сложности. Я не знаю, насколько трудно это было бы реализовать, но это было бы очень полезно. 

Думаю, рано или поздно это будет сделано. Другая полезная вещь — загрузка кэша из удалённой памяти. Можно будет держать, скажем, 100 терабайт энергонезависимой памяти в стойке, и операционная система сама будет динамически решать, какие разделы этой памяти должны соответствовать физическому адресному пространству процессоров. Эта технология позволит создавать системы с дезагрегированной памятью. Думаю, кто-нибудь это да сделает. Это было бы крайне полезно для облачных вычислений, поскольку позволило бы предоставлять большие объемы памяти тем задачам, которые в ней нуждаются.

Вытеснит ли транзакционная память в конечном итоге стандартные многопоточные структуры данных? Виталий: Чтобы закончить разговор о транзакционной памяти, у меня есть ещё один вопрос по этой теме.

Транзакции — это спекулятивный механизм. Майкл: Нет. Такое прогнозирование работает в том случае, если большая часть догадок верные. На уровне программирования это атомарные блокировки, а внутри — спекуляции. Но если между тредами начинается сообщение, от транзакций мало пользы. Поэтому транзакционная память хорошо работает тогда, когда потоки почти не взаимодействуют друг с другом, и нужно просто убедиться в том, что взаимодействий нет. Они всё равно могут с успехом использоваться как составные части для многопоточных структуры данных. Поясню, речь идёт о случае, когда транзакции обёрнуты вокруг всей атомарной операции. В общем, транзакции могут быть полезными, но от необходимости правильно проектировать многопоточные структуры данных они не избавят. 
Например, если необходим CAS из трёх слов, и нужно выполнить в режиме многопоточности три небольших вещи посреди действительно многопоточного алгоритма, который работает с двадцатью тредами одновременно.

Виталий: Последнее, о чём я хотел бы поговорить — это тема ваших текущих исследований: энергонезависимая память. Чего можно в этой области ожидать в ближайшем будущем? Возможно, вам известны какие-либо уже существующие эффективные реализации? 

Все уже слышали, что Intel продаёт Optane DIMM, у которых где-то в 3 раза больше задержка чтения и в 10 раз больше задержка записи, чем у динамических RAM. Майкл: Я не эксперт по железу, я знаю только то, что читаю в новостях и что мне рассказывают коллеги. Забавно думать о том, что можно будет иметь ноутбук с несколькими терабайтами адресуемой в байтах RAM. В скором времени они будут доступны в версиях с очень большим объемом. Но благодаря энергонезависимости у нас открываются совершенно новые возможности. Вполне вероятно, что через 10 лет мы решим использовать эту новую технологию, так как мы используем DRAM — просто наращивать объёмы. Таким образом, нам не нужно будет сериализовать в блочно-структурированные файлы всё, что нужно — перенести из одного запуска программы в другой. Мы можем в корне изменить стек хранения данных, чтобы не было разделения между адресуемой в байтах рабочей памятью и блочно-структурированной персистентной памятью. В этой области очень интересно работать. Из этого можно вывести множество важных принципов, влияющих на операционные системы, среды выполнения и распределенные хранилища данных. Возможно, здесь произойдут революционные изменения, и они очень естественным образом следуют из работы над многопоточностью, поскольку восстановление после сбоя является «многопоточным» процессом рядом с обычной работой системы.  Лично мне сложно предсказать, во что это всё выльется, но проблемы здесь крайне занимательные.

В последние годы наблюдается тренд перемещать доступ к устройству в юзерспейс. Вторая главная тема, над которой я сейчас работаю — это управление сверхбыстрыми устройствами и безопасный доступ к устройствам из юзерспейса с системным контролем над политикой. Поэтому производители предоставляют прямой доступ к устройствам. Это делается из-за того, что поверх сетевого интерфейса, которому нужен новый пакет каждые 5 микросекунд, не может функционировать TCP-IP стек ядра, он просто не будет успевать. Наша исследовательская группа считает, что этого недостатка можно избежать. Но это значит, что операционная система теряет контроль над процессом, и она не может обеспечить правильный доступ к устройству для соревнующихся приложений. Она связана с работой над персистентностью, поскольку долговечная адресуемая в байтах персистентная память является, в сущности, устройством со сверхбыстрым I/O, к которому нужно предоставить доступ в юзерспейсе. На USENIX ATC в этом месяце будет наша статья об этом. Эти исследования делают возможными новые подходы к микроядрам, экзоядрам и прочим другим традиционным попыткам безопасно перенести функциональность из ядра ОС в юзерспейс. 

А это значит, что неизбежно будет задержка при взаимодействии с устройством.  Владимир: Адресуемая в байтах память — это прекрасно, но есть ведь физическое ограничение — скорость света.

Майкл: Совершенно верно.

Владимир: Хватит ли мощностей для того, чтобы справиться с новыми нагрузками?

Уже довольно давно существует идея обработки в памяти, она очень интересная, но и очень сложная. Майкл: Это отличный вопрос, но мне на него сложно будет что-либо ответить. Боюсь, больше мне добавить нечего.  Я в этой области не работал, но было бы здорово, если бы там были сделаны какие-то открытия.

Новые, значительно большие объемы RAM будет невозможно разместить в CPU. Владимир: Есть ещё одна проблема. Поэтому из-за физических ограничений эта RAM должна быть изолированной. 

Если бы можно было создавать полупроводниковые пластины целиком без дефектов, то из неё можно было бы целиком сделать микросхему. Майкл: Здесь всё зависит от количества дефектов при производстве интегральных схем. Но сейчас мы не умеем делать микросхемы больше почтовых марок. 

Это неизбежно оказывает влияние на задержку.  Владимир: Но речь всё равно идёт об огромных размерах, о сантиметрах.

Со скоростью света ничего не поделаешь.  Майкл: Да.

Владимир: К сожалению. 

Виталий: Насколько я понимаю, вы очень быстро улавливаете новые тренды. Вы были одним из первых, кто стал заниматься транзакционной памятью, и одним из первых в энергонезависимой памяти. Как вы думаете, какой будет следующий важный тренд? Или, возможно, это секрет?

Надеюсь, мне удастся заметить, когда возникнет что-то новое. Майкл: Честно говорю, что не знаю. Надеюсь, мне это будет удаваться и в будущем. Мне не посчастливилось изобрести в одиночку какую-либо новую область, но несколько раз повезло, и я смог довольно рано начать работать в новых сферах, созданных другими.

Если я правильно понял, то доклад на школе будет про алгоритмы без блокировки, а на конференции про двойные структуры данных. Алексей: Последний вопрос в этом интервью будет про ваше выступление на Hydra и занятие в школе. Не могли бы вы сказать пару слов об этих докладах?

Речь пойдёт о работе, которую я вел с моим студентом Биллом Шерером. Майкл: Отчасти мы уже затрагивали эти темы с вами в этом интервью. Предположим, происходит чтение и запись в структуру данных без блокировки, то есть у каждой операции есть ограниченное число инструкций на критическом пути. Он написал на основе неё диссертацию, и в ней также участвовал Даг Ли, а в конечном итоге она стала частью многопоточных синхронных очередей в библиотеке Java. Но такое поведение может быть недопустимо, если эти данные очень нужны треду. Если попытаться изъять данные из пустого контейнера, или попытаться изъять определённые данные, которых в этом контейнере нет, то тут же сообщается, что это сделать невозможно. Но тогда возникают помехи для всех остальных. Тогда первое, что приходит в голову — это создать цикл, который будет постоянно спрашивать, не появились ли необходимые данные. В двойных структурах данных по-прежнему нет блокировок, но они позволяют правильно организовать ожидание тредов. Кроме того, при таком подходе можно ждать 10 минут, а потом придёт какой-то другой тред, и он случайно получит необходимые данные первым. Так что если попытаться извлечь что-то из пустого контейнера, то вместо этого в контейнер будет положен запрос. Термин «двойная» означает, что структура содержит либо данные, либо запросы на данные, назовём их анти-данные. Кроме того, структура данных назначает запросам приоритеты, так что при получении она передаёт их тому, кому следует. Теперь тред может ожидать запроса и при этом никого другого не беспокоить. Получается механизм без блокировки, который при этом имеет формальную спецификацию и хорошую производительность на практике. 

Позволит ли она улучшить производительность во всех типичных случаях, или она лучше подходит для определённых ситуаций?  Алексей: Какие ваши ожидания от этой структуры данных?

Насколько мне известно, наша структура обеспечивает оптимальное поведение в случае, когда соблюдаются эти два условия. Майкл: Она полезна в случае, если, во-первых, необходим контейнер без блокировки, и, во-вторых, нужно ждать в ситуации, когда из контейнера необходимо извлечь данные, которых в нём нет. Главное преимущество структур данных без блокировки в том, что они позволяют избежать проблем с производительностью. Поэтому в этих случаях я рекомендую её использовать. А ожидание очень важно во многих алгоритмах, если происходит передача данных из одного треда в другой.

Виталий: Позвольте уточнить: вы будете говорить об одном и том же и в школе, и на конференции?

Я подразумеваю, что аудитория знает, что такое потоки, и знакома с блокировками. Майкл: На школе я буду говорить в целом о многопоточных структурах данных, с изложением основных принципов в начале занятия. Я дам обзор наиболее важных проблем в этой области, затрону темы вроде управления памятью. Ориентируясь на эти базовые знания, я буду рассказывать о структурах данных без блокировок. Не думаю, что там будет что-либо сложнее очереди MS.

Алексей: Планируете ли вы рассказать о двойных структурах данных в конце вашего занятия в школе?

Им будет посвящен доклад на Hydra. Майкл: Я их упомяну, но много времени уделять им не буду. Там будет рассказано о проекте, который в итоге вошёл в Java, а также о работе с Джо Израелевичем над созданием двойного варианта очереди LCRQ, и о создании почти универсальной конструкции для двойных структур данных.

Алексей: То есть лекцию в школе можно порекомендовать для новичков, а лекцию о двойных структурах данных на Hydra — для людей, уже имеющих какой-то опыт?

Майкл: Поправьте меня, если я не прав, но аудитория на Hydra будет довольно разноплановой, в том числе там будет много экспертов по Java, и вообще людей, которые специально многопоточным программированием не занимаются. 

Виталий: Да, это верно.

Алексей: По крайней мере, мы на это надеемся.

Майкл: В этом случае передо мной будет та проблема, с обсуждения которой мы начали это интервью: как сделать доклад одновременно в достаточной степени насыщенным техническими подробностями и доступным всем слушателям.

То есть разговаривать с аудиторией и адаптироваться по ситуации? Виталий: Будете ли вы вести доклад так, как ведете лекции?

Слайды важны, когда слушатели изначально говорят на разных языках. Майкл: Боюсь, так не получится, потому что доклад будет со слайдами. Я выбрал именно эти темы, потому что Пётр Кузнецов попросил меня рассказать о структурах данных без блокировки на Школе SPTDC; а потом стал нужен доклад для конференции юзер-группы Java, и я хотел выбрать что-то, что было бы интересно именно программистам Java. Многим будет сложно понять меня на английском, в особенности если я буду говорить слишком быстро. Проще всего было рассказать о тех вещах в библиотеке Java, к которым я так или иначе приложил руку. 

Но это только предположение, ситуация станет более ясной уже на самой конференции. Алексей: Мы предполагаем, что аудитория на Hydra уже что-то знает о программировании без блокировок и, возможно, имеет какой-то опыт в этой области. Я уверен, интервью будет очень интересным нашим читателям. Так или иначе, спасибо за то, что уделили нам время. Спасибо большое!

Виталий: Спасибо. 

Майкл: Я буду рад встретиться с вами в Санкт-Петербурге. 

Вы здесь когда-нибудь были? Алексей: Мы тоже, у нас красивый город.

Но Санкт-Петербург всегда входил в список мест, где я ещё не был, но где очень хочу побывать, поэтому я очень обрадовался приглашению.  Майкл: Нет, я вообще в России ни разу не был.

Спасибо большое за интервью, и удачного вам дня! Алексей: Кстати, у нас будет программа экскурсий для докладчиков.

Он приедет с докладом «Dual data structures». Продолжить общение с Майклом можно будет на конференции Hydra 2019, которая пройдёт 11-12 июля 2019 года в Санкт-Петербурге. Билеты можно приобрести на официальном сайте.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть