Всем привет! На этой неделе с вами Алексей @alexanius Маркин, программист из отдела оптимизирующих компиляторов.

Я работаю в небольшой фирме, занимающейся разработкой микропроцессоров на основе VLIW архитектуры. И это очень весело!

Поэтому ближайшая неделя будет посвящена процессорам Эльбрус, компиляторам, оптимизациям и обучению студентов

Расскажите, кто из вас слышал что-нибудь про процессоры Эльбрус? Может даже работали с ними?

Ну а пока вы ещё не проснулись, в кратце расскажу про процессоростроение. В России существует несколько фирм, разрабатывающих процессоры.

Разрабатываются они на разных архитектурах. Есть MIPS, ARM, собственные. Как вы уже догадались,я из МЦСТ, и у нас есть 2 линейки процессоров

МЦСТ разрабатывает 2 архитектурные линейки процессоров - на основе Sparc и на основе VLIW архитектуры (Эльбрус, он же e2k)

VLIW - Verly Long Instruction Word. Это означает что в одном машинном слове у нас зашито множество команд. Т.е. можем исполнять 23 за такт!

@backendsecret производительность. ну и собиралось очень долго (хотя не пробовали кросс-компилятор еще). Пакет? Мы свои велосипеды пробовали

@backendsecret Скажем так, я видел, что на нём работает, но не могу об этом распространяться)

При переносе на Эльбрус действительно может проседать производительность. Часто это проблемы в самом коде.У нас есть отдел который их решает

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

Работа с целочисленными задачами (ну большинство десктопных) даётся ему сложнее, но в целом вполне сносная ;)

Раз уж заговорили про компиляторы, то наш (lcc, он же ecomp) в режиме -O3 прогоняет более 350 оптимизационных фаз

Поэтому работает он значительно дольше какого-нибудь gcc или llvm

. @astarasikov про многопоточность - чуть позже, т.к. сам я с ней не работаю. Но поспрашиваю у других отделов

. @saint_armadillo Да, статьи были, довольно интересные, был даже наш официальный ответ, тоже на хабре :)

@backendsecret слежу за новостями про Эльбрус уже больше 10 лет, интересно будет почитать вас

А пока расскажу что ещё есть на тёмной стороне архитектур. Как и у любого VLIW'а,у Эльбруса много регистров. Их целых 256. Хотя этого мало..

@backendsecret @ruxeg очевидно, что имеется в виду 2004 год. В лагере школьнику что 10, что 20 лет - вечность

О, восхитительные истории про Бабаяна и Интел, сразу универ вспоминается. twitter.com/backendsecret/…

@ruxeg @backendsecret Бабаян — это как Пентковский.

@webholt @backendsecret бабаян это как домовик или акопян?

@backendsecret слышала что-нибудь на уровне "такое существует".

Далее Эльбрус (и наши Sparc'и тоже) - это In-Order процессоры. Т.е. процессор не умеет выбирать готовую каманду в процессе исполнения

Порядок исполнения инструкций задаётся компилятором и не меняется. (Современные x86 и ARM - Out-of-Order,т.е. они аппаратно выбирают инстр.)

Т.е. по сути то, что на данный момент процессор делает аппаратно в runtime, в Эльбрусе должен сделать компилятор в compile-time

Отсутствие Out-of-Order - не минус, а скорее особенность. Но жить с ней гораздо сложнее

И ещё это одна из причин дико сложного компилятора. Почти всё приходится делать статически, предугадывать исполнение программы

Оу, извиняюсь за грамматику - на моей машине spell checker не настроен...

Профилирование проходит в 2 этапа. Сначала собираем программу со спец. инструментированием и прогоняем её на тестовых данных

Инструментированная программа собирает информацию о том какие участки сколько исполнялись и сбрасывает в файл.

Далее повторно компилируем программу с указанием собранного профиля и оптимизируем то что нужно

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

Кстати сейчас такой способ компиляции активно развивается в mainstream компиляторах, но у нас профиль интегрирован значительно лучше

@backendsecret @SheVasya на хабре читал

Вообще существует мнение,не безосновательное,что vliw- это dsp архитектура.Тем не менее нам вполне удаётся применять её как general purpose

Ещё одна страшная особенность Эльбруса - отсутствие предсказателя переходов :) Собственно поэтому нам так важен профиль

С плавучкой есть интересный момент. У нас для неё используются регистры общего назначения

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

А если серьёзно, то даже если бы я и знал, то не имел бы права рассказывать об этом

На всякий случай - я не сразу буду отвечать на все вопросы, т.к. на некоторые ответа не знаю, но постараюсь их спросить у тех кто знает ;)

