Главная » Хабрахабр » «Не надо скромничать. Пробуй!». Интервью о жизни, компиляторах и жизни в компиляторах с Alexandre Mutel из Unity

«Не надо скромничать. Пробуй!». Интервью о жизни, компиляторах и жизни в компиляторах с Alexandre Mutel из Unity

Как добиться успеха в системном программировании, что нужно знать и понимать, особенно если ты работаешь уже третий десяток лет? C# и перформанс — cтоит ли переписывать на C# всё что видишь? Какое будущее в смысле низкоуровневых компиляторных технологий нас ждёт?

Сегодня в нашей виртуальной студии на вопросы отвечает Alexandre Mutel.

Кроме того, он известный в опенсорсе разработчик, контрибутящий в SharpDX, Markdig, Zio и другие проекты, а с 2014 года — MVP в категории «Visual Studio and Development Technologies». Alexandre Mutel работает на должности Lead Software Architect в Unity Technologies.

Alexandre работает над разными низкоуровневыми и высокоуровневыми вопросами в областях рендеринга графики в реальном времени, GPGPU, синтеза звука, эффективного использования и архитектуры управляемых языков, кодогенерации и документации.

Как всегда, интервью ведут Евгений Трифонов (phillennium) и Олег Чирухин (olegchir) из JUG.ru Group.

В конце поста есть сюрприз от Дилана Битти (другого известного дотнетчика) — мы и сами не ожидали.

E.: У вас длинная карьера, три десятилетия — для начала можете вкратце рассказать о ней?

Когда я начал программировать на этом компьютере, мне было то ли 11, то ли 12, точно не помню. Всё началось в детстве — у меня появился Amstrad PC 464. Я совсем мало играл в игры, куда интересней было разрабатывать, писать код. Я быстро освоил программирование на BASIC и накупил книжек по разработке игр: тогда это казалось очень интересным. Потом я продолжил писать код на ассемблере для Amstrad.

Встретил ребят, которые занимались написанием демок — это было совсем не то, что сейчас. В 16 лет у меня появилась Amiga 500. Я начал писать много демок, которые я не всегда показывал, но мне просто нравилось писать на ассемблере. Сейчас это WebGL, и это уже совсем другая демосцена. И это было так просто.

Это уже было нечто совсем другое по сравнению с играми и ассемблером. Потом пошёл в технологический колледж, где изучал компьютерную инженерию. Я обожал изучать вещи, про существование которых раньше даже не знал: операционные системы, UNIX, работа с языком C (до этого я пользовался только BASIC или ассемблером, потому что у меня не было денег, чтобы купить компилятор C/C++).

Эта была работа на французскую компанию в Нью-Йорке. Когда окончил колледж, начал работать в индустрии валютного рынка. Вообще, я не хотел работать в банке, я хотел работать в геймдеве. Через два года я вернулся и попал в банк. Так и провёл там лет 8-9, в основном имея дело с Java и немного с C++. Но в результате залип там — новая область, много чему можно научиться. Множество распределённых серверов и SQL БД, копирование баз данных… Совсем не то, чем я занимаюсь сейчас.

Путешествие меня поменяло и встряхнуло. Потом я взял некий творческий отпуск и поехал в туристическую поездку по миру: был в Африке, в Южной Америке, целый год в Азии год. Я уволился и провёл 4 года на курсах социальных работников, чтобы работать с детьми, с бездомными, инвалидами, пожилыми людьми. Когда я вернулся, то не мог уже работать с компьютерами, в IT-сфере, не мог работать на банк. А потом вдруг взял и перешёл в очень гуманитарную область. Три года я учился этому, и это было очень интересно, потому что большую часть жизни я работал в области точных наук: математики, проектов, абстракций. Пытался даже работать в этой области после обучения, но как раз в этот период один друг, с которым я делал демки в детстве, намекнул, что можно снова этим заняться.

