Ну да - всё таки если нужна производительность, от многомерного массива ожидается что он аллоцирован один раз последовательным куском, но при этом разные индексы по разному влияют на смещение от начала. В плюсы для этого таки завезли mdspan.
А по сравнению собственно кодогенератора Go (стандартной реализации от гугла) и clang/gcc есть какие-нибудь сравнения? Как там в плане базовых оптимизаций (анроллинг циклов и т.п.), автовекторизации и прочего? Что насчёт выбора последовательности инструкций под конкретную модель процессора (clang/gcc для этого используют описание микроархитектуры в файликах вродеэтих)?
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.
Ну да - всё таки если нужна производительность, от многомерного массива ожидается что он аллоцирован один раз последовательным куском, но при этом разные индексы по разному влияют на смещение от начала. В плюсы для этого таки завезли mdspan.
А по сравнению собственно кодогенератора Go (стандартной реализации от гугла) и clang/gcc есть какие-нибудь сравнения? Как там в плане базовых оптимизаций (анроллинг циклов и т.п.), автовекторизации и прочего? Что насчёт выбора последовательности инструкций под конкретную модель процессора (clang/gcc для этого используют описание микроархитектуры в файликах вроде этих)?
Только по историческим причинам он всегда инкрементировался с фиксированной частотой.
Угу, соответственно тот досовский edit вообще не помню - для быстрого редактирования можно же просто нажать F4 )
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).