Но на лекции Бабаяна была в основном критика Superscaler'ов в целом. Ну и рассказ про его перспективную архитектуру был немного абстрактный

@backendsecret привет от человека, который сидит через кубик от Б.А. :)

@backendsecret @koirn в проде у таких систем и ОС проблемы связанные с процедурой сертификации по БИ. Из за этого есть куча вопросов >>

@backendsecret @koirn > с обновлениями безопасности. У системы известная дырка, а обновить нельзя, т.к еще не сертифицировано.

@backendsecret @koirn получается, что только для изолированных систем. В открытых - огромное количество рисков - решить оперативно нельзя

. @ffads93_zombie сам не пробовал, но мой коллега портирует sanitaizer для использования в защищённом режиме, дистрибутиву помогает

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

Очень большая проблема с JIT'ами. Пока нет нативного порта, они работают в режиме интерпретатора. Это катастрофа. Но уже есть порт jvm.

@backendsecret @workaround9 слышал, в руках держал, но не работал.

В МЦСТ работают по большей части МФТИ, МГУ ВМК и МИФИ. Представители других ВУЗов - редкое исключение.В МФТИ у нас есть своя базовая кафедра

Я работаю в нативном компиляторе, в отделе оптимизаций. В институте даже не подозревал что буду этим заниматься.

Попал в МЦСТ уже после окончания института. Т.к. у меня не было предметов, которые были у МФТИ'шников, до сих пор приходится многое учить

Но, как ни странно, сейчас в МФТИ читаю лекции по оптимизирующим компиляторам. Вот такие забавные вещи иногда случаются

На всякий случай - я очень рад что закончил именно МАИ, т.к. там сильное программирование. Но там совсем не преподаётся аппаратная часть

@backendsecret Я в институте тоже не подозревал, что подпишусь на @backendsecret и там будет ведущий, который.... тоже не подозревал

Зарплаты у нас вполне конкурентные (сопоставимы с моими одногрупниками из других фирм). Достаточные чтобы не сбежать сразу.

Как я уже говорил, branch prediction'а у нас нет. OoO тоже. Для VLIW'а это нормально, в нём работают другие механизмы борьбы с ветвлениями

Во-первых у нас есть 3 регистра подготовки перехода. Чтобы не тратить время на переход, мы заранее кладём в них адрес и подгружаем команды

Три штуки нужно т.к. мы заранее не знаем куда прыгать

Но в VLIW имеет гораздо более крутые механизмы. Мы можем вообще избавляться от ветвлений. Например у нас есть предикатный режим

Предикат - это специальный флаг в отдельном регистре, который говорит должна ли исполняться команда или нет. В Эльбрусе 32 предиката

Т.е. мы можем тупо взять несколько ветвлений и слить в один линейный кусок.

. @fads93_zombie Если имеется ввиду внезапное изменение bias'а, в нативной программе, то никак - страдаем. Если при трансляции - то не знаю

@backendsecret If-conversion/Predication - наше все для VLIW'ов :)

Помимо предикатов для хорошего слияния ветвлений (if-conversion) нам нужен спекулятивный режим.

Суть в том что мы можем исполнять команду, но она ни на что не влияет пока её результат не использован несепкулятивной командой

Например мы можем сделать обращение к памяти по невалидному адресу, но если оно так и осталось невостребованным, то ничего не случится

Т.е. код { if( ptr != NULL ) *ptr; } мы можем превратить в { *ptr; if( ptr != NULL ) ... }. Это позволяет гибко планировать исполнение кода

Ещё у Эльбрусов есть классная фишка - apb. Это асинхронная подкачка данных. От prefetch отличается тем что исполняется в отдельном потоке

Т.е. если у нас идёт обработка массива, то параллельно с вычислениями мы подгружаем данные со следующей итерации.

@backendsecret знаем, очень крутая архитектурная штука, как и базированные регистры :)

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

Например в регистрах r1-r32 выделим базу r10 и размер базы 5. Тогда b[0] будет обращением к r10, b[1] - к r11 и т.д.

Потом мы можем сдвинуть эти регистры получить обращение b[0] - к r11, bи[1] - к r12 и т.д. Это аппаратная поддержка конвейеризации циклов

@backendsecret Эльбрус - это не процессор, это школа отечественной вычислительной техники!

. @boolker насчёт пары - не могу сказать ) Но вполне возможно. Тут, думаю, нужно чтобы вы как организация это оформляли

Вообще сравнение процессоров - штука очень скользкая, т.к. нужно понимать что и как сравнивается. И понимать как результат интерпретировать

