Допустимо использует случаи для reinterpret_cast для unaligned доступа к памяти vs memcpy?

Question

Внутри snappy имеется раздел с условной компиляцией, который выбирает указатель dereferencing a reinterpret_cast'ed как лучшую реализацию для чтения и записи потенциально невыровненных 16, 32 и 64-битных целых чисел на архитектурах, которые, как известно, поддерживают такие операции (например, x86) , Резерв для других архитектур заключается в использовании memcpy based implementation.

Мое понимание заключается в том, что реализация reinterpret_cast демонстрирует неопределенное поведение, а дефинирующий детектив clang undefined действительно отмечает это.

Что меня озадачивает, хотя это: почему бы просто не использовать реализацию на основе memcpy? Я бы ожидал, что все, кроме большинства сломанных компиляторов, будут использовать intrinsics для реализации этих вызовов memcpy, поскольку размер известен во время компиляции. На самом деле я ожидал бы идентичный код из обеих реализаций на любой современной инструментальной цепочке.

Однако я также признаю, что мгновенный был написан людьми, которые знают, о чем они. Поэтому мне остается задаться вопросом, есть ли еще какое-то преимущество в использовании механизма reinterpret_cast, который перевешивает его неопределенное поведение. Не хотите, чтобы производительность зависела от качества реализации компилятора? Что-то еще я не рассматривал?

Answer 1

Не зная программиста (-ов), который написал этот код в первую очередь, я сомневаюсь, что вы можете получить действительно авторитетный ответ.

Вот мое лучшее предположение: авторы не хотели полагаться на возможную оптимизацию memcpy (которая никоим образом не гарантируется спецификацией, даже если она реализована многими компиляторами). С другой стороны, запись reinterpret_cast очень, очень вероятно, приведет к простому негласному доступу, который ожидали авторы, практически на любом компиляторе.

В то время как умные современные компиляторы оптимизируют memcpy, более старые могут не быть. Согласованная производительность может быть очень важна для этой библиотеки, поэтому они, похоже, пожертвовали некоторой корректностью (поскольку reinterpret_cast представляется потенциально UB) в пользу получения более последовательных результатов в более широком наборе компиляторов.

Answer 2

Причина в том, что быстрее (на x86) загружать int из неравномерного адреса, чем копировать его, а затем загружать.

Накладные расходы на неравновесную нагрузку составляют около 2 раз. Память сводится к 4 байтовым чтениям, 4 байта (или 32 бит записи, в зависимости от компилятора), а затем вам по-прежнему нужна нагрузка. В лучшем случае оптимизатор может заметить, что чтение после чтения является избыточным.

Лично я бы реализовал безопасный метод как 4 байтовые нагрузки со сдвигами.