Это было плохо. Я начал заниматься демками всё своё свободное время, и очень быстро это стало занимать больше, чем работа с детьми на улице. Ты же можешь». Люди говорили: «Нужно попробовать найти работу в геймдеве, почему нет? Но я думал, что это невозможно, ведь я давно не работал с компьютерами, и с моим резюме сложно было отыскать работу в IT.

Однажды со мной вышла на связь одна из этих компаний, они пользовалась одним из последних проектов, который называется SharpDX. Я начал работать над опенсорсными приложениями и выпустил пару проектов, которыми стали пользоваться компании. Мы прожили 5 лет в Японии. Я поехал в Японию вместе с семьёй — ведь у меня уже было двое детей. В это время я работал над созданием игрового движка с нуля на C#.

Это мешало тому, чем я занимался раньше, но они предложили работу над очень сложной и интересной задачей, настоящим испытанием: сделать нативный компилятор, генерирующий нативный код из IL . Года два назад я вернулся во Францию и начал работать в Unity. Это было именно то, чем я всегда хотел заниматься, но не мог, потому что мне бы за такое не заплатили. NET-кода. Я проработал над этим проектом 2 года. И вот появился шанс, прекрасная возможность.

Да, похоже, рассказ получился не очень коротким.

Из-за вашего опыта хочется спросить вот что. E.: Ничего, такая карьера стоит долгого рассказа. Другие отвечают: «Да ладно, хотя они не ускоряются прежними темпами, рост по-прежнему есть, поэтому никаких поводов для паники нет». Сейчас одни люди говорят «Закон Мура больше не работает, компьютеры не становятся быстрее, мы все обречены». Поскольку вам близка тема производительности, и при этом вы следите за индустрией давно, какая позиция у вас?

(смеется) Я верю, что многие, если не большинство приложений, которые мы разрабатываем, адаптируются к требованиям производительности с самого начала, в результате обеспечивая наилучшее качество. Я придерживаюсь в этом вопросе золотой середины.

Например, когда Windows на протяжении нескольких лет становилась немного медленнее — Windows Vista и т.п. Посмотрите, что происходило в IT-индустрии на наших глазах. Когда вышла Windows 8, она была уже немного лучше. По сути велась естественная работа по улучшению перформанса, ведь годами об этом особо не беспокоились. В результате, у нас есть система, которая работает весьма неплохо по сравнению с тем, что было раньше. Потом вышла Windows 10 и она стала ещё немного лучше. Этот софт больше не работает, мы переходим на Linux, потому, что он быстрее и меньше тупит». Действительно важно для них было сделать эти оптимизации, ведь однажды люди обязательно стали бы «жить не по средствам» и начали бы говорить: «О!

И вот что удивительно: всегда была тенденция работать с нативным кодом, в какой-то момент даже в Windows решили вернуться к C++, они говорили: «C++ — это решение, . То же самое можно сказать про весь софт, который мы разрабатываем. И вот снова стали актуальны нативные языки. NET очень медленный, тут Garbage Collector и бла-бла-бла…».

 JS — скриптовый язык, не супербыстрый, но иногда он отрабатывает в два раза быстрее C++. В то же самое время V8 в Chrome вернул в обиход JavaScript благодаря JIT. Но если присмотреться, это всё потому, что требования по производительности закладывались туда с самого начала. Этого было достаточно, чтобы он выжил и чтобы мы использовали его прямо сейчас для вещей вроде написания кода в Visual Studio Code. Всё могло быть написано на другом языке, не обязательно C++, но факт в том, что весь этот софт развивался с учётом перформанса с самого начала. Даже в VSCode, даже несмотря на то, как много там JavaScript и скриптового кода вообще, всё остальное — V8, стек рендеринга, JIT — всё это написано на языке, предназначенном для максимальной производительности, то есть на C++.

