Comments 16
Подкаст с Артёмом Кашкановым получился очень интересным, спасибо. Из его рассказов я узнал, что у интелловых процессоров есть самодостаточная аппаратная трассировка и что появилась она относительно недавно. Было бы интересно увидеть и прочитать здесь на Хабре статью на эту тему, с примерами использования. :)
Во времена NetBurst его преподносили как нечто прорывное, но на практике он так замедлял систему, что годился разве что для очень специфичных задач) PT на его фоне просто космос по эффективности
Неплохой штукой оказалась технология LBR, которая позволяла на самплинге получать неплохие стеки вызовов. С BTS я не взаимодействовал и ничего толкового сказать не могу
BTS похож на LBR, но адреса переходов сразу записывались в буфер в памяти, так что оверхед был заметно больше. И при этом была только трассировка переходов без дополнительной обработки - в LBR для сбора стеков явная поддержка.
Глянул, таки пишут пока про BTS в мануале (18.4.5 в моей версии), но не знаю, поддерживается ли сейчас где нибудь.
У ARM трассировка с рождения была.
Я как-то решил использовать ее и вставил в свой контроллер. И получил такое мессиво данных что оно практически бесполезно. Рядовой ПК с таким объемом еле справляется. Сессия записи короткая, но еще хуже софт, который эти данные обрабатывает. Он тупо показывает бесконечные пирамиды вызовов, там зумить будешь вечно пока доберешься до нужного места. А что искать сам не знаешь.
Вообщем смысла нет, легче свой отладочный вывод организовать через то же канал и свой софт для анализа. К счастью теперь есть Claude.
В подкасте мужик немного пургу несет, его проблема решается бреикпойнтами по паттенам данных. Инструменальный код для этого писать не надо.
Он тупо показывает бесконечные пирамиды вызовов, там зумить будешь вечно пока доберешься до нужного места.
Я совершенно не в теме, но что-то мне подсказывает, что должны быть механизмы задающие различные условия для начала трассировки (переход по адресу например, или доступ к данным по адресу) чтобы ограничить обьем.
Есть ощущение, что трассировка нужна для крайне бедовых ситуаций, когда нет надежды на отладочный вывод.
Да. Трассировка - это микроскоп для забивания гвоздей. Очень мощный инструмент там где все остальное уже не помогает. Отлично подходит для неинвазивной отладки драйверов или самого ядра, где не получится просто так поставить бряку. И всё без инструментации и перекомпиляции.
Был бы этот инструмент мощным его бы все применяли. А так это действительно микроскоп. Нужен только условным "ботаникам" с очень нишевым интересом.
Надо помнить - лог трассировщика не содержит данных. Он ничего не говорит о том что обрабатывалось. Это только голая последовательность инструкций и вызовов функций.
Относительно недавно - это смотря с чем сравнивать. Идеи аппаратной трассировки витали в воздухе давно, просто в потребительских CPU это стало доступно не так давно и что важнее с более-менее вменяемым инструментарием
Конкретно у Интела PT, про который рассказывал Артём, доступен начиная c Broadwell; на Silvermont была очень похожая технология (RTIT), но там трасса выдавалась через отдельные проводки (JTAG или что то вроде), для конечного пользователя не очень удобно )
История про то как я на ночь ставил сгружаться трассу по JTAG - это как раз про RTIT :) Это не другая технология - это тот же PT, только с внешним доступом через JTAG.
Впрочем, не знаю как именно на Silvermont, но на следующем поколении атомов - Goldmont, на которых я и веселился - полноценный доступ к PT был и через JTAG(спойлер: стриминг по USB DCI как раз и не работал) и со стороны системы.
Что касается Broadwell - PT впервые появилось именно там, но было бессмысленно для анализа производительности. Там лютый оверхед при коллекции трассы и нет микротаймстампов. Сколько помню мы в VTune его даже не поддерживали. Да и в принципе Broadwell на мой взгляд вышли неудачными. Один FPMUL на два потока чего только стоит. Поэтому и не упоминаю.
Отличный подкаст, без воды
Новый сезон «Битовых масок» — подкаста о системном программировании и разработке процессоров