Записки программиста

Темы шестого выпуска: Эльбрусы, VLIW, FPGA и многие другие страшные слова, скандальная правда о том, как ведется разработка компиляторов в России, о том, что на самом деле любой рубист может запросто переквалифицироваться в разработчика ядра OpenBSD, а также ужасы написания серверных приложений на Haskell. Предыдущие выпуски: пятый, четвертый, третий, второй.

Слушать онлайн:
http://eaxcast.podfm.ru/_eaxcast/6/

Скачать файл:
http://eaxcast.podfm.ru/_eaxcast/6/file/podfm_eaxcast__eaxcast_106.mp3

Шоу нотес:

• Официальный сайт компании МЦСТ;
• Вскоре после записи подкаста в блоге alexanius’а совершенно внезапно появился пост о конференции «Новая электроника 2014» с акцентом на стенд МЦСТ;
• Исходный код того самого серверсайда на Haskell;

Голоса выпуска: Иван @gliush Глушков, Сергей @kpy3 Елин, Валерий @sum3rman Мелешкин, Александр @afiskon Алексеев

Фоновая музыка: The Panets — Winter Beats (Big Power Mix)

 

Александр: Вы слушаете EaxCast, первый сезон, шестой выпуск. Меня зовут Александр. И сегодня в выпуске у нас толпа народу, все в сборе, все здесь. Валера здесь — привет, Валер.

Валерий: Привет!

А: Сережа здесь — привет!

Сергей: Привет.

А: И Ваня Глушков тоже здесь. Привет, Вань.

Иван: Салют.

А: Наши слушатели жалуются, критикуют нас, что все выпуски сплошь про Erlang, сплошь про базюльки, и у нас Erlang и базюльки, базюльки и Erlang, и больше ничего нет, и сколько вообще можно…

С: А разве что-то есть кроме Erlang-а?

А: Поэтому этот выпуск мы решили разнообразить. Мы постараемся поменьше про Erlang и базюльки, побольше про разные другие интересные темы…

И: Haskell?

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

И: Да, именно так.

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

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

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

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

И: Не ошибаешься, да.

В: И когда он полностью ушел в Интел, мол, там все осталось очень плохо, что сейчас Эльбрус просто в FPGA-шки, в которых просто зашита их схематика, мол они даже железку выпустить не могут, и все очень плохо, ты можешь по этому поводу что-либо прокомментировать?

И: Да, конечно. Я пришел в Эльбрус, когда Бабаян был еще там, и меня тоже коснулся этот переход, то есть, я тоже должен был перейти в рамках толпы народа в Intel. Про причины этого перехода я говорить не буду, так как в интернет много всякого, да и мне до конца самому не ясны основные причины. Но в момент, когда я только приходил в компанию, вот этот Эльбрус, не SPARC версии Эльбрусовские, которые довольно таки давно выпускаются — десятки лет, а вот именно эта новая архитектура, она была готова только в прототипе. Когда я появился, по-моему даже не было FPGA-шек, были чисто программные комплексы симуляторные на которых мы пытались запускать операционные системы, тесты гонять, выполнять своеобразные функции, потому что компилятор надо уже готовить к тому моменту, когда уже первая железка будет готова.

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

Касательно второго вопроса, когда Бабаян ушел, я не заметил очень большого изменения в работе. Руководство очень сильно постаралось, чтобы вот это разделение компании не отразилось на работе сотрудников и, в принципе, что я делал, то я и продолжал делать, и я не скажу, что у нас что-то сильно поменялось. И продолжали делать железяки, и все нормально. Конечно, куча проблем осталось. У нас в Росси до сих пор нет производства меньше, чем, в Зеленограде какое появилось недавно? 90нм? Все Эльбрусы меньше 90нм приходится печатать где-то за границей. Конечно, это проблема, но при сдаче всего этого, там по-моему вписано куда-то в бумажку, что как только появляется на территории России данное производство, оно полностью переходит на территорию России. Ждем, пока оно появится в России, в Зеленограде есть тенденции, я надеюсь, что все поменяется.

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

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

А: Сереж, у тебя, кажется, был вопрос.

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

А: А вот тогда у меня есть вопрос. Ты, Вань, говоришь, что писал компиляторы. А какие это были компиляторы, какие языки ты компилировал? Это был ассемблер, что-то процедурное, что-то функциональное?