Например, Visual Studio Code — изумительное программное обеспечение, очень хорошо работающее для разработчиков, решающее их задачи. Так что да, мы можем использовать менее эффетивные и производительные языки, но только потому, что всё нижележащие технологии разрабатываются с целью получить фантастический user experience. Перформанс повсюду, но иногда мы не видим его, потому что он уже заложен во всё, что мы используем. Многие говорят: «Хотя нам нравится пользоваться более нативными редакторами кода, прямо сейчас мы переходим на Visual Studio Code» — потому что они считают его вполне эффективным.

Но JavaScript такой быстрый только потому, что сотни сотен инженеров-разработчиков годами работали, чтобы оптимизировать JIT. Мы думаем: это написано на JavaScript, потому что он достаточно быстрый. Скриптовыми языками, которые без всей этой подготовительной работы оказались бы гораздо медленнее. Сейчас мы можем пользоваться скриптовыми языками даже для написания очень сложных приложений. У нас есть выбор, но всё равно есть эта история с перформансом, которая повторяется для каждого языка снова и снова. Мы живём в странное время.

NET — типичный пример. Так что . Если вы посмотрите когда-нибудь на ASP. За последние три-четыре года там проведена громадная работа. Пытаясь уложиться в жесткие требования, можно попробовать стать более производительным, можно сэкономить мощности, сэкономить немного денег в конце месяца — перформанс влияет на всё. NET Core, если вы посмотрите на всю работу, проделанную с CoreCLR… Перформанс — это хорошо продаваемая штука, он стоит денег и позволяет достигать большего. Нужно уделять немного времени, чтобы проверять, можешь ли ты сделать своё приложение чуть более производительным. Когда я слышу, как люди говорят: «Всё в порядке, я разрабатываю своё приложение, у него средняя производительность, сойдёт…», о чём они думают? Если ты сможешь сэкономить ресурсы или время работы приложения хотя бы на десятую долю, это уже хорошо.

Вы считаете Slack не лучшим местом для технических решений, а на своём сайте предлагаете подписываться на олдскульный RSS. E.: Есть отчасти философский вопрос. Считаете ли вы, что наступившая эпоха мгновенного обмена сообщениями делает разработчиков менее продуктивными?

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

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

E.: Спасибо, время для вопросов Олега!

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

Если ты интересуешься такими технологиями, то делаешь некую обычную домашку. Не уверен, что существует заготовленный путь для такого перехода. Не обязательно писать полностью компилятор от начала до конца, до самой генерации машинного кода. Дома ты пишешь парсеры и штуки, связанные с компиляторами. Это то, что я делаю последние годы, работая в Unity. Ты начинаешь интересоваться написанием компиляторной инфраструктуры. Как можно улучшить работу, где стоит улучшить перформанс, и где этого ещё не сделали. Если ты увлечён низкоуровневыми вещами, то это одно из тех мест, где можно понять, как это всё устроено на самом деле. Если ты беспокоишься о перформансе, то очень важно быть в курсе, на чём будет выполняться приложение в конце концов.

Хочется подходить к решению проблемы в её основе, то есть на уровне компилятора. Перформанс — это моя тема, и всё это стало для меня отличной возможностью. Если мы запускаем игры, приложения, фильмы или что-то в этом роде, иногда можно сравнительно легко достичь таких результатов. Именно здесь мы можем в десятки раз увеличивать производительность в тех местах, где это нужно для наших пользователей.

