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

Недавно очередной раз отработал со студентам 2-го курса 2-семестровую дисциплину «Алгоритмические языки». Обзорно рассмотрели несколько дюжин языков программирования. Один из студентов, Вадим Шукалюк, захотел получше с ними познакомиться, получить более четкое представление о каждом из них. Посоветовал ему провести небольшое исследование. Чем и увлёк. Предлагаю свой отчёт по проделанной за несколько месяцев вместе с ним работе.

У каждого языка программирования есть свои достоинства и недостатки. Одна из важнейших характеристик транслятора с любого языка — это скорость исполнения программ. Очень трудно или даже невозможно получить точную оценку такой скорости исполнения. Ресурс http://benchmarksgame.alioth.debian.org/ предлагает игровую форму для проверки такой скорости на разных задачах. Но число языков, представленных на этом ресурсе, довольно невелико. Предельную ёмкость стека, критическую величину для рекурсивных вычислений проверить проще, но она может меняться в разных версиях транслятора и быть зависимой от системных настроек.

Тестировались следующие трансляторы: си (gcc, clang, icc), ассемблер (x86, x86-64), ява (OpenJDK), паскаль (fpc), яваскрипт (Google Chrome, Mozilla Firefox), лисп (sbcl, clisp), эрланг, хаскель (ghc, hugs), дино[1], аук (gawk, mawk, busybox), луа, рубин, бейсик (gambas, libre office), питон-2, пи-эйч-пи, постскрипт (gs), пролог (swipl, gprolog), перл, метапост, Т_EХ, тикль, бэш. Исследовались как собственно скорость исполнения нескольких небольших, но трудоёмких алгоритмов, так и:

• качество оптимизации некоторых трансляторов;
• особенности при работе с процессорами Intel и AMD;
• предельное число рекурсивных вызовов (ёмкость стека).

Прочитав статью «Вычислите длину окружности», которая, в общем-то, крайне позабавила меня своим стилем, и узнав для себя кое-что новое, я стал несколько сомневаться в достаточной подробности предложенной информации. Всё-таки компиляторов довольно много, систем тоже немало, а в статье как-то навеяно Windows и Visual Studio (на правах ИМХО).

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

Свёрточная нейронная сеть (англ. convolutional neural network, CNN) — специальная архитектура искусственных нейронных сетей, предложенная Яном Лекуном и нацеленная на эффективное распознавание изображений, входит в состав технологий глубокого обучения (англ. deep leaning). Эта технология построена по аналогии с принципами работы зрительной коры головного мозга, в которой были открыты так называемые простые клетки, реагирующие на прямые линии под разными углами, и сложные клетки, реакция которых связана с активацией определённого набора простых клеток. Таким образом, идея сверточных нейронных сетей заключается в чередовании сверточных слоев (англ. convolution layers) и субдискретизирующих слоев (англ. subsampling layers, слоёв подвыборки).[6]


Рис 1. Архитектура сверточной нейронной сети

Ключевым моментом в понимании сверточных нейронных сетей является понятие так называемых «разделяемых» весов, т.е. часть нейронов некоторого рассматриваемого слоя нейронной сети может использовать одни и те же весовые коэффициенты. Нейроны, использующие одни и те же веса, объединяются в карты признаков (feature maps), а каждый нейрон карты признаков связан с частью нейронов предыдущего слоя. При вычислении сети получается, что каждый нейрон выполняет свертку (операцию конволюции) некоторой области предыдущего слоя (определяемой множеством нейронов, связанных с данным нейроном). Слои нейронной сети, построенные описанным образом, называются сверточными слоями. Помимо, сверточных слоев в сверточной нейронной сети могут быть слои субдискретизации (выполняющие функции уменьшения размерности пространства карт признаков) и полносвязные слои (выходной слой, как правило, всегда полносвязный). Все три вида слоев могут чередоваться в произвольном порядке, что позволяет составлять карты признаков из карт признаков, а это на практике означает способность распознавания сложных иерархий признаков [3].

Что же именно влияет на качество распознавания образов при обучении сверточных нейронных сетей? Озадачившись данным вопросом, наткнулись на статью Мэттью Зайлера (Matthew Zeiler).

В комментариях к прошлому посту был поднят весьма важный вопрос – а будет ли вообще выигрыш в производительности от выгрузки вычислений на интегрированную графику, по сравнению с выполнением только на CPU? Конечно, он будет, но нужно соблюдать определенные правила программирования для эффективных вычислений на GFX+CPU.
В подтверждение моих слов, сразу представлю график ускорения, получаемого при выполнении вычислений на интегрированной графике, для различных алгоритмов и с разной долей вовлеченности CPU. На КДПВ мы видим, что выигрыш более чем весомый.