И: Это, вообще, долгая история. Мы хотели обойти базюльки стороной, но, похоже, не получится. Потому что начинал я как software engineer in QA, Quality Assurance. И я делал систему тестирования компиляторного проекта, в том числе я вел БД для этого тестирования, куда куча режимов разных, разных настроек для тестов записывались, а потом использовались для оперативного или ночного тестирования. То есть основная проблема с компилятором — что там очень много тестов. Тестов настолько много, что из всего многообразия вы выбираете маленький-маленький кусочек, и этот кусочек идет так долго, что до следующего тестирования не успевает. Вам надо запускать его раз в день, а он идет 26 часов. И это самый маленький кусочек, который вы смогли выбрать, который более или менее обеспечивает покрытие. Очень много разных режимов работы компилятора, ну, вы представьте себе, gcc к примеру, ближайший, всем известный пример.

У него куча режимов оптимизации, у него куча параметров по совместимости, скажем, по стандартам (c89, c99, ansi), у него куча проверок, дополнительных настроек оптимизации, -f< и куча параметров >. Отдельные проверки, скажем, на какие-нибудь warning-и, что они включаются и выключаются. Это бывает критично для многих участников, которые пользуются нашим компилятором. И вот все это если перебирать, то там такое большое многообразие получится разных тестов, которые надо бы прогонять постоянно, какое-нибудь регрессионное тестирование сделать, что, ну, довольно сложно это сделать. Поэтому была довольно сложная выборка, что надо, что не надо.

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

И: Да, я совсем забыл про оригинальный вопрос, увлекся сам собою.

В дальнейшем я перешел в отдел разработки компилятора именно самого. И именно под мою ответственность попадал frontend, который мы использовали внешний, Edisson Design Group. Библиотеки системные, glibc, и неоптимизирующий компилятор полностью. У нас там их было несколько, неоптимизирующих, вот один из них. И на вход ему, конечно, попадала программа на си, на выходе получался бинарный код под архитектуру Эльбрус. При этом была возможность создания бинарников как кросс-компиляцией, так и под интел, чтобы можно было запускать компилятор на интеле, для получения кода под Эльбрус. То есть у нас большая часть разработки шла все равно на интеловских машинах, потому что у нас были хорошие симуляторы, которые позволяли компилять на интеле для Эльбруса и запускать под симулятором выполнение программы, особенно если она не требовала IO, а делала какие-то вычисления математические.

С: Я правильно понимаю, что вы разрабатывали весь компилятор с нуля, а не как набор расширений gcc?

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

С: В итоге переход состоялся или нет?

И: Нет, gcc мы в итоге так и не используем, потому что для неоптимизирующего компилятора его, в принципе, можно было бы использовать, но неоптимизирующий компилятор дает слишком «прямой» код. А на архитектуре Эльбруса можно сделать быстрый код только за счет работы компилятора — широкое командное слово, которое позволяет выполнить большое количество команд за такт. Gcc будет по-умолчанию делать малое количество операций, а нам нужно полностью загружать процессор. Дополнительная загрузка процессора делается большим разнообразием способов, поэтому нам необходимо было делать свой компилятор.

С: А если посмотреть в сторону llvm — так такое возможно, нет?

И: Когда я уходил, вот это движение «смотреть на llvm» началось, сейчас они что-то такое сделали, но, если честно, у меня сейчас нет информации об этом. Да, поддержка была, они встраивались в llvm, и, возможно будут вообще на него переходить, но я не могу ничего сказать.

В: У меня тут аж три вопроса накопилось. Ты сказал, что один тест проходил больше 20 часов. Это почему так, потому что это был тест на симуляторе, а не на настоящем железе?

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

В: Второй вопрос. Ты один раз рассказал, что там VLIW, второй раз сказал, что там невозможно без оптимизации со стороны компиляторов полностью загрузить мощность процессора. Если мне не изменяет память, Itanium был примерно про тоже самое. Почему Itanium не взлетел, и почему Эльбрус вроде как взлетает?

