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-битов, дългият е 64-битов. 64-битовият процесор обикновено може да работи по-добре от 32-битов процесор при 64-битово цяло число.

Използването на 32-битови цели числа на 64-битова платформа не е скъпо, поне не и в x64. Няма смисъл да избирате 32-битов пред 64-битов int или обратното в Java само от съображения за производителност. Ако сте използвали два 32-битови int вместо един 64-bit int, ще бъде по-бавно независимо от всичко. По същия начин, ако използвате 64-битова, където бихте могли да използвате 32-битова, това ще бъде по-бавно на някои платформи. С други думи, използвайте правилния тип данни за вашия проблемен домейн.

person L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o&#x    schedule 16.05.2010
comment
Точно така, оставете проблема да избере int размера вместо вас, а не микро-локални проблеми като int size на платформата. Не забравяйте, това е Java. Вашите клас файлове могат да се изпълняват навсякъде и веднъж там JIT ще оптимизира според нуждите и интелигентността. Ако по някаква странна причина локалната платформа може по-ефективно да се справя с int като 64-битови количества, тогава JIT може под капака да уреди int да бъдат 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?

Лоша идея, IMO

Дори ако има разлика между използването на 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