Затрагивали тему трудоустройства.У нас катастрофически не хватает людей.Если вы хотите оказаться по ту сторону процессоров - приходите к нам

. @GolubevVictor присылайте резюме на resume@mcst.ru, у нас много отделов на разный вкус, вот примерный список mcst.ru/vakansis

Ещё одной killer-фичей Эльбрусов является защищённые режим.В нём мы аппаратно тегируем объекты памяти и запрещаем работу по невалидному типу

По факту это является аппаратным аналогом sanitaizer'а. Режим довольно специфический, но может сильно помочь при отладке на машине

Да и не только при отладке. Такой режим не даст злоумышленнику реализовать соответствующие типы уязвимостей ПО

@backendsecret например, ROP-атаки: нельзя подменить адрес возврата тк 1) адрес - это указатель, 2) аппаратно проверяются права на запись

@backendsecret про это рассказывал @dzavalishin на @Ulcamp по-моему крутая штука

По частоте - на Эльбрус-4С 800 МГц (на старых выпусках 750), на 8С - 1.3 ГГц

. @meeverone могу показать roadmap (предпоследний слайд) mcst.ru/files/5575fb/a…

. @KernelByte да в принципе ничего специфического. Просто понимать как работает процессор, память, компилятор

Ещё интересным следствием In-Order процессора является то что компилятор должен сам вычислять задержки инструкций. Имеем адское планирование

. @egregors Вполне конкурентные. Мне пока что хватает :)

. @KernelByte Всё зависит от того куда устраиваться.К нам джуниором очень легко.Достаточно знать язык, уметь простые задачки, быть адекватом

. @KernelByte всё равно разрабатывать компилятор мало кто умеет, по сути всему с нуля учим

. @KernelByte а вот остаться уже сложнее. Тянут не все. Причём это не показатель ума, просто это сложно. Да и на любителя работа

. @strangeqargo для того что мы делаем этого очень мало. Тасков гораздо больше чем мы можем выполнить

@strangeqargo Бывает что уезжают. Кто на совсем, кто с возвратом. Даже если один человек в 3-4 года, это ощущается

@backendsecret зависит от мотивации. Это молодой ты дерзок и горяч, работаешь за идею самореализации, а когда дети и родители пенсионеры

@backendsecret то и за деньги поработать идея нормальная.

Про разработку компилятора я завтра весь день рассказывать буду :)

. @de_gis ФРТК, кафедра информатики и вычислительной техники (базовая МЦСТшная)

. @de_gis это тема для любого программиста :) Просто на базовой кафедре мы сами решаем какие предметы давать и сами их ведём

@KernelByte @backendsecret деньги есть индекс независимости.Когда у вас выбор нелюбимой работы за 50тр и любимой за 20тр,странно выбрать 20

Астрологи предсказали неделю «Эльбруса» :: habrahabr.ru/post/313376/ :: @backendsecret

Тема компилятора Эльбруса окутана плотным покровом тайн и мифов как и сам процессор. Сегодня я буду срывать их

Самый частый миф в том что мы взяли и доработали gcc. Самый смешной из встреченных - что мы доработали lcc (little c compiler)

А какие слухи попадались вам? Очень люблю почитать что про нас пишут, ужаснуться, посмотреть в код и успокоиться

Фронтенд - не самая большая часть компилятора. И не самая долгая по времени работы

Страшная тайна в том что весь бэкенд полность написан нами. Опенсорсного кода там нет вообще

Даже больше скажу - я не представляю как его туда прикрутить

В начале своей работы я как-то хотел взять одну оптимизацию из gcc, но быстро понял что это просто технически не получится

Да и скорей всего мне в итоге не разрешили бы по лицензионным соображениям

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

Да и если честно, копировать алгоритм из gcc в принципе весьма сомнительная идея

Сейчас наш компилятор занимает > 2.5 млн. строк кода. Из них ~0.66 млн строк - форонтенд

Написан на чистом Си, почти 89 стандарта (есть пара незначительных послаблений).

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

В проектах подобного рода наблюдается большая инерция. Так, например на svn мы перешли всего пару лет назад. до этого использовали cvs

Сейчас мы собираемся gcc 4.6. Переход на более новый gcc (5 или выше) мне пробить пока не удалось - придётся обновлять всю инфраструктуру

Релиз компилятора происходит примерно раз в год. Это позволяет иметь довольно надёжную и отлаженную версию.

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

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

К компиляторам предъявляются особые требования надёжности.Например вместо svn commit у нас есть скрипт,который сначала проводит тестирование