Компилятор Intel C++ предоставляет много возможностей для оптимизации приложений под самые различные задачи, в том числе для мобильных устройств. В этой статье мы затронем два аспекта оптимизации: во-первых, поговорим об использовании выполняемого модуля Intel Cilk Plus в Android для реализации многопоточности приложений, во-вторых, коснемся темы использования Profile-guided Optimization (PGO) для повышения производительности приложений в ОС Android. Ссылки для более глубокого изучения этих тем даны в конце статьи.

«Пожалуйста, напишите на C++ функцию, которая получает диаметр круга как float и возвращает длину окружности как float».

Звучит как задание на первой неделе курса по C++. Но это только на первый взгляд. Сложности возникают уже на первых этапах решения задачи. Предлагаю рассмотреть несколько подходов.

Студент: Как вам такой вариант?

#include <math.h>
float CalcCircumference1(float d)
{
    return d * M_PI;
}

Преподаватель: Да, этот код может нормально откомпилироваться. А может и нет.

Продолжая тему JIT-компиляции .NET'a, сегодня мы рассмотрим диспетчеризацию методов у интерфейсов, generics (как классов, так и отдельных методов вместе с реальными сигнатурами); производить отладку релизных сборок с оптимизациями; разберемся с истинным предназначением типа System.__Canon (это не то, что Вы подумали).

Существуют устройства Android на процессорах с архитектурами наборов инструкций (ISA) ARM или x86. Различные архитектуры наборов инструкций не имеют двоичной совместимости, поэтому приложение, содержащее нативный код, должно содержать нативные библиотеки для каждой архитектуры. Одним из механизмов распространения таких приложений являются так называемые «толстые» пакеты приложений Android («толстые» APK).

В этой статье содержатся пошаговые инструкции по созданию такого «толстого» пакета APK, включающего независимые от архитектуры файлы для виртуальной машины Dalvik (Dalvik, 2013), а также библиотеки для разных архитектур. В статье описывается сборка нативной библиотеки приложения x86 с помощью Intel Integrated Native Developer Experience (INDE).

Уже год в свободное от работы время я пилю что-то вроде смеси Maven и Spring для С++. Важной её частью является самописная система умных указателей. Зачем мне всё это — отдельная тема. В данной статье я хочу коротко рассказать о том, как одна, казалось бы, полезная фича С++ заставила меня усомниться в здравом смысле Стандарта.

Редактировано:
Приношу свои извинения хабрасообществу и Стандарту. Буквально на следующий день после отправки статьи осознал грубую ошибку в своих размышлениях. Лучше читать сразу конец статьи… и, да, к copy elision, выходит, статья относиться лишь косвенно.

Продолжаем начатый разговор о Intel® Graphics Technology, а именно о том, что у нас есть в распоряжении с точки зрения написания кода: прагмы offload и offload_attribute для оффлоадинга, атрибуты target(gfx) и target(gfx_kernel), макросы __GFX__ и __INTEL_OFFLOAD, интринсики и набор API функций для асинхронного оффлоада. Это всё, что нужно нам для счастья. Чуть было не забыл: конечно, нам нужен компилятор от Intel и магическая опция /Qoffload.

Но обо всё по порядку. Одна из основных идей – это относительно легкая модификация существующего кода, выполняемого на CPU для его выполнения на интегрированной в процессор графике.

Около шестнадцати лет назад вышла первая версия Hotspot – реализация JVM, впоследствии ставшая стандартной виртуальной машиной, поставляемой в комплекте JRE от Sun.

Основным отличием этой реализации стал JIT-компилятор, благодаря которому заявления про медленную Джаву во-многих случаях стали совсем несостоятельными.
Сейчас почти все интерпретируемые платформы, такие как CLR, Python, Ruby, Perl, и даже замечательный язык программирования R, обзавелись своими реализациями JIT-трансляторов.

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

Таким образом вам может быть интересно под катом, если:

• Вы принципиально не понимаете, что такое JIT-компилятор, или у вас есть легкое непонимание, чем такой подход существенно лучше интерпретации.
• Вы хотели бы написать простой JIT для своего интерпретируемого языка.
• Вы преподаете курс «Языки программирования и компиляторы», и не против сделать практическое задание для студентов еще интересней.
• Вам интересно, как нарисована эта картинка.