Но это не было чем-то, чем я специально хотел заниматься. Увлечённость низкоуровневыми штуками и составными частями компилятора привели меня к текущей работе. Я начинал этим заниматься, но прекратил, потому что это слишком много работы, а у меня очень мало свободного времени. Иногда, когда ты получаешь много опыта с разными языками, пишешь приложения — появляется желание даже придумать свой собственный язык. Конечно, я понимал, как работают компиляторы и всё такое, но не понимал сложности требований. Но у тебя появляется подсознательное желание вернуться «к корням», попытаться сделать что-то самому, чтобы всё понять. Очень сложно выбрать то, что одновременно даст и большую продуктивность работы прикладного разработчика и будет эффективным. Сложных трейдоффов, с которыми придется разбираться, например, в области управления памятью. Rust или . Эта проблема всё ещё не решена до конца. Rust — прекрасный, изумительный, но он сложен в работе, особенно если ты переходишь на него с чего-то типа JavaScript. NET никогда не решат этого. Тем не менее, имеются примеры разработчиков на Python или JavaScript, которые переходят на Rust, хотя это и несколько удивительно.

Так чего хорошего в C#? О.: Вы упомянули, что программировали на C# последние лет 10. C++ кажется более системным языком. Почему не C++, например?

Я искренне верю, что они приводят к куче багов, к огромной неэффективности разработки. Если честно, я ненавижу C++, ненавижу C, но работаю с ними. Это неправда. Многие думают, что раз ты программируешь на C, то ты уже де-факто пишешь быстрый код, что твоя программа будет перформанс-ориентированной. NET. Если ты лепишь кучи malloc и всякого такого, оно будет медленным даже по сравнению с тем, что написано на . Ты должен зарываться в кучу странных вещей, о которых никто не слышал. Хорошие разработчики на C/C++ вынуждены использовать ухищрения вроде region memory allocator. Как минимум, разработчики AAA или люди, которые делают игры на C/C++-фреймворках. Хотя вот разработчики игр обычно о таких вещах знают. Раньше я вообще не читал книг по C++ и только три-четыре года назад начал читать книги только по C++, чтобы просто прочувствовать язык. Часть проблем происходит от сложности самого языка. Я программировал на нём, но у меня не было систематического, формального подхода, и меня поразила его сложность, количество вещей, которые ты можешь испортить, если не напишешь всё правильно.

Фактически мы ссылались на значение, которого уже не было в памяти. Не далее, как пару месяцев назад в Unity был баг, кто-то допустил ошибку в куске кода на C++, это было в конструкторе, что-то передавалось по значению и в итоге мы брали от этого значения адрес и искали в кэше. Совершенно другой код, который отлично работал, внезапно работать перестал. И всё это потому, что там перепутали указатели с неуказателями, и тот, кто сделал этот рефакторинг, не проверил все места использования. По сути, это ошибка в работе с памятью. Вроде бы, ошибка маленькая, но она поломала всё целиком. В . Так что да, когда я вижу подобные вещи, то убеждаюсь, что мы должны ограничить доступ к работе на C и C++, максимально сократить их использование. Но писать всё на C# довольно муторно. NET-части я действительно ограничил их применение только платформозависимыми вещами. Хотя, например, можно попробовать инкапсулировать всё это в обёртку на C и организовать доступ через всего одну функцию. Для того, чтобы получать доступ к API, нужно делать кучу dlopen. Но это такая узкая тема про интероп, а дальше ты остаёшься с нормальным управляемым языком, используешь его большую часть времени, наслаждаешься более быстрой компиляцией. Такие вещи я предпочёл бы изолировать и разрабатывать их дальше на C и C++.

Ты начинаешь компилировать на MSVC, потом должен переключиться на Clang, потом на GCC. Я ненавижу ошибки компилятора C++ и линкера, ненавижу необходимость работать с разными платформами, всё это очень-очень сложно. Работа с C++ — это кошмар! На Linux, на Mac, на Windows, на Android, на iOS и так далее и тому подобное.

-файлами. Я ненавижу разделение между файлами в редакторе, .h-файлами и cpp. Я люблю метапрограммирование, но в современном C++ мы можем делать просто полное безумие. Люди окончательно запутываются в языке и начинают программировать на макросах. Сами по себе эти штуки изумляют, но вообще-то это уже слишком.

