i32 лучше по производительности?
Это вообще какая-то тонкая вещь. Если мы посмотрим на некоторые недавние тесты на уровне инструкций, например, для SkylakeX по большей части очень явное отсутствие разницы между 64-битными и 32-битными инструкциями. Исключением является деление, 64-битное деление медленнее, чем 32-битное, даже при делении одних и тех же значений (деление — одна из немногих инструкций с переменным временем, которые зависят от значений ее входов).
Использование i64 для данных также делает автоматическую векторизацию менее эффективной — это также одно из редких мест, где данные размером менее 32 бит используются помимо оптимизации размера данных. Конечно, размер данных также имеет значение для вопроса i32 и i64, работа со значительными массивами i64 может быть медленнее только потому, что они больше, поэтому требуется больше места в кешах и (если применимо) большая пропускная способность. Так что если вопрос [i32]
против [i64]
, то это имеет значение.
Еще более тонким является тот факт, что использование 64-битных операций означает, что в среднем код будет содержать больше префиксов REX, что делает код немного менее плотным, а это означает, что меньшая его часть будет помещаться в кэше кода L1 одновременно. Хотя это небольшой эффект. Просто наличие 64-битных переменных в коде не является проблемой.
Несмотря на все это, определенно не злоупотребляйте i32, особенно там, где вам действительно нужен usize
. Например, не делайте этого:
// don't do this
for i in 0i32 .. data.len() as i32 {
sum += data[i as usize];
}
Это приводит к значительному снижению производительности. Мало того, что теперь в цикле есть бессмысленное расширение знака, оно также побеждает устранение проверки границ и автоматическую векторизацию. Но, конечно, в первую очередь нет причин писать такой код, это неестественно и сложнее, чем сделать это правильно.
person
harold
schedule
04.08.2018
i64
иf64
? - person Stargateur   schedule 04.08.2018usize
иisize
— единственные типы с этим свойством). - person trentcl   schedule 04.08.2018