Использование long
для int
, вероятно, замедлит вас в целом.
Вас сразу беспокоит вопрос, требует ли int
на 64-битном процессоре дополнительное время обработки. Это очень маловероятно на современном конвейерном процессоре. Мы можем легко проверить это с помощью небольшой программы. Данные, с которыми он работает, должны быть достаточно маленькими, чтобы помещаться в кэш L1, поэтому мы проверяем эту конкретную проблему. На моей машине (64-битный Intel Core2 Quad) нет никакой разницы.
В реальном приложении большая часть данных не может находиться в кэш-памяти процессора. Мы должны беспокоиться о загрузке данных из основной памяти в кеш, что относительно медленно и обычно является узким местом. Такая загрузка работает на единицу «строк кэша», которая составляет 64 байта или более, поэтому загрузка одной long
или int
займет одно и то же время.
Тем не менее, использование long
приведет к потере драгоценного места в кеше, поэтому будет увеличиваться количество пропущенных кешей, что очень дорого. Также выделяется куча пространства Java, поэтому активность GC возрастет.
Мы можем продемонстрировать это, прочитав огромные массивы long[]
и int[]
с одинаковым количеством элементов. Они намного больше, чем могут содержать кеши. Длинная версия занимает на моей машине на 65% больше времени. Тест ограничен пропускной способностью memory-> cache, а объем памяти long [] на 100% больше. (почему это не занимает на 100% больше времени, вне меня; очевидно, в игру вступают и другие факторы)