Может быть, не такой быстрый, как на C++, но можем. Подводя итог: да, думаю, мы можем разрабатывать эффективный софт на C#. Это вполне безопасно. Именно это мы пытаемся делать в Unity — например, мы делаем bust compiler, чтобы компилировать особое подмножество C#, добиваясь максимального перформанса, местами даже большего, чем это получилось бы на C++ — но оставаясь в C#. И это горький опыт. Для указателей нужно объявлять unsafe, не генерить исключений, делать всё эксплицитно. Думаю, это как раз то направление, в которое стоит идти . Но всё-таки ты можешь написать код, который будет так же быстр, как на C++. NET и куда должны идти мы.

NET Core, который представляет из себя очень большой и страшный C-файл. О.: Если говорить об опенсорсном коде, например, у нас есть сборщик мусора в . Возможно, имеет смысл переписать здесь всё на C#? Два мегабайта мусора, скорее всего, сгенерированного из какого-нибудь лиспа (вряд ли столько букв стоило писать вручную).

Я общаюсь с людьми, которые работают над JIT и в Microsoft, и в сообществе. Да! Я верю, что существует момент, когда твой язык становится более зрелым и основополагающим, и тогда ты должен бросить вызов, проверить его на прочность. Есть кое-что, во что я искренне верю. Доказать, что можешь применить его даже для создания чего-то очень требовательного к перформансу. Тебе нужно уметь использовать его в качестве фундамента. Очень-очень большой процент подсистем рантайма . И это история про Garbage Collector и JIT. Если взять за правило, что на C++ можно описывать только абстракции базовой платформы, это сделает большую часть рантайма платформонезависимой. NET, в том числе JIT и GC, может быть сделан на C#. Но это огромная работа. Я бы очень порадовался, если бы это произошло.

Я уже говорил об этом, рефакторинг и улучшение кодобазы на C/C++ настолько сложны, что в какой-то момент ты перестаёшь этим рефакторингом заниматься. Есть одна причина, почему мне эта идея особенно нравится. Придётся переносить и менять какие-то файлы руками, ибо рефакторинги в IDE будут работать плохо, например, потому что слишком много шаблонов — и так далее и тому подобное. Это настолько больно, что ты просто к этому больше не притронешься. Добавлять новые оптимизации оказалось бы возможным гораздо быстрее и проще, просто потому, что время компиляции уменьшилось. Разрабатывая на C#, можно было бы быть амбициознее насчёт своих желаний. Приятно, что, например, в CoreRT стараются максимально использовать C# вместо C++. Уменьшилось бы время итераций для тестирования и так далее. Ситуация меняется.

NET GC на C#. Но мы всё ещё на полпути от того, чтобы переписать . Например, я знаю, что могу переписать . Но мы могли бы. Несколько лет назад я сильно заинтересовался GC, читал книжки про это, написал что-то вроде прототипа реализации GC. NET GC, причём переписать по-другому. Позже я обнаружил, что в Golang компилятор вначале был написан на C, а потом на Golang. Я был поражён работой Java-комьюнити над Jikes RVM — они проделали эту работу на Java. Например, есть огромный файл, где описываются разрешённые оптимизации, которые можно применять к некоторым инструкциям. Когда стал читать исходный код Golang-компилятора, был удивлён организацией кодобазы и тем, как структурированы оптимизации. Я не видел такого ни в LLVM, ни в . Инструкции могут мапиться в более быстрые нативные инструкции, и это всё описано в огромном текстовом файле. NET JIT.

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

Для меня наиболее сложная часть — читать исходники компилятора и понимать их. О.: Вы рассказали о сложности кода, опасности ошибок и так далее. Вот этот файл из Golang с ловерингом, например. Например, вот есть очень большой файл с десятками тысяч строк AST-трансформаций и промежуточных представлений. Как его написать? Что вы думаете о том, чтобы писать хороший понятный код для системных частей?

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

