Здравствуйте, Sharowarsheg, Вы писали:
S> R>Я попробовал этот тест собрать паскалем с llvm, так он вообще весь код выкинул за ненадобностью
S> Статья "о ценности синтетических бенчмарков"
Здравствуйте, eustin, Вы писали:
E>Можно ли в 2023 перейти целиком на 64 бита (b2c)? Сейчас для некоторых продуктов тащится 32 Битный exe на всякий случай.
Да, скорее нужно.
SSE2 по умолчанию на всех процессорах
Больше регистров богу регистров
Отсутсвие x86 системной прослойки — влияет на скорость перого запуска после перезагрузки и потребление физической памяти, если x86 софтина единственная.
Можно выделить МНОГО памяти непрерывным куском без извращений с маппингом.
Ф>>Есть серьёзное подозрение, что под дебаггером. ЕМ>Откуда? Отладчик, если он не безнадежно тупой, никак не взаимодействует с отлаживаемым процессом, пока тот не выполнит действие, вызывающее исключение — отладочный вывод, попадание на стоп-точку, ошибка и т.п. Если тестовый код не сыпет отладочными сообщениями сотни раз в секунду, производительность отличаться не будет.
Для отладочный версии компилятор может генерировать не самый оптимальный код в целях улучшения диагностики. По уму, надо релизные версии сравнивать.
Здравствуйте, Sharov, Вы писали:
Ф>>>Есть серьёзное подозрение, что под дебаггером.
S>Для отладочный версии компилятор может генерировать не самый оптимальный код
Запуск под отладчиком не имеет никакого отношения к генерации кода.
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Для отладочный версии компилятор может генерировать не самый оптимальный код ЕМ>Запуск под отладчиком не имеет никакого отношения к генерации кода.
Под отладчиком, если без лишний действий, будет запускаться отладочная версия, т.е. не
самая оптимальная.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Запуск под отладчиком не имеет никакого отношения к генерации кода.
Не то, чтобы я проверял, но, скажем, в MSVS 2022 есть галка в разделе Options -> Debugging, [ ] Suppress JIT optimization on module load (Managed only). Я не знаю, что она делает, но звучит подозрительно.
Здравствуйте, Sharowarsheg, Вы писали:
S>...[ ] Suppress JIT optimization on module load (Managed only). Я не знаю, что она делает, но звучит подозрительно.
Делает именно то, что написано. А ещё есть переменная среды (с разбегу не нашёл, какая именно), которая позволяет запретить загружать нативные образы из GAC. Тоже помогает при дебаге, особенно таких вещей, как WPF.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Sharowarsheg, Вы писали:
S>скажем, в MSVS 2022 есть галка в разделе Options -> Debugging, [ ] Suppress JIT optimization on module load (Managed only).
Оно и в VS 2005 есть.
S>Я не знаю, что она делает, но звучит подозрительно.
Оно тоже не имеет отношения к "запуску под отладчиком". С тем же успехом тому JIT'у можно как-то иначе передать инструкцию использовать этот режим.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Оно тоже не имеет отношения к "запуску под отладчиком". С тем же успехом тому JIT'у можно как-то иначе передать инструкцию использовать этот режим.
Здравствуйте, Sharowarsheg, Вы писали:
S>эта штука выключает (какую-то) оптимизацию при запуске под отладчиком, а без отладчика — не выключает. S>Мне представляется, что это имеет отношение к запуску под отладчиком.
Когда процесс запускается из студии, он всегда будет "под отладчиком" (студийным).
А еще есть IsDebuggerPresent.
Ну и уж явно нет никакого смысла кодом, генерируемым хоть каким JIT, измерять время работы команды инкремента, верно?
Здравствуйте, eustin, Вы писали:
E>Можно ли в 2023 перейти целиком на 64 бита (b2c)? Сейчас для некоторых продуктов тащится 32 Битный exe на всякий случай.
Да, но зачем? 32 бита жрут меньше памяти, и более портируемые.
64 бита нужны только если 4 гигов мало.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Когда процесс запускается из студии, он всегда будет "под отладчиком" (студийным).
В студии есть меню Debug -> Start without debugging.
Будет без отладчика. По крайней мере, без managed отладчика.
ЕМ>Ну и уж явно нет никакого смысла кодом, генерируемым хоть каким JIT, измерять время работы команды инкремента, верно?
Вообще особо нет смысла измерять время работы инкремента, но в целом, почему нет?
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Для отладочный версии компилятор может генерировать не самый оптимальный код ЕМ>Запуск под отладчиком не имеет никакого отношения к генерации кода.
Сборки в dotnet имеют два осн. типа -- debug и release. Для первого типа компилятор не делает слишком много оптимизаций,
чтобы облегчить жизнь отладчику -- не инлайнит ф-ии, переменные, не удаляет недостижимый код и т.п.
Здравствуйте, Sharov, Вы писали:
S>Сборки в dotnet имеют два осн. типа -- debug и release. Для первого типа компилятор не делает слишком много оптимизаций, S>чтобы облегчить жизнь отладчику -- не инлайнит ф-ии, переменные, не удаляет недостижимый код и т.п.
Вероятно речь про jit-компилятор.
Но обсуждение началось с паскаля, компилятор которого генерит нативный код.
Здравствуйте, Sharov, Вы писали:
S>Сборки в dotnet имеют два осн. типа -- debug и release.
Спасибо, кэп. Только при чем здесь dotnet? Они в MS VS такие с незапамятных времен, когда dotnet еще в проекте не было.
S>Для первого типа компилятор не делает слишком много оптимизаций
Верно, только какое это имеет отношение к "запуску под отладчиком"?
Здравствуйте, Sharov, Вы писали:
S>>>Под отладчиком, если без лишний действий, будет запускаться отладочная версия ЕМ>>"Лишних" — это каких?
S>Как минимум перелючение типа сборки из debug в release.
Вставьте в программу операцию, заведомо вызывающую необрабатываемое исключение, переключите в Release, соберите и запустите. Кто обработает исключение?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Верно, только какое это имеет отношение к "запуску под отладчиком"?
Для .NET есть разница в запуске релиза под отладчиком и без. При запуске релизной сборки (сам .NET "код" в релизе и дебаге одинаковый, для релиза просто соотв. флаг проставляется, так было в старом .NET) под отладчиком JIT генерит нативный код, отличный от того, если запустить сборку без оного. При желании посмотреть сгенерённый код без влияния отладчика использовалась техника запуска сборки (приложения) без отладчика, с дальнейшем аттачем к процессу.
