SDCast #63: в гостях Алексей Маркин, программист из МЦСТ

Приветствую, товарищи! В предыдущем выпуске мы немного затронули тему процессоров «Эльбрус» и VLIW-архитектуры , но эта тема показалась интересной, и вот, в этом выпуске у меня снова в гостях Алексей Маркин, программист из МЦСТ, и этот выпуск целиком и полностью посвящен этой теме.

Вначале Лёша рассказал немного про компанию МЦСТ, историю её появления и развития, направления деятельности, и чем компания занимается сейчас.

Далее мы поговорили про процессоры «Эльбрус», что они из себя представляют, чем они принципиально отличаются от других архитектур (x86, ARM, RISC и прочее). Для VLIW-архитектуры «Эльбруса» порядок инструкций исполнения программы имеет особо важное значение, так как процессор не умеет их сам переставлять, поэтому оптимальный порядок формируется уже на этапе компиляции программы, и компилятор является неотъемлемой частью архитектуры.

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

Так же обсудили сам процесс разработки компилятора, какие инструменты используются в команде разработки в МЦСТ, как устроено тестирование и сбор метрик, бенчмарки и замеры производительности.

Ссылки на ресурсы по темам выпуска:

Понравился выпуск? — Поддержи подкаст на patreon.com/KSDaemon а так же ретвитом, постом и просто рассказом друзьям!

Скачать (mp3, 65 MB) Скачать (ogg, 49 MB)
  • Ivan Glushkov

    Очень интересный выпуск! Как и предыдущий!

  • Ivan Glushkov

    “За несколько дней чинят баги во фронтенде” – это явное преувеличение.
    Не знаю, как сейчас, а раньше с ними насчет многих багов приходилось сражаться, доказывая их важность.
    Большинство проблем обходилось либо какими-то хитрыми настройками опций, вида, “наш инлайн выключить нельзя, но если включить “ansi C, то он не применится, если еще вот эту опцию передать”, или “у нас не получается сделать нормальный switch, но вы уж там сами как-нибудь из наших if-else табличку переходов постройте” или наоборот, уже не помню.
    Или наклеиванием дополнительного скотча и палок в обёртке над фронтендом, поэтому остальные разработчики этого не видели.
    Я точно помню, что было несколько багов, которые они чинили несколько лет.
    Но однозначно, ребята в EDG очень толковые, хорошо работают на поддержке и неплохо развивают свой продукт.

    • Про несколько дней – со слов отдела, с ними контактирующего, но да, некоторые вещи они делать отказывались вообще (вроде с vla были особые проблемы). Ситуация с inline и switch – это скорее оптимизационная часть. На данный момент тем или иным образом inline от них не используется (из-за него были проблемы производительности), а вот со switch – не очень понял. Он приходит на архитектурно-независимое представление как обычный SWITCH NODE, т.е. такой абстрактный switch, из которого торчит множество дуг. Если они его пытались на фронтенде оптимизировать, то это печально. У нас он тоже долгое время был сделан довольно криво, но сейчас ведутся активные работы по выправлению ситуации. В любом случае перекладывать оптимизацию на фронтенд сейчас мне видится не самой хорошей идеей.