Численная оптимизация - PullRequest
       17

Численная оптимизация

4 голосов
/ 27 февраля 2009

Мне было интересно, какие типы Integer или Float самые быстрые ..
я думал, что байт быстрее, чем целое число, потому что у него меньший диапазон.
Некоторые люди говорили мне ... что в некоторых случаях целое число быстрее байта.

второй вопрос:
GPU находится на пути к мировому господству ..
поэтому я спросил себя: может ли Double "быть быстрее", чем Integer .. из-за FPU
так где же эксперты? :)

Ответы [ 8 ]

6 голосов
/ 27 февраля 2009

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

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

4 голосов
/ 27 февраля 2009

Я думал, что байт быстрее целого, потому что у него меньший диапазон.

Что-то, что я испытал: использование short дало мне удар по производительности, тогда как использование int было просто замечательно. Это потому, что шорты обычно не существуют в архитектуре. Это удобные типы. Процессор фактически работает с его размером слова. В моем случае размер слова был таким, как у int. Таким образом, при доступе к шорту он должен был сначала упаковать значение в int, поработать с ним, а затем распаковать и получить результат в шорт. Все это привело к снижению производительности. Таким образом, короче не обязательно лучше.

1 голос
/ 27 февраля 2009

На уровне ЦП нет байтов, есть только слова, которые в настоящее время являются 32-битными или 64-битными. Арифметические единицы обычно запрограммированы для работы с числами размером с слово (или больше, в случае с плавающей запятой).

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

Однако, если у вас большой объем данных, например, большой массив, использование меньших типов обычно приведет к повышению производительности, поскольку у вас будет меньше ошибок кэша.

1 голос
/ 27 февраля 2009

Это зависит от того, нет ли данных в архитектуре. Процессор с плавающей точкой будет обрабатывать значения с плавающей и двойной одинаковыми значениями при выполнении вычислений. Они оба оцениваются с 80-битной точностью и поэтому занимают одинаковое количество времени. Загрузка и сохранение значений в регистры FPU может иметь значение. Double занимает вдвое больше места в оперативной памяти и поэтому может быть медленнее из-за нехватки кэша. Это заметно, если у вас есть большие массивы, которые вы склонны индексировать случайным образом.

0 голосов
/ 27 февраля 2009

Ну, пока вы не выполняете векторную оптимизацию, вы можете использовать целые числа размером с ваши регистры (32/64 бит) без какого-либо фактического снижения производительности.

Числа с плавающей точкой немного отличаются: хотя процессоры оптимизированы для удвоений, графические процессоры обычно работают с плавающими числами.

0 голосов
/ 27 февраля 2009

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

0 голосов
/ 27 февраля 2009

Какой из них быстрее, целочисленный или байтовый, если они оба вписываются в регистр, они работают одинаково или, по крайней мере, без ощутимой разницы.

Насчет целого числа против двойного: может быть, GPU выполняет более быструю арифметику с двойными числами, чем с обычным процессором, но я сомневаюсь, что она выполняет двойную арифметику быстрее, чем целое число, поскольку целочисленная арифметика просто регистрирует арифметику.

0 голосов
/ 27 февраля 2009

Длина байта числовых типов зависит от языка, а иногда и используемой вами платформы. Например, в java и int, и float используют 4 байта, поэтому время обработки должно быть одинаковым. Меня удивило бы, что более длинные типы обрабатываются быстрее. Если есть доказательства этого, я хотел бы прочитать об этом.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...