Тестирование проходит довольно долго. В последнее время самое быстрое - 4-5 часов. Может в плохих случаях идти больше суток

Тестируется сборка, лёгкий тест производительности, ошибки наджности, сборка linux и т.д. Это называется "оперативное тестирование"

Такая система позволяет значительно уменьшить вероятность закоммитить откровенную лажу. Тем не менее это всё равно случается

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

Даже если бы победил git, он бы всё равно использовался как svn. Просто потому что иначе не хватило бы мощностей для тестирования веток

. @Xedin svn работает и хорошо вписывается в наш workflow. Зачем менять то что работает? Тем более у git для нас нет явных преимуществ

"Вся инфраструктура" - это десятки серверов и сотни различных скриптов. (на самом деле в итоге всё сведётся к s/svn update/git pull/)

Я на самом деле удивлён что мы при таком подходе с cvs слезли, но это реально был ад :)

На непрерывное тестирование бранчей просто машин не напасёшься. Да и тестировщиков тоже

Ещё интересный момент заключается в том что если мы протестируем бранч, в нём не будет ошибок,то после мерджа с транком он может развалиться

Связано с тем что оптимизационные фазы очень сильно влияют друг на друга и небольшая смена контекста ставит всё с ног на голову

Т.е. отдельные бранчи уведут ресурсы, а по сути тестирование будет неполноценным.

Про 5 тасков на каждом - это я не совсем правильно сказал. Каждый одновременно над ними работает. Так на каждом от 30 до 60 багов примерно

@backendsecret Не уверен... весьма старомодно я бы сказал... Вообще тестирование перед коммитом - это почти бранч...

Наблюдать, как @backendsecret отбивается от каргокультистов гита - бесценно

Система тестирования не позволяет делать коммит если он ухудшает производительность более чем на 20% хотя бы на одном из тестов

Из-за этого у нас нельзя напрямую откатить правки. Нужно влить новое исправление с откатом чтобы корректировались таблицы производительности

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

@backendsecret просто для небольшой команды компиляторщиков лучше подходит дисциплина с предкоммитным тестированием и централизованным репо

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

@backendsecret @Vlad_P53 мдее…. Сочувствую вам… Здравствуй [Новая папка], [Новая папка 2] и т.д….

Я поначалу, если что, тоже был фанатом git'а. Но со временем понимаешь что это не так удобно как кажется.

Локальные бранчи - единственное чего не хватает, но сейчас я просто делаю коммиты мелкой гранулярности. Так гораздо проще отлавливать ошибки

Дратути twitter.com/backendsecret/…

Если нет явных преимуществ git или git-svn над чистым svn, то разумеется никто не будет в этом копаться

Наброшу ка ещё немного... У нас больше половины разработчиков сидят в gvim !

@backendsecret это сразу всем наброс - и консольщикам и IDE’шникам?)

@Slaaless @backendsecret cp -r project{,_`date "+%Y-%m-%d_%H:%M:%S"`}

@backendsecret если между текстовыми редакторами нет большой разницы, то зачем платить за MSVS/JetBrains/Sublime?

А после среза ветки ещё и дистрибутив усиленно тестируется (в смысле сильнее чем обычно)

@backendsecret @Dronmdf а раз в год все уходят в запой?

. @alexgpg @fads93_zombie Гит можно было бы использовать с точно такими же use-casa'ами. Просто весь вопрос: а зачем тогда git?

@backendsecret @alexgpg @fads93_zombie о чем вообще срач, если нету внешних публичных форков и вся команда в одном здании?

@backendsecret Мне просто очень нравится gerrit :), всем рекламирую, но он для git.

Ещё есть узкое горлышко - переполучение таблиц производительности. На нём все правки выстраиваются в ряд и ждут своей очереди

Упоминание vim'а открыло портал в ад ))

@fads93_zombie @backendsecret это если пользоваться IDE как текстовым редактором ;)

@backendsecret т.е вы их в темной клетке держите большую часть времени а потом показываете vim и еду рядом. Еще бы они его не полюбили

@strizhechenko @backendsecret А ведь никто не спросил Вим-а, когда перетаскивали в винду - а хочет ли он жить в винде :))

На самом деле никакого ограничения на инструментарий у нас нет - каждый пользуется чем хочет. Просто людям gvim реально удобнее

Слова не мальчика, но мужа. twitter.com/backendsecret/…

@backendsecret pic.twitter.com/Q8JgclvjAL

@backendsecret «говорил вим удобный такой, быстрый, все делать можно, ну а потом конечно в дурку попал»

@backendsecret ниужто пробелы! За остроконечники набегут

