В последние несколько месяцев занимался довольно новым для себя делом - читал лекции по курсу "Оптимизирующие компиляторы". Раньше мне не приходилось читать лекции (ну или почти не приходилось), да и предмет не самый распространённый. В общем о том что получилось, что хочется дополнить и исправить расскажу ниже.
Сам по себе курс длится два семестра, я читаю только первый. В нём предполагается рассказать в целом про оптимизирующие компиляторы и сами оптимизации. Курс был составлен на основе моих конспектов этого курса, прочитанного в МФТИ в 2013 году.
Теперь про содержимое самого курса. Сейчас он состоит из 11 лекций:
Ещё есть масса тем, про которые или не рассказано ничего, или сказано очень мало:
Сам по себе курс длится два семестра, я читаю только первый. В нём предполагается рассказать в целом про оптимизирующие компиляторы и сами оптимизации. Курс был составлен на основе моих конспектов этого курса, прочитанного в МФТИ в 2013 году.
Теперь про содержимое самого курса. Сейчас он состоит из 11 лекций:
- Введение в оптимизирующие компиляторы
- Введение в теорию языков и автоматов. Лексический анализ.
- Введение в теорию языков и автоматов. Синтаксический анализ.
- Алгоритмы на графах, используемые в компиляторах
- Структуры данных в оптимизирующих компиляторах
- Оптимизации управления
- Потоковые оптимизации
- Цикловые оптимизации
- Цикловые оптимизации (часть 2). Оптимизации памяти.
- Анализ указателей
- Планирование кода. Межпроцедурные оптимизации.
Я хочу дорабатывать данный курс. Пока мне видятся не лучшими решениями следующие вещи:
- Наличие второй и третьей лекции. Теорию автоматов нужно изучать отдельно, а информацию по фронтенду можно слить в одну лекцию. Но не думаю что это подойдёт для кафедры, на которой читается курс - отдельно теории автоматов у них нет.
- В девятой лекции идёт остаток восьмой про циклы и ещё треть лекции про оптимизации памяти. По идее про оптимизации памяти нужна отдельная лекция, но у меня по данной теме очень мало информации.
- Одиннадцатая лекция тоже содержит две разные темы, их неплохо бы читать отдельно.
Ещё есть масса тем, про которые или не рассказано ничего, или сказано очень мало:
- ничего нет про распараллелвание
- почти ничего нет про режим -fwhole/-flto
- мало про профилирование
- ничего нет про векторизацию
- почти ничего про межпроцедурные анализы
- ничего про оптимизации C++
- ничего про средства отладки/разработки/workflow
Здравствуйте, а поясните пожалуйста про Эль-76 в советских эльбрусах - это был компилируемый язык в байткод как Java или как скриптовый язык как Lisp/JS?
ОтветитьУдалитьИ как он так поддерживался машиной что на нем писали и программы и операционную систему, а ассемблеры вообще отсутствовали? Мне известно про всякие Java/lisp машины, но в моем представлении они являли собой - ну вот как GPU и OpenCL сейчас, но эльбрус то ведь вполне себе общезадачным был, на нем вроде даже и алгол работал.
Современный эльбрус тоже ведь все это поддерживает (всякие указатели на типы) которые для поддержки высокоуровневых языков и внедрялись, да и потом Эльбрус-3 для тех же военных создавался, которые эксплуатировали Эльбрус 1 и 2, он просто не всего того же не поддерживать.
Возможно ли на современном так же как работали Эльбрус-2 и Эль-76, организовать Эльбрус + ECMA Script 6 например?
Извиняюсь за глупые вопросы если что (я фронтенд разработчик клиентских Web приложений), просто очень давно этот вопрос волнует.
Давайте про Эль-76 и Эльбрус-2 я отвечу позже, т.к. про него особо ничего не знаю, и у меня уйдёт некоторое время на исследование, а про современный Эльбрус можно вот что сказать.
Удалить> Современный эльбрус тоже ведь все это поддерживает (всякие указатели на типы) которые для поддержки высокоуровневых языков и внедрялись
Я не очень понял что Вы имеете ввиду. Если Вы про защищённый режим, то там действительно есть теги, содержащие информацию о типах, но они служат не для поддержки высокоуровневых языков, а для контроля доступа к данным и используются для сборки обычных C/C++ программ.
> Возможно ли на современном так же как работали Эльбрус-2 и Эль-76, организовать Эльбрус + ECMA Script 6 например?
Если это и возможно технически (в чём я не уверен), то это совершенно ни к чему. Сейчас Вы просто скомпилируете движок языка, написанный на Си, и он будет работать. Если движок написан хорошо, возможно он даже тормозить не будет.
Вот чего нашел:
Удалитьhttp://www.electriz.ru/postroenie-effekt-mnogoproc-sistem/perspektivnye-modeli-mnogoprocessornyh-evm-1.html
http://www.electriz.ru/postroenie-effekt-mnogoproc-sistem/perspektivnye-modeli-mnogoprocessornyh-evm-2.html
http://www.electriz.ru/postroenie-effekt-mnogoproc-sistem/perspektivnye-modeli-mnogoprocessornyh-evm-3.html (и так статей 6 где то, )
> Рассматриваемая схема предполагает проведение разработки, ориентированной на языки высокого уровня, с использованием накопленного опыта создания системы «Эльбрус», проведение с самого начала значительных работ по оптимизирующему транслятору так, чтобы алгоритм, изложенный на одном из существующих языков высокого уровня, включая ЭЛЬ-76, после трансляции давал высокоэффективные программы фактически на уровне микропрограмм.
> > Схема информационной системы будущих моделей «Эльбрус»
> В этой схеме отсутствует уровень системы команд, он заменен уровнем микрокоманд.
и:
> Как и предыдущие модели, «Эльбрус-3» основан на теговой архитектуре, позволяющей последовательно проводить динамическую типизацию данных, а также обеспечивающей высокий уровень программирования и исключение ассемблера.
Я вообще к чему это все -
на дворе 2015 год а в интел с пафосом рассказывают как эффективно программировать используя регистры AVX. Диды в 70х уже с одними объектами работали а они все свой потешный SIMD наяривают.
Мне думается будущее Эльбруса как раз вот в этой иной (хорошо забытой - старой) философии, нету системы комманд нету ассемблера нету регистров есть высокоуровневые языки легко транслируемые в микрооперации. И пусть он не такой навороченный как интеловские кочегарки, пусть медленней, пусть на него не будет линукса и квейка, это даже плюс что их не будет, пусть у него будет своя платформа в которой у него не будет конкурентов.
Реальность такова, что никому не нужна уникальная тормозная платформа без какого-либо ПО. Единственный возможный путь развития - обеспечивать максимальную возможность для портирования существующего ПО. Тегированная архитектура представляет определённый интерес, но только если на неё можно наложить реальное ПО без особой потери производительности.
Удалить