x86 4 байта с плавающей запятой против 8 байтов удваивается (по сравнению с длинным длинным)?

Это зависит от того, что вы делаете. Сложения, вычитания и умножения на double выполняются так же быстро, как и на float на современных процессорах с архитектурой x86 и POWER. Деление, квадратный корень и трансцендентные функции (exp, log, sin, cos и т. д.) обычно заметно медленнее с двойными аргументами, поскольку время их выполнения зависит от желаемой точности.

Если вы используете фиксированную точку, умножения и деления должны быть реализованы с помощью инструкций умножения/деления длинных целых чисел, которые обычно медленнее, чем арифметика на doubles (поскольку процессоры не оптимизированы для этого). Тем более, если вы работаете в 32-битном режиме, где длинное 64-битное умножение со 128-битным результатом должно быть синтезировано из нескольких 32-битных длинных умножений!

Использование кэша здесь является отвлекающим маневром. 64-битные целые и двойные числа имеют одинаковый размер - если вам нужно больше 32 бит, вы получите этот штраф, несмотря ни на что.

Поищи это. И Intel, и Intel публикуют задержки инструкций для своих процессоров в свободно доступных PDF-документах на своих веб-сайтах.

Однако по большей части производительность не будет существенно отличаться по нескольким причинам:

• при использовании x87 FPU вместо SSE все операции с плавающей запятой вычисляются с точностью до 80 бит внутри, а затем округляются, что означает, что фактическое вычисление одинаково затратно для всех типов с плавающей запятой. Тогда единственная стоимость действительно связана с памятью (с точки зрения использования кеша ЦП и пропускной способности памяти, и это проблема только в float против double, но не имеет значения, если вы сравниваете с int64)
• с SSE или без него почти все операции с плавающей запятой являются конвейерными. При использовании SSE инструкции double могут (я не смотрел это) иметь более высокую задержку, чем их эквиваленты float, но пропускная способность одинакова, поэтому должна быть возможность достичь аналогичной производительности с doubles.

Также не факт, что тип данных с фиксированной точкой на самом деле будет быстрее. Возможно, но накладные расходы на поддержание согласованности этого типа данных после некоторых операций могут перевесить экономию. Операции с плавающей запятой довольно дешевы на современном процессоре. У них есть небольшая задержка, но, как упоминалось ранее, они, как правило, конвейерные, что потенциально скрывает эту стоимость.

Итак, мой совет:

1. Напишите несколько быстрых тестов. Не должно быть так сложно написать программу, которая выполняет ряд операций с плавающей запятой, а затем измерить, насколько double версия медленнее, чем float.
2. Посмотрите это в руководствах и убедитесь сами, есть ли существенная разница в производительности между вычислениями float и double.

Мне трудно понять обоснование «в два раза медленнее, чем с плавающей запятой, мы будем использовать 64-битное целое». Угадывание производительности всегда было черным искусством, требующим большого опыта, на сегодняшнем оборудовании это еще хуже, учитывая количество факторов, которые необходимо учитывать. Даже измерить сложно. Я знаю несколько случаев, когда микротесты соответствовали одному решению, но измерение контекста показывало, что другое было лучше.

Во-первых, обратите внимание, что два фактора, которые были даны для объяснения заявленной более медленной производительности double, чем float, здесь неуместны: необходимая пропускная способность будет такой же для double, как и для 64-битного int, а векторизация SSE2 даст преимущество для double...

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

Поэтому я сомневаюсь, что вращение вашей собственной арифметики с фиксированной точкой будет выгоднее использования double (но меры могут показать мне, что я ошибаюсь).

Реализация 64 фиксированных точек не очень интересна. Особенно для более сложных функций, таких как Sqrt или логарифм. Целые числа, вероятно, будут немного быстрее для простых операций, таких как сложения. И вам нужно будет иметь дело с целочисленными переполнениями. И вам нужно быть осторожным при округлении, иначе могут легко накапливаться ошибки.

Мы реализуем фиксированные точки в проекте C#, потому что нам нужен детерминизм, который с плавающей запятой в .net не гарантируется. И это относительно болезненно. Некоторая формула содержала переполнение x^3 bang int. Если у вас нет действительно веских причин не делать этого, используйте float или double вместо фиксированной точки.

Инструкции SIMD из SSE2 еще больше усложняют сравнение, поскольку они позволяют работать с несколькими числами с плавающей запятой (4 числа с плавающей запятой или 2 числа типа double) одновременно. Я бы использовал double и попытался воспользоваться этими инструкциями. Таким образом, double, вероятно, будет значительно медленнее, чем float, но сравнивать с ints сложно, и я бы предпочел float/double фиксированной точке в большинстве сценариев.

Всегда лучше измерять, а не гадать. Да, на многих архитектурах вычисления на doubles обрабатывают вдвое больше данных, чем вычисления на floats (а long doubles еще медленнее). Однако, как указывалось в других ответах и ​​комментариях к этому ответу, архитектура x86 не следует тем же правилам, что, скажем, процессоры ARM, процессоры SPARC и т. д. На x86 floats, doubles и long doubles преобразуются в long doubles для вычисления. Я должен был это знать, потому что преобразование делает результаты x86 более точными, чем SPARC, и Sun приложила много усилий, чтобы получить менее точные результаты для Java, вызвал споры (обратите внимание, что эта страница создана в 1998 году, с тех пор все изменилось).

Кроме того, вычисления с doubles встроены в ЦП, где вычисления с фиксированным десятичным типом данных были бы написаны программно и потенциально медленнее.

Вы должны быть в состоянии найти приличную десятичную библиотеку фиксированного размера и сравнить.

С различными наборами инструкций SIMD вы можете выполнять 4 операции с плавающей запятой одинарной точности по той же цене, что и одна, по сути, вы упаковываете 4 операции с плавающей запятой в один 128-битный регистр. При переключении на двойники вы можете упаковать в эти регистры только 2 двойника и, следовательно, вы можете выполнять только две операции одновременно.

Как говорили многие люди, 64-битный int, вероятно, не стоит того, если есть вариант double. По крайней мере, когда SSE доступен. Это может отличаться на микроконтроллерах различных типов, но я думаю, что это не ваше приложение. Если вам нужна дополнительная точность в длинных суммах с плавающей запятой, вы должны помнить, что эта операция иногда проблематична с числами с плавающей запятой и двойными числами и была бы более точной для целых чисел.