Во, у меня есть супер-наброс. У нас запрещены англоязычные комментарии!

Не знаю с чем связано. Мне говорили что на случай утечки исходников к потенциальным друзьям. До сих пор не понимаю серьёзно они или нет

@backendsecret У Вас и ассемблер по русски наверное пишется... жуж туда сюда... :)

Но если совсем честно то я привык вообще не верить комментам и смотреть в код. Так что потенциальных друзей они максимум запутают

Кстати наши ядерщики придерживаются kernel coding style, поэтому когда я в нашем стиле написал модуль для ядра, меня ждал неприятный сюрприз

@backendsecret потенциальные друзья умеют читать по-русски :)

@Vlad_P53 @backendsecret @fads93_zombie хорошо сконфигурированный вим даст фору многим IDE.

@backendsecret всё правильно

@backendsecret так и пишите "тут реализаций представителя активности которая использует перегруженную реализацию сетевого стелажа", ад.

это для любителей кумира и 1с:предприятия. twitter.com/backendsecret/…

Расскажу про наш отдел тестирования. При оформлении ошибки тестировщик обязан полностью её разобрать и указать какая оптимизация виновата

И если когда компилятор падает на assert'ах это не проблема, то ошибки исполнения могут быть сущим адом

Хуже может быть только ошибка несличения результата :)

Такие обязанности тестировщиков приводят к тому что в общих чертах они с оптимизациями знакомы лучше чем разработчики :)

Кстати разбирать runtime ошибки на VLIW'ах - это адская жесть. В одной широкой команде могут быть инструкции из разных концов программы

. @backendsecret Только вот по факту можно выбрать только одно ;)

Ещё у нас есть клёвый режим тестирования - с рандомными опциями компилятора. Когда приходят такие ошибки - хочется убивать

@xomaa @backendsecret неправильная аналогия. Мы говорим не об автоматизации, а о внесении изменений ради изменений, без пользы для бизнеса

. @xomaa @alexkorotkikh очевидно, про замену git на svn

. @Alex_MIPT лучше по-нормальному ) От транслита глаза вытекают

Компилятор умеет работать под 3 хостовыми архитектурами и генерит бинарники под 2 архитектуры. И везде должен работать одинаково

Сравнение результатов кроссовой и нативной версии - ещё одно направление тестирования

Кстати, интересно что у нас местами терминология отличается от мировой. Например basic block у нас называется "линейный участок"

Если не знать таких особенностей, то бывает сложно искать публикации на английском

Кстати внутри компилятора у нас активно используются assert'ы и различные чекеры. По сути имеем контрактное программирование

Ну и да, разумеется C-style ООП со своим менеджером памяти и наследованием ;)

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

Без надобности в чужой код никто не лезет, т.к. он не знает что там работает и как. В таком подходе есть свои плюсы и свои минусы

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

Когда разработчик уходит - его модули перераспределяются между оставшимися. Очень весёлое занятие :)

. @dimaip в продакшене фича-флагов, конечно же, нет

Поясню: у нас существует 3 варианта сборки компилятора: отладочная, быстрая и релизная

Отладочная содержит кучу чекеров и debug info. Но она из-за этого долго работает. Быстрая содержит меньше чекеров, нет debug info

Релизная не содержит ничего, в т.ч. фича-флагов, применяемых только разработчиками и тестировщиками

@backendsecret нормас, у нас в сишарпном проекте ваще есть несколько функций с именами на русском

@Frame_Bassman @backendsecret с именами из эмодзи

. @alexey_m_ukolov да, он самый

@backendsecret жуткая картина - абстракции протекают на трамвайные рельсы, трель звонка, голова разработчика катится по мостовой...
:)

В какой-то момент мы упёрлись в то что нам не хватает скорости работы hdd и перешли на ssd. Иначе тестирование слишком сильно тормозило

Вот бы это в уши нашему менеджменту. twitter.com/backendsecret/…

У нас в этом плане специфический подход. Если что-то мешает разработке, это быстро разрешается. Если не помогает - хрен добьёшься )

Кстати, а много разработчиков компилятора читает этот твиттер? Я пока что только одного увидел.

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

Я уже не говорю про то что я не смогу с одной рабочей копией по несколько тестирований запускать

@alexkorotkikh @backendsecret если с git-ом команда будет более эффективнее - смысл бизнесу есть. Иначе - шило на мыло, конечно не стоит.

@backendsecret, прелесть в реализации, а не в концепции

. @trueneu а чтобыло несколько месяцев назад? Я как-то пропустил

