Компиляторы *

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

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

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

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

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

Я не люблю программировать. Мне нужен результат.

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

Но главное — чтоб заработало. И чем раньше — тем лучше.

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

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

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

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

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

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

В последнее время я стал все больше и больше интересоваться функциональным программированием, и при выборе языка предо мною пал выбор среди двух очень понравившихся мне языков — 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 строк? Давайте разберемся.

Многие программисты очень любят обвинять компилятор в различных ошибках. Поговорим немного об этом.

На Github выложен исходный код компилятора Rootbeer, с помощью которого можно почти любой Java-код запустить на графическом процессоре, а также легко разделить Java-программу на фрагменты для CPU/GPU.

Компилятор опубликован под лицензией MIT, он прошёл тщательное тестирование и вполне пригоден для использования. По словам автора, это самый продвинутый транслятор байткода Java на платформу CUDA. Судя по всему, OpenCL тоже поддерживается.

Автор программы — преподаватель Сиракузского университета Фил Пратт-Желига (Phil Pratt-Szeliga).

Недавно на хабре появилась неплохая статья про вычисление N-ного числа фибоначи за O(log N) арифметических операций. Разумный вопрос, всплывший в комментариях, был: «зачем это может пригодиться на практике». Само по себе вычисление N-ого числа фибоначи может и не очень интересно, однако подход с матрицами, использованный в статье, на практике может применяться для гораздо более широкого круга задач.

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

loop 1000000000
  loop 1000000000
    loop 1000000000
      a += 1
      b += a
    end
  end
end
end

Незамедлительно выведет a = 1000000000000000000000000000, b = 500000000000000000000000000500000000000000000000000000, несмотря на то, что если бы программа выполнялась наивно, интерпретатору необходимо было бы выполнить октиллион операций.

Сейчас с уверенностью можно утверждать, что времена самописных C++-парсеров постепенно отходят в прошлое. На сцену медленно, но неумолимо выходит clang — полноценный C++-фронренд и компилятор, предоставляющий своим пользователям богатое API. С помощью этого API можно распарсить исходный текст на C/C++/Objective C, и вытащить из него всю необходимую информацию — от простого лексического значения токенов, до таблицы символов, AST-деревьев и результатов статического анализа кода на предмет всяких разных проблем. В связке с llvm и при сильном на то желании C++ можно использовать в качестве скриптового языка, парся и исполняя C++-программы «на лету». В общем, возможности перед программистами открываются богатые, надо только понять — как ими правильно воспользоваться. А тут, как это не редко случается, и начинается самое интересное.

Уважаемое сообщество, я хочу рассказать вам о языке программирования Gentee. Я уверен, что вы о нем ничего не слышали, но это не новинка. Первая рабочая версия компилятора увидела свет в 2008 году, а в конце 2010 была выпущена последняя на данный момент 3-я версия. Gentee является open source проектом и распространяется под MIT лицензией, то есть без всяких условий и ограничений. Кроме меня над компилятором, библиотеками и всей документацией работал еще один человек. В начале я хочу написать об истории возникновения языка. Начиная с 2000 года я работал над инсталляторами, в которых пользователь мог строить сценарии из определенных команд. То есть, каждая команда из параметров на форме должна была конвертироваться в код на каком-то языке, который можно было бы компилировать в байт-код и создавать исполняемый файл. Начинали с примитивного языка, но в конце концов решили сделать язык широкого применения. Основные требования были следующие: быстрый компилятор, легкая работа с Windows API, маленький размер движка виртуальной машины, лаконичный и понятный синтаксис, возможность использования компилятора и виртуальной машины из любого языка программирования. На языке C был написан компилятор в байт-код и виртуальная машина. Gentee.dll (компилятор и ВМ) занимает всего 112 КБ и может быть включена в любой проект, которому требуется встроенный язык программирования. Программа на Gentee может быть выполнена сразу после компиляции или можно создать исполняемый файл с байт-кодом и вшитой виртуальной машиной.

22 мая состоялся релиз LLVM 3.1, семейства компиляторных инструментов, построенных на модульной основе. Проект активно развивается как альтернатива GCC такими компаниями, как Apple и Google.

