Эффективность встроенного типа
Под Самые эффективные виды второй Вот
…и при определении объекта для хранения числа с плавающей запятой, используйте тип double … Тип double в два-три раза менее эффективен, чем тип float …
Кажется, это противоречит самому себе?
И я читал в другом месте (не могу вспомнить, где), что вычисления с использованием целых чисел выполняются быстрее, чем короткие, на многих машинах, потому что они преобразованы в целые числа для выполнения операций? Это правда? Есть ссылки на это?
Решение
Всегда можно поспорить о качестве содержимого сайта, на который вы ссылаетесь. Но две цитаты, на которые вы ссылаетесь:
…и при определении объекта для хранения числа с плавающей запятой, используйте тип double, …
а также
… Тип double в два-три раза менее эффективен, чем тип float …
Обратимся к двум разным вещам: первые намеки на то, что использование двойных кодов даст гораздо меньше проблем из-за повышенной точности, а другие говорят о производительности. Но, честно говоря, я бы не стал обращать на это слишком много внимания, так как есть вероятность, что если ваш код работает неоптимально, это связано с неправильным выбором алгоритма, а не с неправильным выбором примитивного типа данных.
Вот цитата о сравнении производительности поплавков одинарной и двойной точности от одного из моих старых учителей: Агнера Фога, который читает много интересных материалов на своем сайте: http://www.agner.org об оптимизации программного обеспечения, если вы действительно заинтересованы в микрооптимизации, посмотрите на это:
В большинстве случаев вычисления с двойной точностью занимают не больше времени, чем простая точность. Когда используются регистры с плавающей запятой, просто нет разницы в скорости между одинарной и двойной точностью. Длинная двойная точность занимает немного больше времени. При использовании регистров XMM вычисляются деление с одинарной точностью, квадратный корень и математические функции быстрее, чем с двойной точностью, тогда как скорость сложения, вычитания, умножения и т. Д. Остается неизменной независимо от точности на большинстве процессоров (когда векторные операции не выполняются). используемый).
источник: http://agner.org/optimize/optimizing_cpp.pdf
Хотя могут быть разные варианты для разных компиляторов и разных процессоров, из этого следует извлечь урок: скорее всего вам не нужно беспокоиться об оптимизации на этом уровне, посмотрите на выбор алгоритма, даже контейнера данных, а не на примитивный тип данных.
Другие решения
Эти оптимизации незначительны, если вы не пишете программное обеспечение для запусков космических кораблей (что в последнее время не слишком хорошо). Правильный код гораздо важнее, чем быстро код. Если вам нужна точность, использование удвоений практически не повлияет на время выполнения.
Вещи, которые влияют на время выполнения больше, чем определения типов:
-
сложность — Чем больше работы, тем медленнее будет выполняться код. Сократите объем необходимой работы или разбейте ее на более мелкие и быстрые задачи.
-
Репетиция — Часто можно избежать повторений, что неизбежно ухудшит производительность кода. Это происходит во многих формах — например, неспособность кешировать результаты дорогостоящих вычислений или удаленных вызовов процедур. Каждый раз, когда вы пересчитываете, вы теряете эффективность. Они также расширяют размер исполняемого файла.
-
Плохой дизайн — Самоочевидно. Подумайте, прежде чем код!
-
I / O — Программа, выполнение которой заблокировано в ожидании ввода или вывода (для пользователя, диска или сетевого подключения), должна работать плохо.
Есть много других причин, но это самые большие. Лично, плохой дизайн — то, где я видел, что большая часть этого случается. Конечные автоматы, которые могли бы быть без состояний, динамическое распределение, где статическое было бы хорошо, и т. Д., Являются настоящими проблемами.
В зависимости от оборудования, фактическая производительность процессора (или FPU, если хотите) double находится где-то между половиной скорости и той же скоростью на современных процессорах [например, сложение или вычитание, вероятно, одинаковая скорость, умножение или деление могут отличаться для более крупного типа] по сравнению с float,
Вдобавок ко всему, на каждую строку кэша приходится «меньше», поэтому, если их большое количество, оно все равно замедляется, потому что скорость памяти ниже. На строку кэша их вдвое меньше. double значения -> примерно половина производительности, если приложение полностью связано с памятью. Это будет гораздо менее важным фактором в приложении с привязкой к процессору.
Точно так же, если вы используете SSE или аналогичные технологии SIMD, double будет занимать вдвое больше места, так что количество фактических вычислений будет вдвое меньше «на инструкцию», и, как правило, ЦП будет позволять одинаковое количество инструкций за цикл для обоих float а также double — за исключением некоторых операций, которые занимают больше времени для double, Опять же, около половины производительности.
Так что, да, я думаю, что страница в ссылке сбивает с толку и смешивает идеальную настройку производительности между double а также float, То есть с точки зрения чистой производительности. Часто гораздо легче получить заметные ошибки в расчетах при использовании float — который может быть боль выследить — поэтому, начиная с double и переключение на float если это необходимо, потому что вы определили это как проблему производительности (из опыта или измерений).
И да, есть несколько архитектур, в которых существует только одно целое число — или только два размера, например, 8-битный char и 32-битный intи 16-битный short будет моделироваться путем выполнения 32-битной математики, а затем отбрасывать верхнюю часть значения. Например MIPS имеет только 32-битные операции, но может хранить и загружать 16-битные значения в память. Это не обязательно делает это медленнее, но это, безусловно, означает, что это «не быстрее».
detector