LINUX.ORG.RU

32 bit vs. 64 bit


0

0

Есть сервер с современным процессором. Туда можно установить 64-х битный Linux и 32-х битный.

К своему стыду не знаю, какая будет разница кроме размеров указателей. Будет ли быстрее или медленнее 64 чем 32? Какие вообще отличия?

Спасибо.

★★


если вы задаётесь таким вопросом это означает, что 64бита вам не нужно и лучше довольствоваться старым добрым i386 :)

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от tailgunner

> Вычисления (в т.ч. шифрование) и работа с памятью больше 4Гиг должны быть быстрее.

О, уже что-то. А, скажем, какие-нибудь еще ограничения? Макс количество открытых сокетов или еще что-нибудь?

Kpoxman ★★
() автор топика
Ответ на: комментарий от dont

Это вы вышеотписавшемуся регистрату скажите, который похоже не знает.

anonymous
()

быстрее не будет, может быть только больше глюков связанных с тем что не все программы хорошо отлжены под 64 бита. 64 битную ОС имеет смысл ставить если есть приложения которым надо очень много памяти, Oracle там какой-нить с большой нагрузкой, у нас в винде он одним процессом выполняется и довольно легко достигается ограничение 2 гига на процесс

anonymous
()

если сервер и linux то 64 однозначно centos5 aka redhat5.

anonymous2 ★★★★★
()

Разница не только в размере указателей, а еще и в количестве general-purpose регистров. Для всяких компилируемых динамических (и не только динамических) ЯП (лисп, джава) это зело полезно (не знаю, использует ли эти преимущества jvm). Еще полезно для всяких программ, которые используют mmap — в 32-битной архитектуре, например, нельзя замапить целиком образ dvd-диска.

dmitry_vk ★★★
()
Ответ на: комментарий от dmitry_vk

> Для всяких компилируемых динамических (и не только динамических) ЯП (лисп, джава) это зело полезно

На самом деле, это зело полезно и для ядра. Ну и вообще, как то время идёт, и 4 гб у меня уже в ноутбуке стоит.

Вопрос появляется с периодчиностью два раза в месяц. Почитайте, что ли, на wiki про x86-64. Кроме в два раза большего числа регистров (что само по себе должно являться причиной перехода, ибо их на 32 битах ну очень мало) в 64-битном режиме есть ещё несколько вкусных плюшек, ускорящих работу и даже снижающих размер кода.

mv ★★★★★
()
Ответ на: комментарий от anonymous

> 32-битные системы, к сведению, не работают с памятью больше 4 гигов. *Вообще*

спасибо, дорогой анонимус, я обязательно приму к сведению эту бесценную информацию. однако. автор что-то говорил про память больше 4Gb? не заметил.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от Reset

> PAE это костыль. Самого главного - дать приложению использовать более 4х гиг оно не позволяет

Зато он позволяет использовать больше 4Гиг двум приложениям.

tailgunner ★★★★★
()

Могу рассказать о своих субъективных, и не очень, впечатлениях. Обычные приложения (компилируемые в нативный код) жрут чуть больше памяти, но незначительно, java жрет в 1.5-2 раза больше памяти. Быстрее ли стала работать система не знаю, вроде побыстрее (может это просто кажется). В любом случае за 64 битами ближайшее будущее и рано или поздно придется перейти.

a3
()
Ответ на: комментарий от a3

Даже 32-битную йаву имеет смысл запускать на 64-битном ядре, ибо ядро даст яве все 4 гб адресного пространства под память, что невозможно в случае 32-битного ядра.

mv ★★★★★
()
Ответ на: комментарий от generatorglukoff

> >Зато он позволяет использовать больше 4Гиг двум приложениям.

> и снижать производительность на 10-20%

prooflink?

anonymous
()
Ответ на: комментарий от mv

> Даже 32-битную йаву имеет смысл запускать на 64-битном ядре, ибо ядро даст яве все 4 гб адресного пространства под память, что невозможно в случае 32-битного ядра.

Ну это как-бы любой программе 64-битное ядро даст такую возможность. Как это оправдывает увеличение прожорливости в 2 раза? Причем нативные приложения показывают гораздо меньшую дельту прожорливости. Хоть в 64, хоть в 32 битной яве типы данных одинаковых размеров ведь.

a3
()
Ответ на: комментарий от true_admin

> питон хавал в два раза больше когда тут в Development какую-то прогу запускали :).

Ну, в общем, кроме явы я не заметил заметного увеличения расхода памяти.

a3
()
Ответ на: комментарий от generatorglukoff

> и снижать производительность на 10-20%

это как повезёт. Код может и быстрее заработать из-за большего кол-ва доступных регистров и некоторых других фич. Вообще, это уже сто раз обсасывалось на ЛОРе и очень подробно, неприлично уже про 64 бита спрашивать :)

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

>Код может и быстрее заработать из-за большего кол-ва доступных регистров и некоторых других фич.

вообще-то имело ввиду pae. нам точно регистров не добавилось.

generatorglukoff ★★
()
Ответ на: комментарий от true_admin

на 10-20% медленнее --- это было про PAE. 64битная система в большинстве случаев будет быстрее, особенно если требуются достаточно сложные математические вычисления. Ну и возможность без костылей адресовать память в несколько гигабайт тоже скорость вряд ли убавит.

dn2010 ★★★★★
()
Ответ на: комментарий от generatorglukoff

>>> и снижать производительность на 10-20%

>>prooflink?

>это личные ощущения.

Бгг.

tailgunner ★★★★★
()

Всем спасибо.

В отношении конкретно Linux еще что-нибудь можно отметить?

В частности, максимальное количество сокетов / открытых файлов в Linux зависит от разрядности?

Еще интересная мысль была про интерпретируемые языки. Может кто навскидку скажет, как 64 отразится на Erlang, Python? Станет ли лучше Postgres-у?

Спасибо.

Kpoxman ★★
() автор топика
Ответ на: комментарий от Kpoxman

> В частности, максимальное количество сокетов / открытых файлов в Linux зависит от разрядности?

Нет.

> как 64 отразится на Erlang, Python?

На SBCL отражается самым благоприятным способом.

> Станет ли лучше Postgres-у?

Скорее всего, да.

mv ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.