32 bit vs. 64 bit

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

// wbr

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

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

Мсье о PAE слышали?

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

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

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

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

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

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

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

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

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

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

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

// wbr

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

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

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

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

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

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

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

> жрут чуть больше памяти

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

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

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

prooflink?

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

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

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

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

http://en.wikipedia.org/wiki/64-bit#32_vs_64_bit

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

>prooflink?

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

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

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

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

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

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

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

>>prooflink?

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

Бгг.

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

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

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

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

Спасибо.

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

Нет.

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

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

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

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