И: Я не уверен что Itanium не взлетел. У них больше была такая концептуальная разработка. Они, мне кажется, отказались довольно быстро от идеи, что Itanium получит большой спрос, и они выйдут на рынок с ним. И в итоге, это получилось как с языком Haskell. Там очень много идей обрабатываются, очень академические круги заинтересованы в этом, но в итоге все разработки уходят в какие-то сопредельные вещи, которые получают большой рыночный спрос. И более того, в Itanium’е до сих пор этот процесс идет, нет? Я перестал следить за этим, и сейчас не смотрю в эту сторону.

В: Он помер, в том смысле, что там почти все software vendors, которые хоть как бы то ни было его поддерживали кроме, по-моему, HP-UX, сказали: «Ну, вас всех на фиг! И мы не будем это поддерживать!» И я не знаю, печально это или нет.

И: Ну да, мне вот интересно и HP от него отказался или нет.

В: И последний вопрос. Ты сказал, что у вас были вот эти software-ные стенды симуляции, что вы, получается, эмулировали процессор программно, потом на этой программной эмуляции процессора запускали код, который компилировали под этот процессор, который вообще не существует. Можешь про это все рассказать как-то подробнее? Потому что это жутко интересно, и вот довольно тяжело это в голове уложить.

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

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

А: У меня вопрос. Если я тебя правильно понял, вы писали компиляторы неоптимизирующие.

И: Ну, лично я — да.

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

И: В оптимизирующем компиляторе, да.

А: А, вот оно что. Просто я еще очень удивился, потому что, я вообще-то не специалист, и по моим представлениям неоптимизирующая компиляция — это довольно простая фигня. И у меня возникло удивление, что миллионы строк кода и неоптимизирующий компилятор. То есть я могу себе представить там, что если вы эмулируете все флаги gcc, то — может быть.

И: Да, там с gcc было отдельная засада. Блок, который пытался эмулировать и повторять, что деляет gcc. Это, на самом деле, большой кусок кода рождался потом и кровью, потому что каждое изменение в файле, оно было черевато тем, что что-то где-то у кого-нибудь не заработает, иногда изменеия вносить надо, потому что внезапно новый какой-то GNU’шный пакет перестал правильно работать, ну перестал в смысле, что начали его делать, смотрим — он что-то не так делает.

Я в том числе принимал участие, я был в команде, которая делала полный порт всех GNU утилит на Эльбрус. Первую версию большинства утилит сделали именно мы, и это было давольно интересно, в том плане, что компилятор, который не пытался быть похожим с gcc постепенно приводился к похожести, потому что очень много в GNU-мире все-таки завязано на gcc, на его поведение, на его опции. Это тоже довольно интересный опыт, как сперва мы написаби bash-обертку вокруг нашего компилятора. В этом скрипте нам пришлось вводить таблицу соответствия gcc опций нашим, и как постепенно мы пытались в компиляторе нашем, в самом, сделать эту поддержку, аналогичную, и постепенно табличка уменьшалась, уменьшалась, сейчас она теоретически, вообще, ее не должно быть. Не знаю, закончили они с ней. Там достаточно, все рано, удобно вести подобную обертку на bash, хотя бы для того, чтобы логи смотреть, что, где компилируется, какие приводятся ошибки, и так далее.

Довольно большая работа была сделана, которая на самом деле не видна. Все говорят: «Вот Эльбрус — давай посмотрим, что там такое! ОС МСВС установлена, отлично!» А то, что там на самом деле за этим стоит довольно большое количество технологий, которые рядышком стоят и которые необходимы для этого, это не сразу, не на первый взгляд видно.

А: Сереж, твоя очередь задавать вопросы.

С: Ну, я тут, на самом деле, не столько вопрос поставлю, сколько реплику по поводу того, что Ваня рассказал по поводу огромного объема невидимой работы. Мне в свое время приходилось в институте на курсе операционных систем, чтобы не вылететь из института, потому что я прогуливал этот предмет зачем-то, делать маленькое-маленькое, я бы сказал даже — малюсенькое недо-ядро на чистом ассемблере под 486 процессор. Это был 94-95 год, документации почти не было. Сколько мы убили времени со своим другом на то, чтобы разобраться, как все это работает. Информации тоже было достаточно мало. По-моему был четырехтомник такой, он так и назывался, «486 процессор». Там было достаточно много инженерного, и практически ничего программистского. Поэтому, когда я слышу, когда народ говорит: «А, там, эта операционная система — ерунда, компилятор фуфло», у меня невольно в голове возникает мысль: «Ребята, ну вы бы попробовали написать хотя бы процент от того, о чем вы говорите, вы бы так не говорили».

