История изменений

Есть, анализ диапазонов и удаление мёртвого кода. Либо их отключаем вовсе и получаем медленный код, либо не отключаем и получаем возможностьтрансформацийна основании UB.

Каким образом отсутствие удаления мёртвого кода приведёт к более медленному коду? Мёртвый код не выполняется по оперделению, поэтому не может тормозить. Максимум, он даст чуть больше нагрузки на кэш и память, если будет прямо рядом с живым, но и то не факт.

Но ей богу, пример с unreachable просто высосан из жопы, как и все остальные примеры UB с unsafe. Для таких людей ещё на ручных гранатах пишут: «В РОТ НЕ КЛАСТЬ, В ЖОПУ НЕ СОВАТЬ». Ничего неожиданного от такого использования unsafe{} нет.

Если фронтенд не сформировал кода, который может приводить к UB (как безопасное подмножество Rust), то проблем нет. Но тогда в общем случае код будет медленнее, так как необходимы дополнительные проверки.

Тогда почему в бенчмарках код на расте без unsafe{} показывает производительность на одном уровне с C? По твоим словам выходит, что если тот же код переписать с unsafe{}, он будет ещё быстрее.

Есть, анализ диапазонов и удаление мёртвого кода. Либо их отключаем вовсе и получаем медленный код, либо не отключаем и получаем возможностьтрансформацийна основании UB.

Каким образом отсутствие удаления мёртвого кода приведёт к более медленному коду? Мёртвый код не выполняется по оперделению, поэтому не может тормозить. Максимум, он даст чуть больше нагрузки на кэш и память, если будет прямо рядом с живым, но и то не факт.

Но ей богу, пример с unreachable просто высосан из жопы, как и все остальные примеры UB с unsafe. Для таких людей ещё на ручных гранатах пишут: «В РОТ НЕ КЛАСТЬ, В ЖОПУ НЕ СОВАТЬ». Ничего неожиданного от такого использования unsafe{} нет.