«Эмпирические результаты лишь для публикации, реальные мотивы работ — эстетические». Большое интервью с Майклом Скоттом
Майкл Скотт — уже 34 года как профессор Computer Science в Рочестерском университетe, а в родном универститете Wisconsin–Madison был деканом в течение пяти лет. Он занимается исследованиям в области параллельного и распределённого программирования и дизайна языков и обучает этому студентов.
Мир знает Майкла по учебнику «Programming Language Pragmatics», а работа «Algorithms for scalable synchronization on shared-memory multiprocessors» получила премию Дейкстры как одна из наиболее известных в области распределённых вычислений. Также вы можете знать его как автора того самого алгоритма Майкла-Скотта.
Вместе с Дагом Ли разработал те неблокирующие алгоритмы и синхронные очереди, на которых работают библиотеки Java. Внедрение «dual data structures» в JavaSE 6 позволило в 10 раз улучшить производительность ThreadPoolExecutor.
Содержание:
- Начало карьеры, Рочестерский университет. Проект Charlotte, язык Lynx.
- IEEE Scalable Coherent Interface, блокировка MCS.
- Выживание в постоянно меняющемся мире.
- Становятся ли студенты глупее? Глобальные тренды, интернационализация.
- Эффективная работа со студентами.
- Как не отстать при подготовке новых курсов и книг.
- Связь между бизнесом и академией.
- Практическая реализация идей. MCS, MS, CLH, JSR 166, работа с Дагом Ли и многое другое.
- Транзакционная память.
- Новые архитектуры. Близкая победа транзакционной памяти.
- Энергонезависимая память, Optane DIMM, сверхбыстрые устройства.
- Следующий большой тренд. Dual data structures. Hydra.
Виталий Аксенов — на данный момент, пост-док в IST Austria и сотрудник кафедры «Компьютерные Технологии» Университета ИТМО. Занимается исследованиями в области теории и практики конкурентных структур данных. До работы в IST, он получил PhD в Университете Париж Дидро и в Университете ИТМО под руководством профессора Петра Кузнецова.
Алексей Федоров — продюсер в JUG Ru Group, российской компании, которая занимается организацией конференций для разработчиков. Алексей участвовал в подготовке более чем 50 конференций, а в его резюме есть всё что угодно, начиная от позиции инженера-разработчика в Oracle (JCK, Java Platform Group), и заканчивая позицией деврела в компании Одноклассники.
Владимир Ситников — инженер в компании Netcracker. Десять лет работает над производительностью и масштабируемостью NetCracker OS — ПО, используемого операторами связи для автоматизации процессов управления сетью и сетевым оборудованием. Увлекается вопросами производительности Java и Oracle Database. Автор более десятка улучшений производительности в официальном PostgreSQL JDBC-драйвере.
Алексей: Для начала я хотел рассказать вам, что мы в России все очень любим Сomputer Science, Data Science и алгоритмы. Прямо до неприличия. Мы все читали книгу Cormen, Leiserson и Rivest. Поэтому предстоящая конференция, школа и само это интервью должны пользоваться большой популярностью. Нам поступило множество вопросов для этого интервью от студентов, программистов и членов сообщества, поэтому мы очень благодарны вам за эту возможность. Пользуется ли Computer Science такой же любовью в США?
Майкл: Наша область настолько разносторонняя, в ней так много направлений, и она влияет на общество такими различными способами, что мне сложно ответить вам однозначно. Но факт в том, что благодаря ей за последние 30 лет произошли колоссальные изменения в бизнесе, промышленности, искусстве и обществе в целом.
Виталий: Давайте начнём с чего-нибудь отдаленного. Во многих университетах наблюдается нечто вроде специализации на одном определённом направлении. Для университета Карнеги-Меллона это параллельные вычисления, для MIT — криптография, роботы и многопоточность. А есть ли подобного рода специализация в Рочестерском университете?
Майкл: Если честно, я бы сказал, что CMU и MIT специализируются по всем направлениям. На нашей кафедре всегда больше всего внимания уделялось искусственному интеллекту. Половина работающих у нас людей занимаются ИИ или человеко-компьютерным взаимодействием — эта доля больше, чем на других кафедрах, и так было всегда. Но когда я учился в университете, у меня не было курсов по ИИ, и я никогда в этой области не работал. Так что моя кафедра специализируется на проблеме, к которой я отношения не имею. Утешением служит то, что вторая по важности для нашей кафедры проблема — это параллельное и многопоточное программирование, то есть моя специализация.
Виталий: Вы начали заниматься Computer Science, когда область многопоточного программирования только зарождалась. По списку ваших публикаций видно, что первые работы касались достаточно широкого спектра вопросов: управление памятью в многопоточных системах, распределенные файловые системы, операционные системы. Почему такая разносторонность? Вы пытались найти своё место в исследовательском сообществе?
Майкл: Будучи студентом, я участвовал в проекте Charlotte в университете Висконсина, в рамках которого разрабатывалась одна из первых распределенных операционных систем. Там я работал вместе с Рафаэлем Финкелем (Raphael Finkel) и Марвином Соломоном (Marvin Solomon). Моя диссертация была посвящена разработке языка для системного софта для распределенных систем — сейчас про нее все уже забыли, и слава богу. Я создал язык программирования Lynx, который должен был упростить создание серверов для распределенной операционной системы со слабым связыванием. Поскольку на тот момент я в основном занимался операционными системами, то предполагал, что и моя карьера будет в основном связана с ними. Но в Рочестере университет был очень маленький, и из-за этого разные группы там очень тесно общались друг с другом. Там не было десятка других специалистов по операционным системам, с которыми я мог бы общаться, так что все контакты были с людьми, которые работали в совершенно других областях. Мне это очень нравилось, быть универсалом — большое преимущество для меня. Если же говорить конкретно о многопоточных структурах данных и алгоритмах синхронизации, то ими я начал заниматься совершенно случайно.
Виталий: Можно немного подробней об этом?
Майкл: Это забавная история, которую я не устаю всем рассказывать. Она произошла на конференции ASPLOS в Бостоне — это было в конце 80-х или в начале 90-х. На конференции присутствовал Джон Меллор-Крамми (John Mellor-Crummey), выпускник нашего факультета. Я был с ним знаком, но мы до этого не вели совместных исследований. Мэри Вернон (Mary Vernon) из Висконсина выступала с докладом о многопроцессорной системе, которую они разрабатывали в Висконсине: Wisconsin Multicube. В этом Multicube на уровне железа был механизм синхронизации, который назывался Q on Sync Bit, а позднее он был переименован в Q on Lock Bit, потому что так его можно было произносить как название сыра Colby, то есть это был такой каламбур. Если вы интересуетесь механизмами многопоточности, вы, наверное, знаете, что Colby в конченом итоге стал механизмом синхронизации стандарта Scalable Coherent Interface от IEEE. Это был механизм блокировки, который создавал указатели из одного кэша на другой на уровне железа, чтобы каждый держатель блокировки знал, чья за ним очередь. Когда Джон и я об этом услышали, мы переглянулись и сказали:, а зачем это делать на уровне железа? Разве нельзя того же самого добиться при помощи compare-and-swap? Мы взяли один из блокнотов, лежавших в аудитории, и набросали на нём блокировку MCS, пока Мэри продолжала свой доклад. В последствии мы её реализовали, поэкспериментировали, идея оказалась удачной, и мы опубликовали статью. Тогда для меня эта тема казалась лишь забавным отвлечением, после которого я планировал вернуться к операционным системам. Но затем возникла другая проблема в том же направлении, и в конечном итоге синхронизация, многопоточность и структуры данных стали моей основной специальностью. Как видите, произошло это всё по случайности.
Виталий: Я давно знаком с блокировкой MCS, но до текущего момента я не знал, что это Ваша работа, и не понимал, что это акроним от Ваших фамилий.
Алексей: У меня есть вопрос по связанной теме. 30 или 40 лет назад было больше свободы в разных специальностях. Хочешь начать карьеру в многопоточности или распределенных системах — пожалуйста, хочешь заняться операционными системами — никаких проблем. В каждой области было очень много открытых вопросов и мало экспертов. Сейчас появились узкие специализации: нет просто экспертов по операционным системам в целом, есть специалисты по отдельным системам. То же самое с многопоточностью и распределенными системами. Но проблема в том, что наши жизни не бесконечные, каждый может посвятить исследованиям лишь несколько десятилетий. Как выжить в этом новом мире?
Майкл: Мы в этом плане не особенные, всё то же самое происходило когда-то и в других областях. Мне повезло, что я начал работать в Computer Science, когда эта сфера была в «подростковом» возрасте. Некоторые основы уже были заложены, но все было еще очень незрелое. Такая возможность появляется нечасто. Электротехника существует уже очень давно, физика — еще дольше, математика — чуть ли не с начала времён. Но это не значит, что в математике никто больше не делает интересных открытий. Открытых проблем по-прежнему множество, но в то же время и учиться нужно больше. Вы верно заметили, что сейчас значительно больше специализаций, чем было раньше, но это лишь значит, что мы оказались в той же ситуации, что и большинство остальных областей человеческой деятельности.
Алексей: Меня здесь интересует более практический аспект вопроса. У меня математическое образование, и во время учёбы я часто посещал конференции и работал над различными научными темами. Я обнаружил, что мои доклады никто в аудитории не понимал, и точно так же, доклады других людей были понятны только для них самих. В высокоуровневых темах это не так, но как только начинаешь во что-либо углубляться, аудитория за тобой перестаёт успевать. Как вы с этим боретесь?
Майкл: Не всегда успешно. Недавно я подготовил доклад, в котором ушёл слишком глубоко в технические подробности. По ходу доклада стало видно, что большая часть аудитории меня не понимает, так что мне пришлось приспосабливаться к ситуации на ходу. Слайды было уже не изменить, так что получилось не слишком удачно — поэтому, вообще говоря, я стараюсь слайды не использовать. В целом, мой совет такой — учитывайте свою аудиторию. Нужно знать, к кому вы обращаетесь, какой у них уровень знаний и что им нужно услышать, чтобы оценить вашу работу.
Виталий: А вы не могли бы намекнуть, о чём была эта лекция?
Майкл: Если честно, я предпочёл бы на эту тему не распространяться, чтобы оставить анонимными тех людей, о которых идёт речь. Суть в том, что мы часто погружаемся слишком глубоко в тонкости той проблемы, над которой работаем, поэтому нам становится сложно объяснить в начале доклада, почему эта проблема интересна и важна и как она связана с вопросами, которые слушатели уже знают. По моим наблюдениям, студентам этот навык даётся тяжелее всего. И это же было слабой стороной моего недавнего доклада. Правильно построенный доклад должен с самого начала найти контакт с аудиторией, объяснить ей, в чём именно заключается проблема и как она соотносится с уже известными ей темами. Насколько технической будет эта вступительная часть, зависит от аудитории. Если она совсем разношёрстная, то доклад может быть многоступенчатым. Вступление должно быть доступно всем, а к концу часть, возможно, уже не будет за вами успевать, но люди, относительно знакомые с вашей областью, смогут разобраться во всём.
Алексей: Вы наблюдаете за студентами уже несколько десятков лет. Становятся ли студенты глупее или умнее от десятилетия к десятилетию или от года к году? В России профессоры постоянно жалуются, что студенты с каждом годом глупеют, и прямо-таки непонятно, что с этим делать.
Майкл: От нас, стариков, действительно можно услышать много негатива. Подсознательно у нас есть склонность ожидать, что студенты освоят весь тот 30-летний опыт, который уже есть у нас. Если у меня есть более глубокое понимание, чем в 1985 году, то почему его нет у студентов? Наверное, потому что им 20 лет, как вам такое? Думаю, наиболее существенные изменения в последние десятилетия касаются демографического состава: у нас сейчас значительно больше международных студентов, за исключением канадцев. Раньше канадцев было много, поскольку мы находимся очень близко к границе с Канадой, и студенты оттуда могут ездить домой на выходных. Но сейчас в Канаде много хороших университетов, и канадцы предпочитают учиться у себя, в США их стало ездить значительно меньше.
Алексей: Как вы думаете, это местный тренд или глобальный?
Майкл: Не помню точно кто, но кто-то сказал, что мир плоский. Наша область стала значительно более интернациональной. Конференции ACM раньше проходили исключительно внутри США, потом решили раз в 4 года проводить их в других странах, а сейчас они проходят по всему миру. Ещё в большей степени эти изменения коснулись IEEE, поскольку она всегда была более интернациональной организацией, чем ACM. А руководители программ (program chairs) есть из Китая, Индии, России, Германии и многих других стран, потому что везде сейчас очень много чего происходит.
Алексей: Но, вероятно, есть какие-то негативные стороны такой интернационализации?
Майкл: Я бы сказал, что все негативные стороны касаются не техники, а политики. Когда-то главной проблемой был тот факт, что США крали самых умных и талантливых людей у стран во всём мире. А сейчас основная проблема — это политические игры между разными странами вокруг виз и иммиграции.
Алексей: То есть барьеры и тому подобные вещи. Понятно.
Владимир: Лично мне интересно, какого подхода вы придерживаетесь, когда преподаете новый предмет студентам. Есть ведь разные варианты: можно стараться в первую очередь вдохновить их попробовать что-то новое, а можно больше внимания уделять подробностям того, как устроена определенная технология. Что предпочитаете вы?
Алексей: И как найти чёртов баланс между первым и вторым?
Майкл: Проблема в том, что занятия не всегда проходят так, как мне хотелось бы. Обычно я заранее даю студентам материал для чтения, чтобы они в него вникли, по мере сил разобрались и сформулировали вопросы по тем местам, которые понять не удалось. Тогда в классе можно сосредоточиться именно на наиболее трудных моментах и исследовать их всем вместе. Это то, как мне больше всего нравится вести занятия. Но с учётом той нагрузки, которая сейчас лежит на студентах, мне далеко не всегда получается сделать так, чтобы они подготовились заранее. В итоге приходится уделять общему пересказу материала значительно больше времени, чем хотелось бы. Несмотря на это, я стараюсь, чтобы наши занятия были интерактивными. В противном случае проще один раз записать видео, которое студенты могут затем смотреть у себя дома. Смысл живых занятий — в человеческом взаимодействии. На занятиях я предпочитаю пользоваться не слайдами, а мелом и доской, за исключением отдельных случаев, когда какая-нибудь диаграмма слишком сложная, чтобы её изобразить на доске. Благодаря этому мне нет необходимости придерживаться жёсткого плана занятия. Поскольку нет строго определенного порядка, в котором я даю материал, это позволяет адаптироваться к аудитории в зависимости от вопросов, которые я получаю. В общем, я стараюсь, чтобы занятия были как можно более интерактивными, чтобы излагаемый мной материал зависел от вопросов, которые мне задают.
Владимир: Это очень здорово. По моему опыту довольно сложно добиться от слушателей вопросов. Даже если заранее просишь задавать любые вопросы, не важно, глупые или умные, они всё равно молчат. Как вы с этим справляетесь?
Майкл: Вы будете смеяться, но если достаточно долго молча стоять, то рано или поздно всем станет неудобно, и кто-нибудь да задаст вопрос. Или можно задать простой технический вопрос с ответом «да» или «нет», чтобы определить, поняли ли люди, о чём только что шла речь. Например, есть ли в приведённом примере гонка данных? Кто считает, что да? Кто считает, что нет? Кто вообще ничего не понимает, потому что в общей сложности поднялась только половина рук?
Виталий: И если ты ответил неверно, вылетаешь из класса :-)
Майкл: Если ты не ответил ничего, то должен задать вопрос. Я должен понять, что именно студенту нужно знать, чтобы ответить на вопрос, который я только что задал. Нужно, чтобы они помогли мне помочь им. Я готов подстроиться под них, чтобы они разобрались в проблеме. Но если я не знаю, что происходит у них в голове, я не могу этого сделать. И если достаточно долго не давать студентам покоя, то в итоге иногда они задают правильные вопросы, то есть такие, благодаря которым я вижу, что именно происходит в головах у студентов.
Алексей: Наталкивают ли иногда эти вопросы на идеи, о которых вы сами раньше не думали? Бывают ли они неожиданными? Позволяют ли взглянуть на какую-то проблему в новом свете?
Майкл: Бывают вопросы, благодаря которым открывается новый способ подачи материала. Часто бывают вопросы, которые приводят к интересным проблемам, о которых я не планировал говорить. Студенты мне часто говорят, что у меня есть склонность уходить от темы занятия, когда такое происходит. И, согласно им, очень часто это бывает наиболее интересная часть занятия. Совсем редко, буквально несколько раз, студенты задавали вопросы, которые наталкивали на новое направление в исследовании и вырастали в статью. Это значительно чаще происходит в беседах со студентами, а не во время занятий, но изредка было и во время занятий.
Алексей: То есть студенты задавали вам вопросы, на основе которых потом можно было опубликовать статью?
Майкл: Да.
Виталий: Насколько часто у вас происходят такие беседы со студентами? Когда они хотят узнать больше, чем было рассказано во время занятия?
Майкл: С моими аспирантами — постоянно. У меня их где-то 5 или 6 человек, и мы всё время с ними что-то обсуждаем. А разговоры такого рода со студентами, которые просто посещают мои занятия — не слишком часто. Хотя хотелось бы, чтобы это происходило чаще. Подозреваю, что они просто боятся приходить на факультет в часы приёма. Каждый семестр некоторым студентам удаётся преодолеть этот психологический барьер, и с ними всегда очень интересно говорить после занятий. Правда, если бы все студенты были настолько же смелыми, у меня просто не хватило бы времени. Так что, возможно, всё работает так, как надо.
Виталий: Как вам удаётся находить время для общения со студентами? Насколько я знаю, в США у преподавателей очень много работы — заявки на гранты и тому подобное.
Майкл: Честно говоря, работа со студентами — это тот аспект моей деятельности, который мне нравится больше всего. Так что мотивации к этому у меня достаточно. Большая часть времени, которое я провожу в своём офисе, уходит на всякого рода встречи. Сейчас лето, поэтому график менее плотный, но во время учебного года каждый день с 9 до 17 у меня всё забито. Исследовательская работа, рецензии, гранты — для всего этого остаются только вечера и выходные.
Алексей: Продолжаете ли вы сейчас читать какие-либо курсы, которые вы читаете на протяжении длительного времени? Что-нибудь вроде введения в Computer Science.
Майкл: Первое, что здесь приходит в голову — курс языков программирования.
Алексей: Насколько сильно отличается сегодняшний вариант этого курса от того, который был 10, 20, 30 лет назад? Возможно, тут более интересны не подробности отдельного курса, а общий тенденции.
Майкл: Мой курс языков программирования был несколько необычен в то время, когда я его создал. Я стал читать его в конце 1980-х, заменив моего коллегу, Дага Болдуина (Doug Baldwin). Тема курса лишь косвенно относилась к моей специализации, но когда он ушёл, я оказался лучшим кандидатом для проведения этого курса. Мне не нравился ни один из существовавших тогда учебников, поэтому я в конечном итоге сам написал учебник для этого курса. (Примечание редакции: речь идёт о книге «Programming Language Pragmatics») Сейчас он используется в более чем 200 университетах по всему миру. Мой подход необычен в том плане, что в нём сознательно смешиваются проблемы проектирования языка и его реализации, и большое внимание уделяется взаимодействию между этими аспектами во всех возможных областях. Основной подход остался неизменным, как и многие базовые понятия: абстракции, пространство имён, модульность, типы. А вот набор языков, при помощи которого эти понятия демонстрируются, поменялся целиком. Когда курс был только создан, в нём было множество примеров на Pascal, а сегодня многие мои студенты о таком языке даже не слышали. Зато они знают Swift, Go, Rust, поэтому я должен говорить о языках, которые в ходу сегодня. Кроме того, сейчас студенты хорошо разбираются в скриптовых языках, а когда я начинал преподавать этот курс, он целиком был посвящен компилируемым языкам. Сейчас же нужно много материала о 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-х считалось, что науке не хватает вычислительных ресурсов. Чтобы исправить эту ситуацию, Национальный научный фонд (National Science Foundation) создал программу координированных экспериментальных исследований (Coordinated Experimental Research, CER). Задачей этой программы было предоставить вычислительную инфраструктуру для кафедр Computer Science, и она добилась существенных изменений. На предоставленные ею деньги мы в Рочестерском университете купили в 1984 году 128-узловый BBN Butterfly, это было за год до моего появления там. На тот момент это был самая большая в мире многопроцессорная система с общей памятью. У неё было 128 процессоров, каждый на отдельной материнской плате, она занимала четыре стойки. Каждый процессор имел мегабайт памяти, 128 мегабайт оперативной памяти в то время было невообразимым количеством. На этой машине мы впервые реализовали блокировку MCS.
Алексей: То есть если я правильно вас понял, то на данный момент проблема с железом решена?
Майкл: В общем и целом — да. Есть несколько оговорок: во-первых, если вы занимаетесь архитектурой компьютера на уровне микросхем, то в академической среде это делать сложно, поскольку в бизнесе для этого существуют гораздо более совершенные инструменты. Если вам нужно что-либо меньше 10 нанометров, то это придётся заказывать у кого-то на стороне. В этой области значительно проще быть исследователем в Intel. Если вы работаете над оптическими связями на чипах или над твердотельной памятью, то вы найдёте в бизнесе технологии, которых пока нет в науке, так что приходится создавать союзы. Например, Стивен Свансон (Steven Swanson) создал такое товарищество для новых технологий памяти. Эта форма не всегда работает, но в некоторых случаях она может быть весьма успешной. Кроме того, в науке тяжелее идет развитие наиболее мощных вычислительных систем. Самые масштабные проекты с суперкомпьютерами, которые сейчас есть в США, Японии и Китае, все сосредоточены в бизнесе.
Виталий: Вы уже рассказали о том, как начали работать над алгоритмами синхронизации. У вас есть две очень известных статьи о блокировке MCS и очереди Майкла-Скотта (MS), которые в определённом смысле были реализованы в Java. (Примечание редакции: все публикации можно посмотреть по ссылке). Там эта блокировка была реализована с некоторыми изменениями и получилась блокировка CLH, а очередь была реализована как и задумывалась. Но между публикацией ваших статей и их практическим применением прошло много лет.
Алексей: Кажется, около 10 лет в случае с очередью.
Майкл: Прежде чем эти фичи появились в стандартной библиотеке Java?
Виталий: Да. Что вы сделали для того, чтобы это произошло? Или ничего не делали?
Майкл: Я могу рассказать вам, как очередь MS попала в Java 5. За несколько лет до её появления я работал с группой Марка Мойерса (Mark Moyers) из Sun Microsystems в их лаборатории под Бостоном. Он организовал семинар для своих знакомых, занимавшихся интересными проблемами в многопоточности, поскольку он хотел найти темы, которые можно было бы продать их компании. Там я впервые встретил Дага Ли (Doug Lea). Даг, я и ещё где-то 25 других людей из Sun вместе обсуждали презентацию Дага о JSR 166, который впоследствие стал java.util.concurrent. По ходу дела Даг сказал, что он хотел бы использовать очередь MS, но для этого ему был необходим счётчик количества элементов в очереди для интерфейса. То есть это должен был делать отдельный метод, атомарный, точный и быстрый. Я предложил просто добавить серийные номера к узлам, взять номер первого узла и последнего и отнять один от другого. Даг почесал голову, сказал «почему бы и нет», и в итоге так и поступил. Мы обсуждали с ним реализацию этого подхода в библиотеке, но большую часть работы Даг сделал сам. В итоге ему удалось наладить отличную поддержку многопоточности в Java.
Алексей: То есть если я правильно понимаю, метод .size () должен был входить в стандартный интерфейс очереди, и у него должна была быть алгоритмическая сложность O (1)?
Майкл: Да, и помимо этого необходим отдельный счётчик.
Алексей: Потому что если вызвать метод .size () в Java, ожидается, что результат будет доступен сразу же, а не в зависимости от реального размера коллекции. Понятно, спасибо.
Майкл: Несколькими годами позже я работал над двойными структурами данных (dual data structures) с моим студентом Биллом Шерером (Bill Scherer) — собственно, о них будет мой доклад на Hydra. Даг подошёл к нам и сказал, что они пригодились бы ему в Java Executor Framework. Вместе с Биллом они создали две реализации, так называемые честные и нечестные очереди (fair and unfair queues). Я консультировал их по этому проекту, хоть и не участвовал в написании собственно кода. В итоге скорость executors существенно увеличилась.
Владимир: Сталкивались ли вы с неверными реализациями ваших алгоритмов или с просьбами добавить новые фичи? Вообще практика должна совпадать с теорией, но достаточно часто они отличаются. Предположим, вы написали алгоритм, и на бумаге он работает, но люди, которые занимаются реализацией, стали просить у вас больше фич или какой-либо настройки алгоритма. Были ли у вас такие ситуации?
Майкл: Единственный пример, в котором ко мне подошли и спросили «как реализовать» — это вопрос Дага, о котором я уже рассказывал. Но было несколько случаев, когда в соответствии с практическими нуждами вносились интересные изменения. Например, команда K42 из IBM конвертировала блокировку MCS и сделала стандартный интерфейс, благодаря которому не было необходимости передавать туда и обратно узел очереди подпрограммам acquire и release. Благодаря этому стандартному интерфейсу идея, красивая в теории, стала работать на практике. Удивительно, что они так и не опубликовали об этом статью, а патент хоть и получили, но потом от него отказались. Замысел был прекрасным, и я при возможности стараюсь о нём рассказывать.
Были и другие случаи, когда люди вносили улучшения в опубликованные мн