А: Вань, мне интересно, а как выглядит, скажем так, workflow при разработке компиляторов? От кого поступают feature request’ы, кто делает bug report’ы? Ну, отдел QA тестирует — понятно. Как часто у вас происходят релизы, и вы заливаете куда-то бинарную сборку «чуваки, скачивайте», или как?

И: Я думаю, что основным направлением работы, фактически, является сдача гос испытаний. Это какие-то гранты, и необходимо под требование этих грантов попадать, соответствовать им. Поэтому, есть какая-то задача, и, начиная с некого верхнего уровня, происходит планирование, что необходимо для решения этой задачи, начиная с железа, и заканчивая поддержкой в компиляторе и окружающих утилитах. Поэтому feature request’ы это были в первую очередь соответствия этим требованиям. Бывало так, что какой-то баг находился в последний момент, но он сильно действовал на сдачу гос испытаний, все бросали все и начинали править баг, хотя следующие испытания вставали, фактически, на какое-то время.

Я ответил на вопрос?

А: Да, вполне. Скажи, как же так получилось? Дело в том, что, по моим представлениям, в мире программирования довольно трудно сменить нишу. У меня так получилось, что я в студенческие годы пошел подрабатывать, подрабатывал как полу-веб разработчик, и у меня всегда какой-то server side, какой-то веб, какие-то базюльки с тех пор. Как тебе удалось сменить-таки нишу? Это что, это я реально так не прав, или это было очень трудно? Тебя, фактически, без опыта серверсайда взяли в Echo, на серверсайд.

И: Да, так и было. Касательно, почему взяли, я думаю, что Echo всегда брало людей по тому, ну не по текущим знаниям, а по по какому-то понимаю того, будет ли этот человек работать или не будет, грубо говоря.

А с точки зрения меня, моей мотивации, мне было интересно окунуться в эту область, потому что мне, наверное, в целом интересно оглядываться вокруг. Я увидел, что есть возможность, я увидел, что, в принципе, неплохо платят, у меня появилась возможность уехать из Москвы, я в целом к Москве больше негативно отношусь. И так все сложилось, что я взял и поехал. Да, было не очень просто, да, переезд вместе с семьей и ребенком из одного города в другой — это довольно тяжелая вещь. Но, так получилось, и, в принципе, неплохо получилось, я доволен.

C: В общем, так совпало, очень много факторов, насколько я понимаю.

И: Да.

А: Давай последний вопрос по компиляторам, и перейдем к каким-то другим вопросам. Сколько же можно, в самом деле? Что бы ты посоветовал начинающим разработчикам компиляторов, разработчикам pet project’ов, а не тем, кто хочет заниматься этим профессионально, потому что это довольно специфическая область. Ну, вакансий мало и все такое. Что бы ты посоветовал, вот, допустим, я хочу написать свой маленький компилятор, или, большой. У меня, например, есть давно идея скрестить Erlang с Haskell в какой-то пропорции. Вот что бы ты посоветовал?

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

И, наверное, начинать «make it simple, make it fast». Сделайте хотя бы простенький прототип, который работает, потом пытайтесь его усложнять. От простого к сложному намного проще делать, чем начинать писать оптимизации на неработающем еще кодогенераторе или парсере. Как-то так.

А: В предыдущем выпуске ты имел неосторожность сказать, что у вас Haskell используется на server-side, это так?

И: Слушайте, я прям столько неосторожностей имел в прошлом выпуске. Да, это так.

С: Это Саша нагнетает просто.

А: Проблема с подкастами — все записано, не отмазаться. У меня такой вопрос. Один наш с тобой общий знакомый, у него есть такой интересный поинт, что в Haskell все очень плохо с рефлексией. У тебя когда что-то в продакшене долго работает и внезапно ломается, ты не можешь так просто по remsh зайти и посмотреть, под что там память выделена, и где очереди переполнились, stacktrace посмотреть. Как же так? Вот рефлексии нет, а в продакшене используется?

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

