BTS похож на LBR, но адреса переходов сразу записывались в буфер в памяти, так что оверхед был заметно больше. И при этом была только трассировка переходов без дополнительной обработки - в LBR для сбора стеков явная поддержка.
Глянул, таки пишут пока про BTS в мануале (18.4.5 в моей версии), но не знаю, поддерживается ли сейчас где нибудь.
Конкретно у Интела PT, про который рассказывал Артём, доступен начиная c Broadwell; на Silvermont была очень похожая технология (RTIT), но там трасса выдавалась через отдельные проводки (JTAG или что то вроде), для конечного пользователя не очень удобно )
Не надо сравнивать тёплое с мягким ) Микроархитектура P4 - отдельная история; BTS и PT сами по себе заметно отличаются по формату и размеру генерируемых данных. С какого то момента BTS совсем вырезали, сейчас даже упоминаний в SDM не вижу.
В принципе ещё на Pentium 4 был BTS (Branch Trace Store), но там оверхед был заметно выше, чем у PT/RTIT. По использованию PT можно начать отсюда. А так то @radiolokздесь тоже бывает )
Раз уж статья про 3.14 - то там можно взять билд без GIL и параллелить внутри одного интерпретатора, интересно было бы сравнить разные подходы (с точки зрения производительности и сложности написания/поддержки кода).
А с целыми есть два более-менее распространённых варианта представления отрицателньых чисел - хотя найти сейчас живую машинку c ones' complement непросто.
Вот это меня тоже напрягает - как то стало принято игнорировать даже системные цвета для заголовков активных/неактивных окон, даже MS Office этим отличается. Да и сами настройки для явного задания этих цветов сильно запрятали.
Любая реализация должна опираться на уже существующий нижележащий уровень, лимитов которого не может обойти.
Как вариант - при исчерпании ресурсов текущих накопителей ждём, пока не добавят новый, после чего привязываем его к текущему файлу. Объём производства накопителей пока не останавливается - что будет дальше неизвестно, но по крайней мере жёстких лимитов нет. В любом случае это уже детали реализации за пределами семантики C++.
Позиция необязательна - для stdin/stdout она вообще смысла не имеет, не вижу препятствий к реализации потока с сохранением информации, с которым работают read/write, но не seek/tell.
Там же дело не в видимых результатах выполнения инструкций (которые определены документацией), а в деталях реализации и времени исполнения (замеряя которое и вытаскивается теоретически недоступная информация). По времени чёткой документации нет - есть таблички с latency/throughput для инструкций, но в общем случае их недостаточно для предсказания времени работы произвольного куска кода.
BTS похож на LBR, но адреса переходов сразу записывались в буфер в памяти, так что оверхед был заметно больше. И при этом была только трассировка переходов без дополнительной обработки - в LBR для сбора стеков явная поддержка.
Глянул, таки пишут пока про BTS в мануале (18.4.5 в моей версии), но не знаю, поддерживается ли сейчас где нибудь.
Ответ скорее "получите опыт работы с полезным инструментом" - qemu для эмуляции, сбора трасс и т.п. в индустрии вполне себе применяется.
Видимо как то так.
Конкретно у Интела PT, про который рассказывал Артём, доступен начиная c Broadwell; на Silvermont была очень похожая технология (RTIT), но там трасса выдавалась через отдельные проводки (JTAG или что то вроде), для конечного пользователя не очень удобно )
Не надо сравнивать тёплое с мягким ) Микроархитектура P4 - отдельная история; BTS и PT сами по себе заметно отличаются по формату и размеру генерируемых данных. С какого то момента BTS совсем вырезали, сейчас даже упоминаний в SDM не вижу.
В принципе ещё на Pentium 4 был BTS (Branch Trace Store), но там оверхед был заметно выше, чем у PT/RTIT. По использованию PT можно начать отсюда. А так то @radiolokздесь тоже бывает )
На arm и x86_64 (и прочих более-менее распространённых) в этом плане отличий нет )
Раз уж статья про 3.14 - то там можно взять билд без GIL и параллелить внутри одного интерпретатора, интересно было бы сравнить разные подходы (с точки зрения производительности и сложности написания/поддержки кода).
IEEE 754 же )
А с целыми есть два более-менее распространённых варианта представления отрицателньых чисел - хотя найти сейчас живую машинку c ones' complement непросто.
Значит это была уже 4. Один знакомый фидошную ноду держал на NT 3.51
Вот это меня тоже напрягает - как то стало принято игнорировать даже системные цвета для заголовков активных/неактивных окон, даже MS Office этим отличается. Да и сами настройки для явного задания этих цветов сильно запрятали.
Как вариант - при исчерпании ресурсов текущих накопителей ждём, пока не добавят новый, после чего привязываем его к текущему файлу. Объём производства накопителей пока не останавливается - что будет дальше неизвестно, но по крайней мере жёстких лимитов нет. В любом случае это уже детали реализации за пределами семантики C++.
Спасибо, как то пропустил.
Позиция необязательна - для stdin/stdout она вообще смысла не имеет, не вижу препятствий к реализации потока с сохранением информации, с которым работают read/write, но не seek/tell.
В семантике C++ (стандартной библиотеки) есть файлы, в которых тоже может храниться состояние программы.
Фича - это на такую инструкцию сгенерировать #UD (06h).
Никто не мещает хранить состояние на внешних ресурсах и подключать новые в процессе работы программы.
Так как в нынешнем C++ правильно работать с отдельными битами double/float?
По хорошему либо выполняется документированная команда, либо генерируется соответствующее исключение. Но да, далеко не везде это так.
Писать код через db не так уж и странно (скажем, если надо использовать новые инструкции, которые ещё не завезли в тулчейн).
Так это именно bug, а не feature )
Там же дело не в видимых результатах выполнения инструкций (которые определены документацией), а в деталях реализации и времени исполнения (замеряя которое и вытаскивается теоретически недоступная информация). По времени чёткой документации нет - есть таблички с latency/throughput для инструкций, но в общем случае их недостаточно для предсказания времени работы произвольного куска кода.