@backendsecret никогда не понимал, как можно холиварить об инструментах, если они не мешают пользующемуся и делают дело - какая разница?

@trueneu @backendsecret бывает так, что люди привыкают к убогим инструментам и практикам, и упорно не хотят переучиться(я не про vim сейчас)

@trueneu @backendsecret в итоге делают свою работу хуже и медленнее, чем могли бы. это, как минимум, раздражает

@backendsecret адский срач под постом 'и как эти ***** используют этот ***** vim'. Пост собрал рекордное количество идиотов с обоих сторон

@backendsecret вот оно: m.habrahabr.ru/post/307084/

@quit_ka @backendsecret согласен, так бывает, но, дамы и господа, согласитесь - это не проблема инструмента.

Давайте поговорим про использование компиляторов. Какие используете вы, под какие платформы?

@backendsecret gcc/clang, linux (centos 6, x86_64) и OS X (чисто для тестов того же кода для linux, чтобы далеко не ходить с локалхоста).

Мы, кстати, собираемся сначала gcc под linux x86, потом сами собой под linux e2k и sparc v9. Ещё под solaris сборка есть

@backendsecret GHC, clang, gcc. Для centos 7. Разработка и тестирование под macOS.

Вы пишите что используете и gcc и clang (надеюсь в смысле llvm). А зачем оба, что идёт в релиз, почему?

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

Современные компиляторы обладают богатым набором диагностик. В принципе имеет смысл собираться как минимум с -Wall -Werror

При этом по -Wall включаются далеко не все диагностики. Более того, gcc и llvm умеют ловить непересекающиеся множества варнингов

Так что пересборка проекта обоими компиляторами для целей поиска проблемных мест - весьма хорошее решение

А вот в плане оптимизаций всё не так однозначно. Когда я в поседний раз сравнивал режимы -O3 у gcc и llvm, последний плавучку проигрывал

Только вот у gcc была одна проблема... Далеко не все задачи корректно работали в режиме -O3. Я, на самом деле, был шокирован резултатами

Про llvm сказать сложнее, т.к. у них нет фортрановского фронтенда, а большая часть плавучки - фортран

Чятик, а вы используете оптимизации компилятора? Проверяете что после оптимизации программа работает корректно?

У нас дистрибутив собирается с опцией -O3, поэтому корректной работе компилятора в режиме агрессивных оптимизаций уделяется большое внимание

@Alvcohen @backendsecret win-1252? Это вообще законно?

Заметил что большинство проблем о которых тут пишут (кодировки, конфликты, ветви) у нас решается простыми организационными методами

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

Т.е. мы не сидим, разруливая безумные merge conflic'ы или сливая ветки. Мы хреначим код. Ну или комменты в твиттер

Когда у вас релиз раз в год и непрерывное тестирование транка, ветки git'овском смысле просто мешаются

Аудитория твиттера почему-то не воспринимает такой подход к ведению проекта, но в реальности у нас феноменальная надёжность компилятора

Для сравнения попробуйте собрать что-нибудь серьёзное при помощи gcc в режиме -O3 (я пробовал если что).

А мы нашим компилятором дистрибутив так собираем. И пришли мы к этому не так давно, года 2-3 назад. До этого тестировщики не разрешали

Жёсткий code review приучает перед тем как что-то коммитить хотя бы мельком просмотреть svn diff

@backendsecret а вот у git есть чудесное:

git add -p

который у нас прямо в должностной инструкции разработчика прописан :)

@backendsecret вот буквально 10 минут назад узрел в том, что коммичу неистовую диверсию от самого же себя и стало страшно.

. @strizhechenko всё больше склоняюсь к тому что административные меры эффективней технологий ;)

@Dronmdf @trueneu @backendsecret CI failure / хуки на ересь никто не отменяет.

Но глазами посмотреть что ты сделал - надо, ибо >>

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

Ситуация редкая, но случается. Такой ошибке выставляется стату P1 Blocker, и виновник обязан исправить её в течении суток

@strizhechenko @trueneu @backendsecret Да, не на все можно сделать хук. Но пробельчики - легко. И можно не ругаться а думать о глобальном.

@Dronmdf @trueneu @backendsecret ну так хуки + тесты + ревью глазами перед коммитом - минус 90% всякой гадости => меньше поводов ругаться.

В плане помощи друг другу у нас довольно дружный коллектив, я после сидения на гентушных форумах долго привыкал :)

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

@strizhechenko @backendsecret ты же помнишь про тёмную комнату без еды?

@ruxeg @backendsecret ммм, мой первый офис :D

Раз уж снова про организацию производства заговорили, расскажу как оценивается производительность компилятора

