Короткий ответ: такие мик‑оптимизации оправданы только когда вы доказали профилированием, что деление реально в «горячей» ветви и что простая альтернатива даёт измеримый выигрыш на целевой платформе. В остальных случаях риск превышает пользу (читаемость, переносимость, точность).
Развернуто — основные соображения.
Что именно вы предлагаете заменить
- Обычная замена: $a/b$ → $a\times b^{-1}$, где $b^{-1}$ предвычислен как $1.0/b$ (для float/double).
- Для целых есть отдельные техники (magic‑mul + shift): $\lfloor a/d\rfloor$ заменяют на $\lfloor a\times m/2^k\rfloor$ с подобранными $m,k$.
Когда это оправдано
- Профилирование: деление действительно горячая точка (большая доля цикла CPU).
- Дивизор неизменяем в горячем цикле (или меняется редко), так что предвычисление инверсии выгодно.
- Допускается небольшая потеря точности или вы явно контролируете округление (часто в графике/нейросетях с fast‑math).
- Целевая архитектура имеет высокую латентность деления и быструю умножение/векторизацию; вы измерили выигрыш на таких CPU/GPU.
- Для векторных инструкций иногда есть быстрые инструкции recip/rsqrt + Newton‑Raphson refinement — оправдано при тщательной проверке.
Риски и ограничения
1. Точность и числовая семантика
- Умножение на приближённый $b^{-1}$ даёт погрешность; результаты могут отличаться от точного деления, особенно при краевых значениях (ноль, очень маленькие/большие числа, NaN, ±Inf, denormals).
- Разные компиляторы/архитектуры/режимы округления могут давать разные результаты; вычисления перестают быть репродуцируемыми.
- Для целых операций замены требуют аккуратного выбора «magic» констант; неверная реализация даёт баги.
2. Переносимость и аппаратные различия
- На некоторых платформах компилятор уже делает аналогичную оптимизацию; на других — нет. На некоторых CPU деление не так дорого, и трюк может даже замедлить (из‑за дополнительных нагрузок на FPU, instruction throughput, или если инверсия требует нормализации).
- Поведение на GPU/ARM/x86 может различаться; векторизация и latency/throughput метрики важны.
3. Читаемость и поддержка
- Код становится менее очевидным: будущий читатель может не понять мотивацию, усложнённое выражение хуже тестируется.
- Отладка проблем с точностью сложнее; тестов может оказаться недостаточно.
4. Семантика исключений и побочных эффектов
- Деление и умножение могут по‑разному обрабатывать флаги FP (overflow, divide-by-zero и т.д.). Для корректности нужно явно обрабатывать особые случаи.
Практические рекомендации
- Сначала профиль: убедитесь, что деление реально узкое место.
- Измерьте на целевой платформе (микробенчмарки под realistic workload).
- Если оптимизация нужна:
- Для float/double: предвычисляйте $r=1.0/b$ и используйте $a\times r$ только если вы проверили точность и поведение с NaN/Inf/0.0. Рассмотрите дополнительный шаг Newton‑Raphson для повышения точности.
- Для целых: используйте проверенные алгоритмы «magic constants» (или встроенные компиляторные оптимизации), не придумывайте ad‑hoc.
- Документируйте причину и оставьте тесты с допуском по ошибке (unit tests, property tests).
- Рассмотрите компиляторские флаги (например, -ffast-math) — они могут резко изменить поведение/производительность, но влияют на корректность.
- Альтернатива: доверяйте компилятору — современные компиляторы часто автоматически превратят деление на константу в умножение или применят оптимизации для векторных инструкций.
Краткое резюме
- Оправдано: когда профиль показывает узкое место, дивизор стабильный, вы контролируете погрешности и тестируете на целевой платформе.
- Не оправдано: ради преждевременной оптимизации в коде, где деление не критично, или без проверки переносимости и числовой корректности.