Наиболее заметные изменения включают в себя улучшенную поддержку нового стандарта C++'11 Clang'ом (включая лямбды, списки инициализации, константные выражения, пользовательские литералы и атомики); появление AddressSanitizer — инструмента для динамического отлова ошибок работы с памятью; серьёзные улучшения времени компиляции и появление новых фич для ARM архитектуры; заметно улучшенная поддержка архитектуры MIPS (включая MIPS64).


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

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

Тем не менее я решил попробовать создать парсер для HTTP запроса на основе ДКА. Основная задача не просто проверить корректность HTTP запроса, а именно выделить во входной строке элементы соответствующие определенным значениям полей HTTP запроса. Автомат должен генерироваться из BNF правил (разбросанных по) RFC2616. Реализовано все на C#, автомат на выходе тоже на C#. Хотя понятно что когда автомат готов, сгенерировать его на любом языке, в любом виде не проблема.

Сегодня ночью вышел долгожданный GCC 4.7, выпуск которого приурочен к 25-летию проекта.

Долгожданным этот выпуск является прежде всего для программистов C++, так как несет с собой обширную поддержку нового стандарта С++11.

Введение

Добрый день.
В заключительной части про написание собственного генератора LALR-парсеров я бы хотел описать возможные особенности и фичи. Кроме того я опишу чего мне не хватало в существующих решениях и ради чего я начал писать свой велосипед.

Дабы задать контекст, сообщу, что грамматика для анализа — это ECMAScript, так же известный как JavaScript. Конкретная спецификация — ECMA-262, редакция 5.1 от июня 2011 года.

Предисловие

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

В комментариях к прошлой статье несколько человек интересовались моими мотивами в написании своего компилятора компиляторов. К сожалению, они в этой статье не найдут ответов на этот вопрос. Не скрою, изначально я планировал написать статью без особой теории, но с оправданием задач и целей, ради которых я начал писать генератор, да и хотел поделиться нюансами и особенностями реализации. То есть по объему это довольно прилично: несколько экранов. Но затем я решил всё же описать базовую теорию популистским языком, поэтому статья разрослась до трех частей. Таким образом, дабы не ломать логику изложения, я сначала расскажу про LR/SLR/LALR-анализаторы, а завтра опубликую заключительную, и, думаю, самую интересную часть.

До появления gccxml, был только один способ извлечь мета-информацию из Си/С++ кода. Для начала, необходимо было написать парсер, способный справиться с грамматикой языка С++. Это не та задача, которую вы обычно решаете дома за выходные.

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

Для разбора XML данных, полученных от gccxml, пригодится библиотека pygccxml. Это не просто ридер формата gccxml — библиотека предоставляет интерфейсы для изучения собранных метаданных; в частности есть готовые функции, отвечающие на вопросы вроде «совместимы ли типы T₁ и T₂?» или «наследует ли класс C₁ от C₂?». Библиотека написана на языке Python.

В качестве хобби последние несколько месяцев я разрабатываю парсер языка PHP с помощью ANTLR. Сам проект для меня скорее просто Just for fun, но в ходе его реализации у меня, разумеется, возникали сложности. Тут сказывается как особенность языка PHP с полным отсутствием спецификаций, так и ограничения алгоритмов LL(k).

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

Введение, или зачем нужны синтаксические анализаторы

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

Эта часть посвящена базису, общей теории computer science. Возможно, что это даже преподаётся в школах/вузах России. Самая мякота пойдет со второй части.

Итак, зачем же кому-то может понадобиться писать парсер и что вообще это такое? Парсер — это код, который наделяет входящий набор символов семантическим смыслом. То есть, происходит анализ этих символов, и на основе этого анализа программа понимает как интерпретировать эти буквы и цифры. Простой пример — «1+2», после или во время процесса парсинга знак "+" это не просто символ плюса, но обозначение бинарноого оператора сложения, а в "+3" это унарный оператор знака числа. Большинству людей это очевидно, машине — нет.

Парсеры используются всюду — в Word'e для анализа приложений, словоформ, формул, etc; практически на любом сайте при валидации входных данных: email'а, телефонного номера, номера кредитки; конфигурационные файлы; сериализованные данные (например, в xml); во многих играх — скриптовые ролики, скрипты ИИ, консоль. В общем, это неотъемлемая часть computer science.