Понятное дело что все эти наколеночные тесты из одного цикла (или как сейчас модно "микробенчмарки") - это лажа

Промышленные компиляторы традиционно замеряются на специальных бенчмарках SPEC CPU. Они представляют из себя выдержки из реальных приложений

Отдельно идут целочисленные задачи (сжатие, xml, кодеки, ...) и с плавающей точкой (химия, гидродинамика, ...)

Эти тесты одни из наиболее репрезентативных, хотя, я бы сказал, немного устарели. К ним вообще много претензий, но лучше ничего нет

@backendsecret про гентушников и компиляцию есть слоган: "Watching shit scroll by for hours makes me a compiler expert overnight!"

Кстати с гентой и компиляторами я тоже игрался когда-то.Понял что собирать её с gcc -O3 - самоубийство,и что от llvm в этом плане толку мало

Давайте поговорим про оптимизации. Идеология VLIW такова что вся работа по поиску параллелизма и перестановке операций ложится на компилятор

Это делает необходимым наличие хорошего оптимизирующего компилятора. Оптимизации могут ускорять программу в десятки раз

Т.е .минимально рекомендованный набор в случае Эльбруса - это "-O3 -ffast". По возможности неплохо бы добавлять -fwhole (аналог -flto)

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

Пэтому для Эльбруса особенно важны такие оптимизации как inline, if-conversion и хорошие анализы указателей

Про inline можно сказать интересную вещь - по дефолту мы полностью игнорируем это ключевое слово в программах.

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

# из-за этого у компилятора не получалось проинлайнить то что действительно нужно

С инлайном ещё интересно то что сразу после его применения размер программы уменьшается. Хотя итоговый бинарь получается больше

Кстати, у нас есть оптимизация, обратная к инлайну. Она разрезает большие процедуры )

Обратные друг к другу оптимизации часто встречаются среди цикловых оптимизаций.

Например есть reroll. Это оптимизация, которая откатывает последствия ручного unroll`а чтобы выолнить его по-нормальному

Потому что никогда не делайте unroll руками! Это очень платформозависимая оптимизация. Компилятор лучше знает.

. @fads93_zombie там довольно много разных эвристик с попыткой предсказать эффект для других оптимизаций

. @ivbx некоторые алгоритмы квадратично едят память. Так что слишком большая процедура может не скомпилироваться

Разрезание процедуры может негативно сказываться на производительности, но лучше иметь тормозную программу чем уронить компилятор :)

А ещё лучше не писать больших процедур и не иметь проблем ;) А то видел я экземпляры по нескольку тысяч строк...

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

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

Мне иногда кажется, что если бы в своё время победил Itanium, то весь мир IT сейчас выглядел бы по-другому. Языки были бы более продуманы

Современный компилятор должен уметь делать межмодульные оптимизации. В gcc этот режим включается по -flto. У нас по -fwhole

Это немного разные технологии, но суть примерно одна: получить возможность видеть содержимое функций из других модулей

В таком режиме происходит много прикольных плюшек. Например глобальные переменные получают признак static.

Режим -fwhole позволяет проводить нормальные анализы указателей, проводить девиртуализацию виртуальных вызовов и т.д.

@backendsecret нет, просто компиляторщикам досталось бы больше проблем

Ещё есть очень классная штука - анализ указателей, основанный на типах. Он же strict-aliasing. С`шники тоже без ума от него, я знаю :)

Этот анализ позволяет хорошо рвать зависимости даже в помодульном режиме

Немного про “разрыв зависимостей” в ассемблере есть операции работы с памятью Load/Store. Операция load может работать долго

Если мы лезем в память, а не в кэш, то под сотню тактов и более. Мы стремимся запустить такие операции как можно раньше

Но нам неизвестно работают ли load/store по одному адресу. Задача анализа указателей выяснить это и разорвать зависимость

Обычно это сложные, ресурсоёмкие алгоритмы, нормально работающие только в -fwhole

Сегодня я предпочёл не строчить в твиттер, а поработать, поэтому ничего не писал. Давайте под конец дня ещё немного про оптимизации

Сейчас (по крайней мере год назад) в тренде было pgo - profile guided optimizations. Сама по себе постановка вопроса звучит как костыль

Т.е. мейнстрим компиляторы писали отдельные версии оптимизаций под использование профиля. У нас этот вопрос решён грамотно:

Профиль - неотъемлемая часть представления, оптимизации не могут его не использовать. Т.е. profile guided почти всё. Но это усложняет жизнь