Мне очень не нравится, когда говорят: «Код должен сам описывать себя! Второе: я убеждён, что мы обязаны сопровождать код большим количеством комментариев, чтобы объяснять внутренние зависимости, которые не очевидны, когда просто смотришь на код. Это совершенно неверно и вводит в заблуждение. Он должен быть очевиден!». Инженеры любят рассказывать такие сказки молодым разработчикам, и так делать не стоит.

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

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

Нужно делать больше юнит-тестов. И третье для меня — тестирование. Так твое приложение будет совершенствоваться со временем. Не больших интеграционных тестов, а именно мелких юнит-тестов, проверяя части своего API, начиная с нижних уровней. И в момент написания он был неплох. Например, я написал SharpDX вообще без тестов. Я хотел иметь доступ к DirectX C++ API, которое уже было доступно на C++. Но дело в том, что я создавал его не для людей, а для себя, в своё свободное время. Но каждый раз, когда я вносил какие-либо изменения, приходилось проверять функциональность заново. На протяжении многих лет я проверял, что всё работает. А потом пришел один разработчик из опенсорсного сообщества, выделил компилятор в отдельный пакет и попробовал на этом сделать нечто отдельное от SharpDX. Последние несколько лет я переключился на другие проекты: времени нет, да и не пользуюсь я им больше. Просто замерджил его pull request (он казался идеальным). Штука в том, что я полностью не проверил этот PR, поскольку мы не сделали ни одного теста. Но мы кое-чего не учли, и сам SharpDX оказался совершенно сломан в какой-то из версий. Он начал делать мини-тесты на своём репозитории на своём отдельном приложении. Но попытка достичь 90-процентного покрытия — это очень муторно. Тут же нарисовались люди с проблемами вида: «А чего это вот этот метод вызывает исключение?» На последующих проектах (и опенсорсных, и рабочих) я старался быть очень осознанным в плане тестирования, периодически даже пытаясь увеличить покрытие. Иногда реальные тесты получаются слишком странными, ты написал их просто для отладки и не можешь внести их под покрытие, не хочешь тащить такое в свой код.

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

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

И это действительно вызов, ответить на который компиляторы немного затрудняются, потому что SIMD и подобные оптимизации обычно добавляются позже, не обязательно с самого начала создания компилятора. Я думаю, что сегодня главный челлендж — создать компилятор, который будет эффективен в работе с SIMD. Дело в том, что это приносит множество новых проблем оптимизатору, он должен уметь выполнять их корректно. (В случае с LLVM, наверное, они были с самого начала). В каком-то виде они могут это делать, но иногда это проще сделать вручную. Как можно заметить, компиляторы сейчас затрудняются, например, автоматически векторизовывать код. Это сложная тема. Компиляторы неспособны определять все места для оптимизации, и в результате генерится неэффективный код. Проект разрабатывается уже несколько лет, и в целом это только подготовка, чтобы внести эти изменения в апстрим LLVM. Кое-кто из Intel работает над добавлением технологии векторизации в LLVM. LLVM — это очень хорошая система, хотя бы потому, в ней есть вещи, отсутствующие в . Их ещё пока там нет, это очень сложно, и потребуются годы. Использование преимуществ SIMD, CPU и разных ядер — вот это будет наибольшим современным челленджем. NET. NET языки добавляют векторные интринсики — можно использовать векторизатор и SIMD-инструкции эксплицитно. Вот почему, например, в . Но во многих случаях, вроде циклов, можно было бы ожидать и автовекторизации.

