[Программирование, Совершенный код, Отладка, Процессоры] Чего не хватает для идеального профилирования кода
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Знаете ли вы, как работает такая серьезная программа оценки производительности, как Intel VTune Amplifier? Не в смысле интерфейса с пользователем и разных возможностей, а на какой аппаратной поддержке она основана?Я попытался найти об этом информацию, но как-то разработчики этой программы не делятся с пользователями объяснениями, как именно они получают данные о пользовательской программе. Вероятно, никаких секретных команд и способов там нет. Все основано на сигналах прерываний и установке аппаратных и программных контрольных точек (которые тоже вызывают прерывания). Ну и, конечно, на чтении «телеметрии» самого процессора.Я не рассматриваю здесь интерпретируемые языки типа Питона. Ясно, что интерпретатор и безо всяких сигналов прерываний легко может собирать статистику при выполнении программы. А вот все остальное, кроме случаев вставки в код специальных вызовов, так или иначе, требует прерываний. Ну, или, например, виртуальной машины, которая тоже требует прерываний.При этом близкое к идеальному с точки зрения накладных расходов профилирование кода получается, когда используют метод Монте-Карло, который позволяет оценить распределение нагрузки с точностью до периода таймерного прерывания.Т.е. достаточно поставить обработчик на системный таймер и извлекать из автоматически запоминаемого контекста указатель текущей команды RIP (EIP). Затем, имея адреса подпрограмм, легко определить, какая именно подпрограмма работала в момент прерывания, и статистически учитывать это в профиле выполняемого кода. Поиск подпрограммы по адресу RIP процесс, конечно, тоже не мгновенный и не бесплатный, но его можно отложить, а в реальном времени лишь запоминать в памяти очередное значение RIP.Никакой специальной аппаратной поддержки в данном случае не требуется и для типового кода метод дает хорошие результаты даже для периодичности таймера порядка мс. Но программисты все равно недовольны: «для программ, обрабатывающих тысячи событий в секунду, требуется сильное уменьшение периода, а это и дает большие накладные расходы, и портит результат. Кроме этого, такой метод часто неприменим для профилирования низкоуровневого кода — тех же обработчиков прерываний, процедур планировщика ОС и т.п.»Помнится, давным-давно, в начале 90-х, у меня был настольный компьютер (к сожалению, забыл марку, по-моему, немецкий), у которого на передней панели был спидометр! Я не шучу. На его передней панели был индикатор из светодиодных сегментов для трех цифр. Согласно очень мутному описанию, он показывал число команд в штуках, то ли в среднем за тик, то ли еще за какое-то фиксированное время. В общем, он показывал какое-то число, обычно близкое к 1.00, и чем оно было выше, тем более производительным был в этот момент процессор.По тем временам прекрасная вещь для поиска «узких мест»! И, главное, специально для замеров в программе делать ничего не надо было: поменял очередной раз код, запустил тестовый прогон и смотришь на индикатор. Ну да, в те стародавние времена и тактовые частоты были невысокие, считалось все относительно медленно, и объем ПО был небольшим, да и MS DOS с современной точки зрения, это, вероятно, случай отсутствия ОС. Вполне можно было разглядеть на индикаторе любые незначительные отклонения производительности.С его помощью я, отчасти из спортивного интереса, отчасти из уязвленного самолюбия, пытался ускорить работу транслятора с ассемблера RASM-86. Он выполнял тест за 23.4 секунды, а микрософтовский MASM выполнял этот же тест за 8.3 секунды. С помощью этого волшебного индикатора я быстро нашел все узкие места и неудачные команды (конечно, они оказались в лексическом анализаторе) и добился выполнения теста за 5.6 секунды.И у этого примитивного средства было преимущество, которого, на мой взгляд, и не хватает для идеального профилирования выполняемого кода сегодня – аппаратная поддержка.По-моему, простую аппаратную поддержку профилирования кода несложно добавить в любой современный процессор. Если взять процессоры Intel, то такая поддержка могла бы быть реализована на внутреннем счетчике, подобному счетчику системных тактов, который можно прочитать с помощью инструкции RDTSC. Но в отличие от счетчика, читаемого RDTSC, дополнительный внутренний счетчик должен увеличиваться с каждым тактом не с момента включения процессора, а только при выполнении условий, заданных в программе.Разумеется, никаких новых команд вводить для этого не требуется. Задание условий для гипотетического дополнительного счетчика можно делать и через запись в порт самого процессора командой WRMSR, а чтение значения счетчика – командой чтения из порта процессора RDMSR. Кроме этого, запись в порт должна вызывать и сброс счетчика, чтобы не создавать для этого отдельное действие.В качестве условий вводится два адреса программы – начальный и конечный, а также один из двух способов их использования.Смысл в том, что при задании начального и конечного адресов внутренний счетчик тактов обнуляется и теперь увеличивается на каждом такте только, когда указатель RIP/EIP попадает внутрь заданного диапазона адресов. В другом режиме — счетчик начинает работу, когда RIP/EIP строго совпадает с начальным адресом и заканчивает, когда строго совпадает с конечным адресом. Такая незначительная доработка процессора позволит использовать его для профилирования выполняемого кода без какого либо изменения самого кода анализируемой программы и совершенно прозрачно для нее.В первом режиме я задаю начало и конец своей, может быть небольшой подпрограммы внутри огромного проекта, причем начало — это необязательно именно точка входа в подпрограмму. Затем просто запускаю главную программу, возможно, заканчиваю или останавливаю её прогон, а затем читаю получившийся счетчик — число тактов, которое управление находилось именно в этой подпрограмме, без учета, например, времени работы системных вызовов (так как они наверняка окажутся вне заданного диапазона адресов).Во втором режиме я задаю точку входа в подпрограмму и точку выхода из неё. И получаю счетчик тактов нахождения в подпрограмме уже с учетом всех вложенных вызовов. Только в том случае, если точек выхода несколько, возможно, придется слегка менять код программы, чтобы такое профилирование давало верные результаты.В большинстве же случаев можно не ставить никаких специальных отладочных вызовов, не использовать никаких прерываний и вообще никак не влиять на работу кода. И в результате получать некоторую количественную характеристику производительности выполнения анализируемого участка кода.При попытках улучшения теперь можно сравнивать не все время работы огромной программы, а лишь с такой же предыдущей количественной характеристикой, т.е. становится возможным увидеть изменения производительности в масштабах микро- и наносекунд, не запуская миллионы циклов теста.Таких команд, правда, пока нет. Но, возможно, что-то похожее именно для поддержки профилирования кода со стороны процессора в будущем и появится. А может быть, появится сначала в виртуальных машинах.
===========
Источник:
habr.com
===========
Похожие новости:
- [Программирование, Разработка под Android, Flutter] Flutter ListView и ScrollPhysics: Детальный взгляд (перевод)
- [Программирование, Java, ООП, Функциональное программирование] Java Optional не такой уж очевидный (перевод)
- [Компьютерное железо, Настольные компьютеры, Ноутбуки] XPS 13 9310: эволюционный апгрейд флагманского ультрабука Dell с Tiger Lake внутри
- [Программирование, Анализ и проектирование систем, Хакатоны] Группа «М.Видео-Эльдорадо» приглашает на онлайн-контест для аналитиков
- [Программирование, C++, Алгоритмы, Математика] Пишем свой парсер математических выражений и калькулятор командной строки (перевод)
- [Open source, Совершенный код, C, Разработка под Linux] Finding Typos in the GTK 4 Project by PVS-Studio
- [Программирование, Go, WebAssembly] Запускаем AssemblyScript в Go
- [Программирование, Проектирование и рефакторинг, API, Google API] Проектирование API: почему для представления отношений в API лучше использовать ссылки, а не ключи (перевод)
- [Python, Программирование] Как строить красивые графики на Python с Seaborn (перевод)
- [Системное программирование, FPGA, Программирование микроконтроллеров, Компьютерное железо] Добавляем поддержку Vendor-команд к USB3.0 устройству на базе FX3
Теги для поиска: #_programmirovanie (Программирование), #_sovershennyj_kod (Совершенный код), #_otladka (Отладка), #_protsessory (Процессоры), #_intel, #_profilirovanie (профилирование), #_programmirovanie (
Программирование
), #_sovershennyj_kod (
Совершенный код
), #_otladka (
Отладка
), #_protsessory (
Процессоры
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:20
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Знаете ли вы, как работает такая серьезная программа оценки производительности, как Intel VTune Amplifier? Не в смысле интерфейса с пользователем и разных возможностей, а на какой аппаратной поддержке она основана?Я попытался найти об этом информацию, но как-то разработчики этой программы не делятся с пользователями объяснениями, как именно они получают данные о пользовательской программе. Вероятно, никаких секретных команд и способов там нет. Все основано на сигналах прерываний и установке аппаратных и программных контрольных точек (которые тоже вызывают прерывания). Ну и, конечно, на чтении «телеметрии» самого процессора.Я не рассматриваю здесь интерпретируемые языки типа Питона. Ясно, что интерпретатор и безо всяких сигналов прерываний легко может собирать статистику при выполнении программы. А вот все остальное, кроме случаев вставки в код специальных вызовов, так или иначе, требует прерываний. Ну, или, например, виртуальной машины, которая тоже требует прерываний.При этом близкое к идеальному с точки зрения накладных расходов профилирование кода получается, когда используют метод Монте-Карло, который позволяет оценить распределение нагрузки с точностью до периода таймерного прерывания.Т.е. достаточно поставить обработчик на системный таймер и извлекать из автоматически запоминаемого контекста указатель текущей команды RIP (EIP). Затем, имея адреса подпрограмм, легко определить, какая именно подпрограмма работала в момент прерывания, и статистически учитывать это в профиле выполняемого кода. Поиск подпрограммы по адресу RIP процесс, конечно, тоже не мгновенный и не бесплатный, но его можно отложить, а в реальном времени лишь запоминать в памяти очередное значение RIP.Никакой специальной аппаратной поддержки в данном случае не требуется и для типового кода метод дает хорошие результаты даже для периодичности таймера порядка мс. Но программисты все равно недовольны: «для программ, обрабатывающих тысячи событий в секунду, требуется сильное уменьшение периода, а это и дает большие накладные расходы, и портит результат. Кроме этого, такой метод часто неприменим для профилирования низкоуровневого кода — тех же обработчиков прерываний, процедур планировщика ОС и т.п.»Помнится, давным-давно, в начале 90-х, у меня был настольный компьютер (к сожалению, забыл марку, по-моему, немецкий), у которого на передней панели был спидометр! Я не шучу. На его передней панели был индикатор из светодиодных сегментов для трех цифр. Согласно очень мутному описанию, он показывал число команд в штуках, то ли в среднем за тик, то ли еще за какое-то фиксированное время. В общем, он показывал какое-то число, обычно близкое к 1.00, и чем оно было выше, тем более производительным был в этот момент процессор.По тем временам прекрасная вещь для поиска «узких мест»! И, главное, специально для замеров в программе делать ничего не надо было: поменял очередной раз код, запустил тестовый прогон и смотришь на индикатор. Ну да, в те стародавние времена и тактовые частоты были невысокие, считалось все относительно медленно, и объем ПО был небольшим, да и MS DOS с современной точки зрения, это, вероятно, случай отсутствия ОС. Вполне можно было разглядеть на индикаторе любые незначительные отклонения производительности.С его помощью я, отчасти из спортивного интереса, отчасти из уязвленного самолюбия, пытался ускорить работу транслятора с ассемблера RASM-86. Он выполнял тест за 23.4 секунды, а микрософтовский MASM выполнял этот же тест за 8.3 секунды. С помощью этого волшебного индикатора я быстро нашел все узкие места и неудачные команды (конечно, они оказались в лексическом анализаторе) и добился выполнения теста за 5.6 секунды.И у этого примитивного средства было преимущество, которого, на мой взгляд, и не хватает для идеального профилирования выполняемого кода сегодня – аппаратная поддержка.По-моему, простую аппаратную поддержку профилирования кода несложно добавить в любой современный процессор. Если взять процессоры Intel, то такая поддержка могла бы быть реализована на внутреннем счетчике, подобному счетчику системных тактов, который можно прочитать с помощью инструкции RDTSC. Но в отличие от счетчика, читаемого RDTSC, дополнительный внутренний счетчик должен увеличиваться с каждым тактом не с момента включения процессора, а только при выполнении условий, заданных в программе.Разумеется, никаких новых команд вводить для этого не требуется. Задание условий для гипотетического дополнительного счетчика можно делать и через запись в порт самого процессора командой WRMSR, а чтение значения счетчика – командой чтения из порта процессора RDMSR. Кроме этого, запись в порт должна вызывать и сброс счетчика, чтобы не создавать для этого отдельное действие.В качестве условий вводится два адреса программы – начальный и конечный, а также один из двух способов их использования.Смысл в том, что при задании начального и конечного адресов внутренний счетчик тактов обнуляется и теперь увеличивается на каждом такте только, когда указатель RIP/EIP попадает внутрь заданного диапазона адресов. В другом режиме — счетчик начинает работу, когда RIP/EIP строго совпадает с начальным адресом и заканчивает, когда строго совпадает с конечным адресом. Такая незначительная доработка процессора позволит использовать его для профилирования выполняемого кода без какого либо изменения самого кода анализируемой программы и совершенно прозрачно для нее.В первом режиме я задаю начало и конец своей, может быть небольшой подпрограммы внутри огромного проекта, причем начало — это необязательно именно точка входа в подпрограмму. Затем просто запускаю главную программу, возможно, заканчиваю или останавливаю её прогон, а затем читаю получившийся счетчик — число тактов, которое управление находилось именно в этой подпрограмме, без учета, например, времени работы системных вызовов (так как они наверняка окажутся вне заданного диапазона адресов).Во втором режиме я задаю точку входа в подпрограмму и точку выхода из неё. И получаю счетчик тактов нахождения в подпрограмме уже с учетом всех вложенных вызовов. Только в том случае, если точек выхода несколько, возможно, придется слегка менять код программы, чтобы такое профилирование давало верные результаты.В большинстве же случаев можно не ставить никаких специальных отладочных вызовов, не использовать никаких прерываний и вообще никак не влиять на работу кода. И в результате получать некоторую количественную характеристику производительности выполнения анализируемого участка кода.При попытках улучшения теперь можно сравнивать не все время работы огромной программы, а лишь с такой же предыдущей количественной характеристикой, т.е. становится возможным увидеть изменения производительности в масштабах микро- и наносекунд, не запуская миллионы циклов теста.Таких команд, правда, пока нет. Но, возможно, что-то похожее именно для поддержки профилирования кода со стороны процессора в будущем и появится. А может быть, появится сначала в виртуальных машинах. =========== Источник: habr.com =========== Похожие новости:
Программирование ), #_sovershennyj_kod ( Совершенный код ), #_otladka ( Отладка ), #_protsessory ( Процессоры ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:20
Часовой пояс: UTC + 5