Профиль нужно поддерживать в корректном состоянии, а это сложно. Даёт знать накопление погрешности плавающих операций

Loop unrolling @backendsecret twitter.com/turbojedi/stat…

Ещё интересной особенностью является ситуация когда пользователь не снимает реальный профиль (почти всегда). Тогда мы его предсказываем

Компилятор пытается статически угадать куда и с какой вероятностью мы пойдём, сколько итераций будет у цикла

Ещё хотелось бы поговорить про образование. Много ли читателей преподаёт в ВУЗах? Хотели бы? Да, нет, почему?

Мне вот в какой-то момент предложили, я подумал “почему бы и нет”. Преподаю чисто ради удовольствия. Ну и чтобы предмет изучить получше

Преподавание вскрывает массу интересных особенностей и проблем. Например у разных ВУЗов совершенно разный подход к обучению

@backendsecret по таким же причинам преподаю школьникам олимпиадой программирование

В МАИ на 8 факультете сильное программирование, причём практическая сторона. На физтехе больше математики и есть аппаратная часть

Очень разный подход к студентам (но я так понял что это от кафедры зависит). Где-то студентов за людей не считают, где-то с ними сюсюкаются

@backendsecret нет, преподавание - не мое. При этом люблю делиться знаниями. Тут главное, чтобы тебя слушали с интересом.

Из-за разности подходов и программ приходится адоптироваться в реалии института. Особенно если твой предмет требует фундамента

Но я тут ругал физтех, а лучший курс по компиляторам именно там ;) Хотя курса по автоматам и теории сложности не хватает

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

Во время подготовки своего курса русскоязычных материалов я использую менее 10%. Просто потому что их нет. Это ужасно, я считаю

Большой плюс публиции учебных материалов в том что обмен такой информации между преподами совершенствует программу

@backendsecret преподаю пару курсов, just for fun

Не знаю что бы я делал без десятка забугорных институтов, у которых смотрел что и как они дают и адаптировал к своему курсу

@ru_ostroumova @backendsecret в кемеровском универе

@backendsecret для меня iTunes U основной источник интересных курсов. pic.twitter.com/jJD1FK9A9m

@backendsecret все публикуется, просто похоронено в глубинах

@backendsecret программы вообще обязаны публиковать

@backendsecret удовольствие либо есть от этого либо нет, люди либо любят помогать либо нет

На русском, кстати есть неплохой ресурс с записями лекций lektorium.tv. На курсере ещё стали выкладывать русскоязычные лекции

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

@backendsecret
itunes.apple.com/ru/itunes-u/in…

@backendsecret еще иногда что-то здесь проскакивает: openedu.ru

Расскажите, а вас устраивает уровень джуниоров когда их берёте? Каких знаний или навыков не хватает?

@backendsecret джуны, как правило, начитаются теории, а поставить ту же базу или либу и поиграться, практики набраться - нет.

@backendsecret навыка доводить задачу до конца

В преподавании компиляторов часто опираются на классического dragon book, из-за чего пол курса рассказывают про создание лексеров/парсеров

Мне кажется такой подход устарел. Сейчас фротненд - не такая актуальная проблема и решается не так. А вот бэкенду уделяеется мало внимания

У нас компиляторы идут 2 семестра (лекции), и неплохо бы ещё добавить как минимум семестр семинаров с лабами

Ситуация осложняется ещё и тем, что на одной кафедре готовят и программистов (не только компиляторщиков), и аппаратчиков.

Но вообще изучение компиляторов необходимо аппаратчикам, как и аппаратуры - программистам. Иначе одни не понимают как работают другие

@backendsecret преподаю базы данных. Сумы, СумГУ.

@backendsecret да школьникам серьезное и не интересно, сам со скуки окочуришся)) там обычно в уровень и педагоги) общался с такой))

Интересное наблюдение: учебный курс получается гораздо лучше и полезнее если ведёт его человек, который в данной области деньги зарабатывает

@backendsecret я тоже базы данных преподаю в СПбГЭТУ (Санкт-Петербург)

@backendsecret полностью согласен. Но это работает если дают основы из параллельной специальности, а не пытаются вы… twitter.com/i/web/status/7…

@backendsecret преподаю на физтехе, чтобы быть поближе к уютненькому родному универчику.

Итак, друзья, пора прощаться спасибо за интересную беседу, надеюсь я не слишком утомил вас кишками компилятора.

Напоминаю, что с вами был @alexanius, научный сотрудник отдела оптимизирующих компиляторов в МЦСТ

И на последок - о самой лучшей методологии разработки написано здесь: macode.ru. Всем хорошего воскресного вечера! Пишите код!