Сегодня это больше не проблема. Раньше я бы сказал: «Нам нужны компиляторы как сервисы и компиляторы как библиотеки». Поэтому LLVM и стала такой известной штукой: она разрабатывалась с самого начала как компилятор-библиотека, в которой можно пользоваться любым языком, каким захочется. Люди убедились в полезности этих идей. Конечно, это компилятор не того же типа, но тем не менее его можно использовать в собственном коде. То же самое, например, с Roslyn на C#, там тоже есть компилятор. Так что для меня совместимый с SIMD код — более важная штука. Думаю, сейчас все уже в курсе этих штук, люди осознают, что компилятор приносит пользу. У нас есть 6, 8, 16, 42 ядра. Программировать с прицелом на GPU, CPU, на количество используемых ядер — это только начало. В какой-то момент начнётся их увеличение, мы должны быть готовы к этому, чтобы использовать всю эту мощь максимально эффективно.

Не могли бы вы совсем немного объяснить, каков статус Markdown? О.: У вас есть своя собственная реализация Markdown под названием Markdig, да? Есть ли у него формальная определённая грамматика, как у него дела?

Скорее всего, это не для простых обывателей, которым всё ещё проще использовать Word или что-то такое. Да, для меня Markdown — это такой способ написания документации, который нравится разработчикам. Разработчики на протяжении многих лет пользовались чем? Но для разработчиков он хорош. И это было нормально. Текстовыми файлами, разными способами размечали в них заголовки, и так далее. Их не всегда было просто читать, там не было картинок, и это было сумасшествие. Ты знаешь, это как читать RFC в интернете — есть куча текстовых форматов файлов, очень ограниченных, очень хорошо сделанных, но не формализованных. А потом появился Word, PDF и тому подобное. Но у нас не было выбора, и приходилось использовать даже ASCII-art. Разработчиков было не очень-то просто уговорить работать с такими документами — это было не модно. В двухтысячном году куча документации была в Word. Когда появился Markdown, это было изумительно, стало возможным производить из него что-то очень приятное — например, HTML. Было неудобно смотреть изменения в документации, когда вносишь правки в связанный код и наоборот. Даже если у тебя не сгенерировано HTML, Markdown можно удобно читать в текстовом редакторе. И это всё ещё текстовый формат, который легко читать и добавлять в свою кодобазу. И всё это лежит рядом с твоим кодом. Сейчас, когда ты открываешь проект на Github, он определяет Markdown-файлы и самостоятельно красиво их отображает. Например, в Microsoft перевели всю техническую документацию на Markdown, и теперь документацию можно читать прямо на GitHub, они принимают PR — вот такой прекрасный способ дать доступ к документации и организовать процесс внесения правок, воспользоваться которым может каждый. Документация среди кода — лучшая форма технической документации.

Думаю, что сегодня CommonMark — это и есть стандарт. В плане нормализации Markdown, есть проект под названием CommonMark, который запущен несколько лет назад, целью которого является стандартизация Markdown. Например, Github перешел на CommonMark в прошлом году. Люди начинают уважать его, следовать ему, но есть и множество других реализаций. Но они смогли перейти на него. Никто этого не заметил — и это хорошо. Они начали работать над тем, чтобы использовать Markdig много лет назад, а до этого они взяли самописный Markdown-движок, использующий внутри регулярки. И Microsoft тоже перевёл документацию на CommonMark, потому что они использовали мой Markdig. Они связались со мной, и это было круто. Это неплохо, но, насколько знаю, они не очень следовали в этом движке спецификации CommonMark, поэтому в результате перешли на Markdig. Очень рад, что такая компания как Microsoft решила его подхватить. Я написал Markdig для того, чтобы им пользовались, и хотел использовать в своём собственном проекте, но потом надолго отложил его в сторону.

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

