Будет ли использование длинных вместо целых выгод в 64-битной Java - PullRequest
17 голосов
/ 01 августа 2011

В 64-битной ВМ использование longs вместо ints улучшится с точки зрения производительности, учитывая, что long - 64-битные в Java и, следовательно, извлечение и обработка 64-битных словможет быть быстрее, чем 32-битное слово в 64-битной системе.(Я ожидаю много НЕТ, но я искал подробное объяснение).

РЕДАКТИРОВАТЬ : я подразумеваю, что "извлечение и обработка 64-битного слова может быть быстрее, чем извлечение 32-битного словав 64-битной системе "потому что я предполагаю, что в 64-битной системе для извлечения 32-битных данных потребуется сначала получить 64-битное слово, а затем замаскировать старшие 32 бита.

Ответы [ 3 ]

22 голосов
/ 02 августа 2011

Использование long для int, вероятно, замедлит вас в целом.

Вас сразу беспокоит вопрос, требует ли int на 64-битном процессоре дополнительное время обработки. Это очень маловероятно на современном конвейерном процессоре. Мы можем легко проверить это с помощью небольшой программы. Данные, с которыми он работает, должны быть достаточно маленькими, чтобы помещаться в кэш L1, поэтому мы проверяем эту конкретную проблему. На моей машине (64-битный Intel Core2 Quad) нет никакой разницы.

В реальном приложении большая часть данных не может находиться в кэш-памяти процессора. Мы должны беспокоиться о загрузке данных из основной памяти в кеш, что относительно медленно и обычно является узким местом. Такая загрузка работает на единицу «строк кэша», которая составляет 64 байта или более, поэтому загрузка одной long или int займет одно и то же время.

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

Мы можем продемонстрировать это, прочитав огромные массивы long[] и int[] с одинаковым количеством элементов. Они намного больше, чем могут содержать кеши. Длинная версия занимает на моей машине на 65% больше времени. Тест ограничен пропускной способностью memory-> cache, а объем памяти long [] на 100% больше. (почему это не занимает на 100% больше времени, вне меня; очевидно, в игру вступают и другие факторы)

4 голосов
/ 01 августа 2011

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

Что я имею в виду, если вам нужно 64-битная длина, тогда используйте 64-битную, но если выне требуется 64-битная длина, тогда используйте int.

Использование 32-битной на 64-битной платформе не дорого, и нет смысла проводить сравнение на основе производительности.

Для меня это выглядит не так:

for(long l = 0; l<100; l++)
 //SendToTheMoon(l);

И SendToTheMoon не имеет к этому никакого отношения.

1 голос
/ 01 августа 2011

Может быть быстрее, может быть медленнее.Зависит от конкретной реализации Java и от того, как вы используете эти переменные.Но в целом, это, вероятно, не достаточно разницы, чтобы беспокоиться.

...