Рубрика «Компиляторы» - 55

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

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

Четвертая версия языка оказалось удачной: я написал факториал, затем генерацию последовательности Фибоначи и дюжину простых примерчиков аля “сумма чисел от 0 до 99”. Язык получился что надо: необычный, крайне эзотерический, с простой и понятной идеей. Главное — язык может решить любую (ну или почти любую) задачу которую можно выразить в виде вычислимой функции.

Читать полностью »

image

Этот пост снова посвящается цикловым оптимизациям. Почему вообще речь зашла о цикловых перестановочных оптимизациях? Дело в том, что это одна из самых эффективных частей оптимизирующего компилятора. В число цикловых перестановочных оптимизаций входит как автовекторизация так и автопараллелизация. У этих оптимизаций существует своя специфика, но в целом у всех цикловых оптимизаций общие проблемы и общие методы их решения.
Часто приходится слышать мнение, что компилятор во многих случаях «тупит». Мне хочется здесь побыть адвокатом компилятора, чтобы показать, что жизнь компилятора не так уж легка, возможно вызвать легкую долю сочувствия к его нелегкой доле и показать, какие существуют объективные трудности при обработке программы и почему во многих случаях компилятор совершенно обоснованно не может сделать ту или иную оптимизацию, которая кажется очевидной программисту. Ну и заодно я хочу продемонстрировать некоторые возможности помочь компилятору в его работе. Понятно, что иногда существуют и субъективные факторы, в лице разработчиков, которые по како-либо причине не реализовали ту или иную функциональность внутри компилятора.

Читать полностью »

Балансируя между точностью и производительностью
Есть несколько важных аспектов, которые нужно обязательно учитывать при создании приложения, производящего какие-либо вычисления, а точнее — операции с числами с плавающей точкой. Что мы ждём и планируем получить от таких приложений (в большинстве случаев, научных)? В первую очередь, нас интересует точность вычислений – полученный результат должен быть наиболее близок к «правильному». Другая сторона медали – стабильность результатов и портируемость приложения. Нам важно иметь возможность получать одинаковый, неизменно повторяющийся от запуска к запуску результат, причём на разных машинах/архитектурах. Ну и последний, но не менее значимый пункт – производительность. Насколько быстро при всём этом будет выполняться наше приложение, и когда мы получим результаты наших вычислений?

В компиляторе компании Intel есть набор опций, отвечающих за контроль оптимизаций вычислений над числами с плавающей точкой. Рассмотрим преинтереснейший ключик –fp-model, который, судя по описанию в документации, управляет семантикой вычислений над числами с плавающей точкой. Кстати, стоит отметить, что похожие ключи есть и в других компиляторах, не только Интеловском, об этом мы тоже поговорим. По сути, с помощью данного ключика мы и сможем контролировать баланс между производительностью и точностью вычислений. Возможные значения, которые могут быть указаны в опции –fp-model: precise, fast[=1|2], strict, source, [no-]except (Linux*) or except[-] (Windows*). Давайте разберёмся, что они дают при компиляции нашего кода.
Читать полностью »

image

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

Читать полностью »

      Распространено мнение, что GCC отстает по производительности от других компиляторов. В этой статье мы постараемся разобраться, какие базовые оптимизации GCC компилятора стоит применить для достижения приемлемой производительности.

Читать полностью »

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

Продолжаю разговор об оптимизации приложений, начатый здесь в посте «Существует ли простая оценка качества оптимизации приложения?».

Про процессоры можно говорить много и подробно и, наверняка, среди читателей Хабра есть масса людей спопобных на такие разговоры. Но моя точка зрения на процессор сугубо прагматичная. Поскольку меня интересует производительность приложения, через призму производительности процессора, то мне достаточно понимания базовых принципов работы вычислительного ядра. А также методов, которые существуют, чтобы на эти базовые принципы воздействовать. Буду я ориентироваться на архитектуру Intel64. Это вызвано тем, что в нашей команде анализа производительности мы занимаемся анализом работы оптимизирующего компилятора Intel, в основном, именно для этой архитектуры. На рынке вычислительных систем для высокопроизводительных вычислений эта и совместимые архитектуры занимают львинную долю, поэтому большинство проблем производительности имеет довольно общую природу. Давайте я коротко перечислю те основные проблемы и возможности, которые определяют производительность ядра и вычислительной системы и предложу короткий список различных оптимизаций, призванных влиять на эти проблемы.

Читать полностью »

image

Тише едешь дальше будешь...? Оценка производительности.

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

Читать полностью »

Меня очень заинтересовала статья Самая короткая запись асинхронных вызовов в tornado или патчим байткод в декораторе, не столько с практической точки зрения, сколько с точки зрения реализации.
Всё-таки модификация байткода в рантайме это слишком опасная и ненадежная операция. И уж наверняка не поддерживаемая альтернативными интерпретаторами Python.

Попробуем исправить этот недостаток способом, который для этого предназначен куда больше и который применяется для схожих целей во многих других языках (я точно встречал в Lisp или Erlang). Этот способ — модификация Абстрактного синтаксического дерева (AST) программы.
Читать полностью »

Как я подружил Unity3D и F#
В последнее время я стал все больше и больше интересоваться функциональным программированием, и при выборе языка предо мною пал выбор среди двух очень понравившихся мне языков — Haskell и F#.
В F# меня соблазнило то, что его можно компилировать в MSIL сборки, что обеспечивает возможность использования библиотек классов F# в других языках Microsoft .Net, а также то, что он и сам может их использовать. Ко всему прочему, я ещё и начинающий разработчик Unity3D, и мне в голову пришла мысль: если компилируется в MSIL, то может можно использовать F# скрипты в Unity? Гугление дало ответ: по-человечески нельзя. Можно создать библиотеку классов, поставить в проекте ссылки на библиотеку UnityEngine.dll, компилировать и импортировать как ассет, после чего добавлять компоненты Mono-behaviour напрямую из библиотеки, но это не слишком удобно, согласитесь. Однако, пройдя гугл, Reflection и справку по Unity, мне все таки удалось приблизить(но не повторить в точности) работу с F# скриптами внутри редактора к тому виду, в котором производится работа со скриптами на встроенных языках. Подробности — под хабракатом.
Читать полностью »

Копировать элементы из одного контейнера в другой? Нет ничего проще, универсальный алгоритм помещается в 5 строк:

template<class InputIterator, class OutputIterator>
OutputIterator copy(InputIterator first, InputIterator last, OutputIterator result) {
    while(first != last) *result++ = *first++;
    return result;
}

Возможно вы узнали реализацию std::copy с cplusplus.com. Почему же реализация std::copy из GNU STL занимает 139 строк? Давайте разберемся.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js