А: Я еще обратил внимание, что для меня, вот, я пишу на Erlang довольно долго. Вот для меня такой психологический барьер к переходу на Haskell, один из, в продакшене. В Erlang, если у тебя дохнет процесс, то у тебя добрый supervisor его перезапускает и все дальше работает. А в Haskell тебе, ну, если процесс вдруг случайно сдохнет, то он сдохнет совсем, если ты не догадался прикрутить Cloud Haskell, или, не знаю, сделать какую-то обертку, чтобы поймать все исключения, или не используешь какой-нибудь Scotty, например, у него если в handler-е бросать исключение, то сервер не падает. А как в Echo решается эта проблема?

И: Ну, я еще немножко к предыдущему вопросу вернусь, у нас большой опыт работы не только с Erlang-ом в продакшене, у нас же и OCaml, и Си, и сейчас вот Haskell появился. У нас есть опыт работы с подобными другими технологиями, не Erlang-овскими. Касательно Haskell, да, если у вас Haskell-ный процесс запущен как порт к Erlang, то Erlang будет его сам рестартовать в случае падения. Если у вас это отдельный сервис, который сам по себе висит, конечно, вам необходимо заботиться, чтобы он в случае падения рестартовал, а если он еще и state имеет какой-то, чтобы он этот state пытался поднять откуда-то дополнительно. Сложности есть, но они все решаются, ты сам назвал несколько возможных решений, которые уже есть в интернете.

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

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

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

С: Да, конечно, у меня очень много вопросов. Вот, смотри, у вас есть. Точнее, у вас до этого был и есть довольно большой опыт с OCaml. И сейчас появился Haskell. Собственно, вопрос, почему он появился? Это желание попробовать что-то новое, или OCaml вас не устраивает. Может быть для решения той задачи или вообще в целом.

И: Вопрос очень хороший в том плане, что это в целом для всех компаний довольно сложный вопрос. Вот, скажем, есть какая-то новая технология, трогать ее или не трогать. Я думаю, что у нас и OCaml появился таким же способом, каким появился Haskell. Это, в первую очередь понимание того, что язык подходит для решения данной задачи. Есть несколько человек, у которых есть опыт работы с этим языком. И, наверное, банально любопытство: «а давайте попробуем и посмотрим, получится или не получится». Я думаю, OCaml бы подошел для решения данной задачи. Но человек который решал эту задачу сказал: «А почему бы не Haskell?» И мы сказали: «Да, почему бы не Haskell?»

С: Но я правильно понимаю, что этот человек у вас не единственный, и кто-то другой может подхватить этот кусок?

И: Да, да, и ревью сможет сделать и обсуждения были на тему архитектуры.

А: Валер, твой вопрос.

В: Мой вопрос? Какой мой вопрос?

А: Последний для этого выпуска.

В: Почему ты думаешь, что у меня все еще есть какой-то вопрос?

И: Это отличный вопрос, разрешите мне ответить на него!

В: Но я, кстати говоря, я так и не понял, каково это — писать софт, который исполняется софтом. Как, что это вообще выглядело. Как какая-то виртуальная машина, или как что? Как это, работать с симулятором процессора? В каком это вообще виде интерфейс?

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

В: We need to go deeper.

С: Это напоминает мне забавный эксперимент, который я раньше делал, когда я пытался в каком-нибудь VPC запускать VMWare, а в нем какой-нибудь VirtualBox, посмотреть, что из этого получится.

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

А: Ты пропал :(

С: На самом интересном месте.

И: Этот скайп мне сегодня надоел, что-то с ним какая-то беда.

А: Я думаю, скайп намекает нам на то, что у нас 35 минут прошло даже с поправкой на все разрывы. Так что на этот раз все, но мы с вами не прощаемся, у нас будет еще один выпуск, а за ним, может быть, последуют остальные. Так что, вы подписывайтесь, у нас есть RSS, есть Twitter, iTunes, а также Google+. У нас есть даже почта, можно подписаться на подкаст по почте. Жмакайте лайки, не забывайте, и спасибо, что слушали. До следующего выпуска, всем пока.

С: Пока!

В: Пока!

И: Счастливо!

Дополнение: EaxCast S01E07, интервью со Светланой Божко

Метки: EaxCast.