Если Вы по массиву линий идёте только в одну сторону и не возвращаетесь, то лишние 4 байта ни на чём сказаться не должны. Про memory prefetch Вы уже тоже прочитали?

Можно и целочисленное деление, но я гуглил и вроде как i32/i64.div (я так понимаю это idiv в x86-64) не сильно быстрее флоатного деления, мне действительно нужно получить только целую часть результата деления целого числа которое в 0-255 раз больше второго (и соотвественно получить целый результат деления который будет в промежутке 0-255). То есть нужно получить только первые 8 бит результата. Например 736755/8437 = 87.324285... но мне нужно только значение 87 потому что конечный результат (цвет пикселя) кодируется одним байтом

Да знаю я про префетч и про последовательное хранение/чтение данных в памяти (типа первое обращание грузит 64 байта в кеш а дальше мы считываем уже из кеша) но учитывая что вся линия будет кодироваться всего 8 байтами то лишние 4 байта для кеширования флоат-константы это 50% оверхеда по bandwidth и меньшей эффективности кеша

есть еще арифметика с фиксированной точкой, можно как вариант рассмотреть ее

целочисленное деление и деление с плавающей точкой имеют совршенно разные алгоритмы и скорости. Целочисленное действительно медлненное для общего случая если только у вас не Zen2/Zen3 архитектура, с плавающей же точкой деление не сильно медленее умножения с плавающей точкой

Разве? Везде пишут что деление примерно на порядок медленнее чем умножение (например тут есть подробный ответ https://stackoverflow.com/questions/4125033/floating-point-division-vs-floating-point-multiplication). Может не особо сильно по latency но более значительно по throughput а еще я помню из курса по процессорам что float alu-блоков обычно меньше чем целочисленных и вместо параллельного выполнения инструкций (out-of-order) будут лишние паузы. В общем все советуют выносить деление в виде константы 1/x за пределы горячего цикла (чтобы внутри цикла умножать на заранее вычисленное 1/x значение)

Ну относительно.
Деление примерно в 5-6 раз медленее чем умножение для floating points
А вот с целочисленным аж в 15-40 раз

Кстати компилятор оптимизирует случаи вроде x / 2.0 в x * 0.5 но только если делитель является степенью двойки

Вы bandwidth неправильно считаете. С пайплайнингом и OoO execution оно не так будет работать. 😊

Я думал про это, но мы все равно приходим к плавающей запятой. Вычисления с фиксированной точкой тут не подходят потому что ошибка зависит от того насколько большой делитель (точнее коэффициент 1/x) - для маленьких чисел нужно хранить больше цифр после запятой а для больших - меньше. Я так прикинул - там даже 16-битного флоата будет много и можно еще меньше хранить. Ну а потом такая мысль - раз нам нужно получить только первые 8 бит результата (число в промежутке 0-255) то может достаточно просто выполнить ручное деление в столбик до тех пор пока не получим первые 8 бит и это если это будет не сильно затратно (несклько шифтов и сложений) то это будет идеальное решение

Ну если у нас затык в вычислениях (alu) то разницы по скорости действительно не будет. Но если вычислений наоборот немного то процессор начнет ждать загрузку из кеша или памяти и соотвественно чем более компактно уложим данные в памяти тем больше вычислений сможем проделать после загрузки данных и меньше будем ждать загрузки следующей порции данных

Процессор в любом случае будет ждать память, поэтому разница будет не в разы, а на проценты.

Ну и ещё, чисто для ясности: из четырёх integer ALU на ядро, делить обычно умеет только один. Если FP ALU больше одного, то распараллеливаться будут как раз только FP деления (на одном ядре).

а скорость целочисленного деления от чего зависит?

От шинины регистра и последнего и позиции дидирующей единицы для делителя и делимого. Но это только для архитектур отличных от Zen2/Zen3. В ней используется новый алгоритм который не зависит от этого

Кстати а никто не видел скоростного вычисления обычного квадратного корня? А то для 1/sqrt(x) есть так называемый "fast inverse square root" хак а для обычного корня ничего не гуглится

Еще один интересный вопрос - умеют ли процессоры оптимизировать тривиальные значения (1, -1 и 0) для медленных операций деления и вычисления квадратного корня ? Понятно что если это будут константы в коде то сам компилятор это поудаляет но что если это динамические значения из памяти которые известны только в рантайме? Есть ли в процессоре в каком-нибудь instruction decoder блоке проверка что если делитель равен 1 то ничего не делаем, если -1 то меняем знак а если 0 то подставляем Infinity-константу (ну и для всех остальных значений будет медленное выполнение деления). И то же самое с корнем - если sqrt(1) или sqrt(0) то подставляем соответственно 1 или 0

а эти 8 бит должны быть точными или могут быть некоторым приближением?

если второе, то можно воспользоваться теоремой об отображении и неподвижной точке и аппроксимировать y = sqrt(x) параболой и по ней сходиться кваратично к решению

(в советском ядерном проекте так собственно и делали)

а тут при расчёте будет только умножение и вычитание без деления