тип данных int в 64-битной JVM. Это более неэффективно, чем долго?

Я слышал, что использование shorts в 32-битной системе просто более неэффективно, чем использование ints. Это то же самое для ints в 64-битной системе?

Python недавно (?) в основном объединил ints с long и имеет в основном один тип данных long, верно? Если вы уверены, что ваше приложение. тогда будет работать только на 64-битной версии, возможно ли (потенциально хорошая идея) использовать long для всего в Java?


java types int long-integer 32bit-64bit
person Enno Shioji    schedule 16.05.2010    source источник
comment
@bmarguiles: Извините, клянусь, я видел этот вопрос в SO, но не смог его найти...   -  person Enno Shioji    schedule 17.05.2010

Ответы (2)


arrow_upward
2
arrow_downward

Python long имеет произвольную точность, он не 64-битный. Python 3 изменил long на int, так что теперь есть только один целочисленный тип произвольной точности, это экономит программисту много работы. int в Java 32-битный, long 64-битный. 64-разрядный процессор обычно может работать лучше, чем 32-разрядный процессор, с 64-разрядным целым числом.

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

person L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o&#x    schedule 16.05.2010
comment
Именно, позвольте проблеме выбрать для вас размер int, а не микролокальные проблемы, такие как размер int платформы. Не забывайте, это Java. Файлы вашего класса могут работать где угодно, и JIT оптимизирует их по мере необходимости и с умом. Если по какой-то странной причине локальная платформа могла бы более эффективно обрабатывать целые числа как 64-битные величины, тогда JIT мог бы под капотом организовать целые числа как 64-битные величины. Что касается вашей программы, int составляет 32 бита. Пусть умные компиляторы делают свою работу. - person President James K. Polk; 17.05.2010
comment
Да, и оптимизация должна быть для JVM, вы хотите, чтобы ваш код работал быстрее на JVM (которая работает на чем угодно), а не на ARM или x86. Благоприятным побочным эффектом является то, что если есть аппаратная JVM, она будет запускать ваш код с оптимальной скоростью. - person L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o&#x; 17.05.2010

arrow_upward
2
arrow_downward

Если вы уверены, что ваше приложение. тогда будет работать только на 64-битной версии, возможно ли (потенциально хорошая идея) использовать long для всего в Java?

Плохая идея, имхо

Даже если есть разница между использованием int и long на 64-битной JVM (что я считаю крайне сомнительным), она не будет достаточно существенной для всего приложения, включая библиотеки, от которых вы зависите, чтобы гарантировать использование long для всего.

И есть некоторые потенциальные проблемы:

  • Вы будете использовать больше памяти, по крайней мере, для long[] по сравнению с int[].
  • Вы пожалеете, если ваше предположение о том, что никогда не нужно работать на 32-битной платформе, окажется неверным.

(Причина, по которой я думаю, что не будет существенной разницы в производительности, заключается в том, что проблема, если она есть, будет заключаться в извлечении и хранении невыровненных int-32. Но если это так, разработчики JVM, вероятно, позаботятся о том, чтобы Поля int-32 всегда выравниваются по адресам 64-битных слов.JVM обычно делают это уже с int-8 и int-16 на 32-битных архитектурах...)

person Stephen C    schedule 16.05.2010