| Дата последнего изменения : | 19.10.2009 07:40 |
Рейтинг |
|
В статье описывается работа над проектом, целью которого было создание инструмента для поиска потенциальных возможностей проведения кэш-оптимизаций, состоящего из трех компонент: инструментатора бинарного кода для сбора статистики доступа к RAM, статистического анализатора данных и графического интерфейса для представления полученных результатов.
Г. Маркес был прав, говоря, что самое лучшее в нашей жизни происходит неожиданно. И случайно замеченное мной на просторах Интернета приглашение в Летнюю Школу Intel - яркий тому пример. Сегодня, находясь в Иркутске и выбрав тему диплома непосредственно связанную с тематикой моего проекта в Летней Школе, я понимаю, что один месяц, проведенный на стажировке в Новосибирском Академгородке, оказал достаточно сильное влияние на мою дальнейшую деятельность. В этой статье мне бы хотелось познакомить вас с идеей проекта, рассказать о уже проделанной работе, а также о перспективах развития данной темы.
«Создание инструмента для поиска потенциальных возможностей проведения кэш-оптимизаций» - таково название проекта, над которым кроме меня работал Антон Астафьев, а курировал проект ментор от Intel Дмитрий Буданов.
В данном случае нам нужно было рассмотреть возможность повышения производительности программы посредством увеличения эффективности доступа к памяти, зависящей от структуры кода. Реализация проекта состояла из реализации трех его компонент, а именно: инструментатора бинарного кода для сбора статистики доступа к RAM, статистического анализатора данных, графического интерфейса для представления полученных данных. В общем виде суть проекта можно представить следующей схемой:
Рис. 1. Суть проекта
Говоря о структуре кода, необходимо сказать о видах существующих цикловых оптимизаций, т.к. именно циклы зачастую оказываются «узкими местами» программы и, изменяя их структуру, в большинстве случаев, можно достичь более эффективной работы программы с памятью. Ниже приведены наиболее известные цикловые оптимизации:
Таким образом, выявив с помощью статистического анализатора и представив визуально наиболее «проблемные» участки программного кода, можно предположить, что эти участки следует рассмотреть на предмет применения одной или ряда цикловых оптимизаций. Не следует забывать, что результаты, полученные при компиляции программы без оптимизаций компилятора и с ними, будут отличаться друг от друга, что в свою очередь позволяет использовать инструмент при тестировании компиляторов.
Для реализации первой компоненты нам понадобилась утилита Pin. Pin - Dynamic Binary Instrumentation Tool, утилита, которая внедряется в анализируемый процесс непосредственно перед стартом и позволяет отслеживать выполнение практически любых инструкций, предоставляет API доступа к содержимому регистров, контексту выполнения программы, символьной и отладочной информации. В нашем случае, мы использовали API, позволяющие инструментировать инструкции доступа к памяти.
Таким образом, в БД записывался адрес инструкции программы, происходящей в каждый n-ый момент времени, адрес ячейки памяти, к которой она обращалась и тип доступа. Т.к. при выполнении даже самой простой программы количество происходящих событий измеряется тысячами, то в качестве параметра n задавался шаг, с которым считывалась необходимая нам информация.
Что касается БД, то мы использовали SQLite - свободно распространяемую реляционную базу данных, не использующую парадигму «клиент-сервер», а основанную на встраиваемом движке. SQLite хранит всю базу данных (включая определения, таблицы, индексы и данные) в единственном стандартном файле на том компьютере, на котором исполняется программа.
Наиболее сложным и самым важным оказалось создание статистического анализатора полученных данных, функция которого заключалась в выявлении областей (кластеров) с наибольшей плотностью обращения инструкций к сегменту памяти. В итоге нами были предложены следующие реализации:
Реализация №1: Определение границ кластеров по каждому измерению с помощью фильтра LoG, фильтрация по плотности наполнения областей.
Фильтр LoG (Laplacian of Gaussian) - сглаживание ряда данных по методу Гаусса, взятие второй производной и определение границ кластера по смене её знака. Чтобы применить фильтр формируются временные таблицы следующей структуры: адрес инструкции, число её повторений (для выявления диапазонов адресов инструкций) и адрес ячейки памяти, число обращений к этой ячейки (для выявления диапазонов адресов ячеек памяти).
Реализация №2: Сортировка собранной статистики пространственным деревом поиска (окто-деревом), фильтрация по плотности и восходящее объединение кластеров.
Кластеризацию на окто-дереве можно описать следующими характеристиками:
Результат обеих реализаций сведен к единому формату - списку кластеров. Кластер представляет собой пересечене диапазонов времени, адресов инструкций и адресов данных.
Надо сказать, что вопрос наиболее эффективного метода обработки данной статистики еще не закрыт и является основным направлением нашего дальнейшего исследования в этом проекте. В рамках Летней Школы мы представили результаты, полученные методами, описанными выше. Графический интерфейс был разработан на языке Java с помощью библиотек Swing и JfreeChart, в среде NetBeans 6.5.
Думаю, было бы странно, если при работе над проектом не возникло бы ни одного затруднения. В этом проекте мне пришлось впервые столкнуться с достаточно большими объемами данных. Индексация и обработка баз данных занимала довольно много времени на ПК средней производительности. Благодаря тому, что у нас был доступ к использованию кластера, нам удалось в разы сократить время работы инструмента. Кроме того, из-за большого объема данных (миллионы записей) терялась точность выявления проблемных областей. Объем данных в свою очередь был связан с выбором шага инструментации. В итоге было принято решение, менять шаг инструментации в соответствии с размером исследуемого кода.
Исследовав предметную область, выбрав средства реализации и устранив возникшие проблемы, мы перешли к реализации задуманного. Благодаря организованной работе команды (Антон занимался реализацией первого компонента и метода, основанного на окто-деревьях, а я реализацией третьего компонента и метода, использующего фильтр LoG) и грамотному управлению проектом со стороны нашего куратора, был создан инструмент, архитектура которого представлена на рис.2.
Рис. 2. Архитектура инструмента
На сегодня, так скажем, в первой версии программы, инструментатор бинарного кода отделен от статистического анализатора и графического интерфейса. То есть инструмент состоит из двух частей. На вход первой, консольной части, подается исполняемый бинарный код, на выходе формируется файл базы данных, содержащий необходимые для статистического анализатора данные и используемый во второй части. Во второй части сначала выбирается файл базы данных, затем метод кластеризации. Результаты формируются в виде таблицы кластеров со значимой плотностью, диаграмм диапазонов адресов памяти и адресов инструкций и графика пересечений этих диапазонов.
Ниже вы видите график пересечений диапазонов и общий вид графического интерфейса.
Рис. 3. График пересечений диапазонов
На графике по оси Х указаны адреса ячеек памяти, а по оси Y адреса инструкций. Синим цветом показано, что два диапазона адресов инструкций обращаются к одному и тому же диапазону адресов памяти. Данное пересечение указывает на потенциальную «проблемную» область.
К сожалению, нам не хватило времени протестировать инструмент на реальных приложениях, на скриншоте представлены результаты, полученные при работе с приложениями тестового набора Polyhedron.
Рис. 4. Общий вид графического интерфейса
Я не случайно написала выше именно о первой версии программы. В рамках Летней Школы был заложен хороший фундамент для дальнейшего исследования данной предметной области и работы над проектом, поэтому останавливаться на достигнутом мы не собираемся. Развивать проект предполагается в следующих направлениях:
Как видите, впереди много интересной работы. Возможно, пройдет время, и на сайте сообщества появится статья о второй версии инструмента, а пока я прощаюсь с вами. Благодарю за внимание.
Жданова Наталия Юрьевна, студентка Байкальского Государственного Университета Экономики и Права ( факультет Экономической Кибернетики), проходила стажировку в рамках Летней Школы Intel в Новосибирске. Для меня стажировка в Летней Школе стала самым ярким событием этого лета. Интенсивная работа, интереснейшие лекции и тренинги, общение с единомышленниками, экскурсии - четыре сумасшедших недели за которые я расширила свой кругозор, нашла новых друзей, получила опыт работы в команде, изменила взгляд на науку и многое другое. Если бы стажировка длилась всё лето, я бы не задумываясь провела его с Intel, потому что как оказалось, лето и Intel очень даже совместимы!
| 28.09.2009 08:37
zhdanova
|
Поговорить – всегда пожалуйста! Отвечаю на Ваши вопросы: 2) да, Антон Астафьев тоже проходил стажировку в рамках Летней Школы. 3) Что касается способов выявления кластеров: нет, они не были нам предложены изначально. Поиск и выбор методов – это, так скажем, исследовательская часть нашего проекта. 4) Из графика пересечения диапазонов убраны «кубики» с небольшой плотностью, т.к. в данном случае они нас не интересуют, т.е. на самом деле кластеров, конечно, больше. Про первый столбик я ничего не написала, потому что наша первоначальная цель – показать места пересечения именно разных куч при обращении к одному и тому же куску памяти. |
| 02.10.2009 15:08
mt2
| На мой взгляд, работа очень интересная и заслуживает высокой оценки. Особо следует отметить старательность автора как в проведении работы, так и в неформальном ("не для галочки") изложении результатов. А вот руководитель, на мой взгляд, недостаточно внимательно подошел к данной статье и пропустил досадные промахи в ее оформлении, каковые промахи начинающий автор увидеть не может. Например, "График пересечений диапазонов": рассмотреть на нем что-либо очень трудно, можно было оцифровать оси пореже, а шрифт для цифр взять крупнее? И сам рисунок крупнее дать? Раздел "Используемая литература и ссылки на ресурсы" - 2 первых номера это не web-ссылки и не печатные издания (т.к. не указано ни издательство, ни место, ни год) и даже не рукописи (этого тоже не отмечено). Такие ссылки обычно не приводят. И, наконец, стиль: с одной стороны, стиль под серьезную статью (ну хотя бы под курсовую/дипломную работу), иногда с тяжеловесными канцелярскими оборотами "Получить потенциальную возможность сокращения времени выполнения кода за счет изменения его структуры", с другой - чрезмерный "оживляж" типа "Думаю, было бы странно, если при работе над проектом не возникло бы ни одного затруднения." И то, и другое затрудняет чтение, и более внимательное отношение опытного руководителя позволяет в таких случаях найти золотую середину, "не наступая на горло авторской песне", но и не усаживаясь на 2 стула сразу. Очевидно, однако, что отмеченные недостатки оформления не снижают значения самой работы. С искренними пожеланиями дальнейших успехов! |
| 05.10.2009 02:33
zhdanova
|
Благодарю за пожелания! И отдельное спасибо за критику. Замечания для меня очень важны, т.к. это моя первая подобная работа. Так сказать, дебют) К вопросу о стиле... Дело в том, что в условиях конкурса было написано, чтобы мы не забыли включить в техническую статью рассказ о впечатлениях, полученных на стажировке. Гармонично совместить воспоминания/эмоции с одной стороны и серьезную тему проекта с другой оказалось не так и просто. Буду учиться)) |
| 06.10.2009 05:18
mt2
| У Вас есть очень важное умение: слушать критику и отвечать на критику. И про стиль Вы совершенно правы - действительно непросто включить в техническую статью рассказ о впечатлениях ;) Так что снимаю свое замечание про стиль и переадресую его устроителям конкурса: не стоит требовать впечатлений в технической статье, если хотите впечатлений - пусть конкурсанты отдельно от статьи публикуют выдержки из дневников, лабораторных журналов, избранные места из переписки с друзьями и т.д. ;) |
| 17.10.2009 15:12
Alexei Alexandrov (Intel)
|
Интересная работа. Некоторые замечания: * Картинки мелкие - ничего не видно * Делать 3D интерфейс для такого рода инструментов - пустая трата времени. Надо найти такие методы представления, которые и в двумерной таблице все разумным образом покажут. Никто ваши кубы вращать на экране не будет - это неудобно. * С проверки на реальных приложениях надо начинать. Все остальное потом. |
| 18.10.2009 07:09
alexander.musman
|
Кроме наиболее плотных областей в кубе, вероятно, интерес будут представлять точки с маленьким расстоянием по оси времени (и по оси адреса инструкций) и существенным расстоянием по адресу ячейки памяти (например, обычное умножение матриц за O(n^3), которое немного быстрее, если одну из матриц перед ним транспонировать, чтобы не ходить по столбцам). |
| 19.10.2009 07:44
zhdanova
| Алексей, спасибо за комментарий. С замечаниями согласна. Насчет 3D интерфейса: подразумевалось создание куба для представления общей картины, а двумерные таблицы и графики уже для детализации. |
| 19.10.2009 07:45
zhdanova
| Александр, спасибо за идею! |
| 23.10.2009 04:58
Dmitry Oganezov (Intel)
|
«наиболее сложным и самым важным оказалось создание статистического анализатора полученных данных, функция которого заключалась в выявлении областей (кластеров) с наибольшей плотностью обращения инструкций к сегменту памяти»… «В итоге нами были предложены следующие реализации»... Увы, но как раз обоснования предложенных реализаций я и не увидел. На мой взгляд, эта самая интересная часть вашей исследовательской работы. Именно она и должна быть раскрыта в статье. Утилиты Pin и визуализатор вряд ли стоит рассматривать как нечто новое. А вот увидеть связку между анализатором и кодом приложения хотелось бы – ведь это главное в инструменте оптимизации. А в целом статья понравилась. Понравилась легким языком и хорошим, доступным описанием весьма сложного проекта. |
| 24.10.2009 03:50
zhdanova
| Благодарю за замечание, Дмитрий. Вы правы, нужно было бы подробнее описать реализации стат. анализатора, но тогда статья могла как раз-таки утратить легкость и доступность. Если я буду писать полноценную научную статью на эту тему, то, конечно, анализатору я уделю гораздо больше внимания. |

ksili
4,113
Статусных баллов:
3,613
1) Во-первых спасибо, что рассказали про утилиту Pin. Я про неё не знал.
2) Антон это тоже летний школьник?
3) Способы выявления кластеров (LoG и окто-дерево) были вам предложены или вы сами до них додумались?
4) Что-то график пересечения адресов совсем уж грубый. Про первый столбик тоже можно сказать, что куча инструкций обращаются в один диапазон адресов.