В посте про «новшества» Parallel Studio XE 2015 я обещал написать про интересную технологию от Intel — Graphics Technology. Собственно, это я и собираюсь сделать сейчас. Суть Intel Graphics Technology заключается в использовании интегрированного в процессор графического ядра для выполнения вычислений на нем. Это оффлоад (offload) на графику, что, естественно, дает прирост производительности. Неужели интегрированная графика настолько мощна, что этот прирост будет действительно велик?
Давайте посмотрим на семейство новых графических ядер GT1, GT2 и GT3/GT3e, интегрированных в процессоры 4-го поколения Intel Core.

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

Данная статья посвящена оптимизациям компилятора Visual C++. Я собираюсь обсудить наиболее важные техники оптимизаций и решения, которые приходится применить компилятору, чтобы правильно их применить. Моя цель не в том, чтобы рассказать вам как вручную оптимизировать код, а в том, чтобы показать, почему стоит доверять компилятору оптимизировать ваш код самостоятельно.

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

На днях я получил баг репорт, что мой код неправильно работает, если его скомпилировать при помощи pgcpp.

Начав разбираться, я нашел место, где происходит ошибка. Оказалось, что если код компилируется с O2 или O3 оптимизацией, то std::sort может начать дублировать часть вектора и заменять этими дубликатами другие части.

Вот простой C++ код, который поможет воссоздать это ужасное поведение (обратите внимание на число 3193 в выводе):

Традиционно компиляторы реализуют вызовы виртуальных функций через двойную косвенную адресацию — если класс содержит хотя бы одну виртуальную функцию, то в начале каждого объекта этого класса хранится адрес таблицы виртуальных функций. Если компилятор не знает конкретный тип объекта, на который указывает указатель, то для вызова виртуальной функции нужно сначала взять указатель на объект, прочитать адрес начала таблицы, затем по номеру метода прочитать адрес, где хранится реализация функции, затем вызвать функцию.

Процесс поиска конкретной функции по указателю на объект называется поздним связыванием и выполняется во время работы программы. Позднее связывание не только увеличивает накладные расходы на вызов, но и препятствует оптимизации кода компилятором. Из-за этого сами виртуальные функции принято считать замедляющими работу.

В тексте выше ключевое слово «если». Что, если компилятор знает, какую функцию на самом деле надо вызывать?

Мы все сталкивались с проблемами, возникающими при неправильной работе с указателями: выход за пределы массива и переполнение буфера, случайная запись в неизвестный кусок памяти, с последующим чтением этого «мусора» в другом месте, а в некоторых отдельных случаях и просто падение всей системы. Иногда это просто «дичь», господа! И нужно уметь обходится с этой «дичью» правильно – вовремя находить и исправлять подобные ошибки и проблемы. Именно этим занялись в «плюсовом» компиляторе Intel ещё несколько релизов тому назад. Кроме того, многие идеи пошли дальше и будут реализованы в «железе» через технологию Intel Memory Protection Extensions. Давайте-ка посмотрим, как всё это работает в компиляторе.

Данный пост продолжает серию из трех статей об оптимизациях для x86 в GCC 5.0. В предыдущей статье речь шла о векторизации. Напомню, что GCC 5.0 находится сейчас в фазе stage3, то есть внедрение новых оптимизаций уже фактически заверешено и уровень производительности за редким исключением останется прежним и в продуктовом релизе. Сегодня речь пойдет об ускорениях позиционно-независимого кода или position independent code (PIC) в 32-битном режиме для x86.

Здравствуйте. Хочу представить свой проект – компилятор .NET/Mono в Java. Целью проекта является создание компилятора, и набора стандартных библиотек позволяющих переносить написанные приложения и библиотеки на платформу Java, версии 1.6 и выше. Из аналогичных проектов мне известен лишь проект dot42. Но он заточен под Android и имеет собственную стандартную библиотеку не совсем совместимую с .NET/Mono.

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

Исходные коды на github.com: https://github.com/zebraxxl/CIL2Java

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

Язык Julia не поддерживает такую технику программирования, хорошо зарекомендовавшую себя в языках Haskell, Prolog, Erlang, Scala, Mathematica, как pattern matching. Но разрешает писать макросы, которые позволяют исправить этот фатальный недостаток. Выглядит это примерно так:

julia> immutable X a end

julia> immutable Y a ; b end

julia> @case(Y(X(9),2),  Y(4,3)-> 55, Y(X(k),2)->1+k)
10

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