Главное — делать свою домашку, изучать вещи самостоятельно. Это применимо не только к программированию, но и к любой сфере. Не обязательно принимать язык программирования таким, какой он есть. Важно задавать вопросы. Ты должен быть любознателен и открыт к изучению причин, должен задавать хорошие вопросы. Не то чтобы надо его менять, но важно понимать, почему разные вещи работают так, как они работают. Что бы ты сделал, чтобы улучшить язык? «Я не понимаю, как это устроено, но я хочу понять это». Так ты сможешь узнать гораздо больше, чем просто вбивая в Google «я хочу сделать X» и находить на гитхабе готовые проекты из одной функции «сделать хорошо». Чем больше вопросов ты задаёшь языку, которым пользуешься, тем больше у тебя будет возможностей помогать, улучшать его, узнавать новые вещи и открывать, почему что-то в программном обеспечении сделано определенным образом. Но в той части, которая тебя заботит, которая интересна для тебя лично, стоит глубже погружаться и задавать вопросы. Когда мы пишем реальное приложение, слишком сложно было бы вдаваться в детали каждой использованной зависимости — это была бы огромная работа по ковырянию в деталях. «Может быть, я могу написать что-то лучшее?» Как это работает, можно ли это сделать быстрее, почему какая-то вещь работает не очень хорошо — ты обязательно должен понять, почему.

Иногда хозяева проекта не хотели его менять. Многие проекты, с которыми я работал, по большей части были законченными. Реальность опенсорса такова, что иногда тебе нужно заняться чем-то другим. Это грустно, ведь ожидаешь, что в опенсорсе все друг с другом будут сотрудничать. Людям бывает тяжело принимать такие предложения — возможно, это принесёт только больше багов и больше поддержки, и кто будет всё это поддерживать? Иногда то, что ты предлагаешь, хорошо, но ведёт к слишком большим изменениям. Наверное, нет. Тот, кто пришёл с этим предложением?

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

Не надо скромничать. И ещё одна важная вещь. Пробуй делать то, тебе хочется. Пробуй! Даже если эта идея безумная, и иногда ты можешь получить немного безумные результаты — в этом тоже что-то есть. Если у тебя появилась идея — попытайся воплотить её. Тебе нужно быть очень внимательным к тому, что они говорят, как они работают, что они думают. Пока ты занимаешься такими вещами, можно встретить множество странных и сумасшедших людей, от которых можно получить крутые инсайты о том, как можно заниматься разработкой. Это круто, когда ты можешь встретить таких людей на своем карьерном пути. Не копируй их, потому что у тебя есть свой собственный путь и своё будущее. Я не всегда это осознавал, но спустя какое-то время понимал: «Да ведь этот парень был крутым!». У меня было несколько таких людей. Это золотая середина между тем, чтобы пытаться думать самостоятельно и брать лучшее от лучших умов вокруг себя. Я научился у них чему-то, но, может быть, мог бы научиться большему. Они могут повлиять на тебя в хорошем смысле и могут помочь разработать более крутые вещи.

Это история про то, чтобы быть развиваться самостоятельно, задавать как можно больше вопросов, пытаться быть открытым людям, которых встречаешь, к событиям, которые можно использовать, и принимать участие в чём-то большем, чем мы сами.

NET IL to highly optimized native code by using LLVM» на DotNext 2018 Moscow. Уже в следующую пятницу Александре выступит с докладом «Behind the burst compiler, converting . Мы бы рассказали вам, чего ещё ждать от конференции, но за нас это лучше сделал другой её спикер, Дилан Битти — он записал целую песню: Конференция пройдёт 22-23 ноября в Москве и, кажется, это будет самый большой DotNext из всех.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

У нас DevOps. Давайте уволим всех тестировщиков

Можно ли автоматизировать всё, что угодно? Потом всех тестировщиков уволим, конечно. Зачем они теперь нужны, «ручного» тестирования не осталось. Правильно ведь? Здесь будут конкретные цифры и чисто практические выводы, как так получается, что у хороших специалистов всегда есть работа. Это ...

Современный PHP — прекрасен и продуктивен

Почти 8 месяцев тому назад я пересел с проектов python/java на проект на php (мне предложили условия от которых было бы глупо отказываться), и я внезапно не ощутил боли и отчаяния, о которых проповедуют бывшие разработчики на ПХП. И вот ...