LINUX.ORG.RU

32 vs 64


1

1

Часто задают вопрос о том, какой вариант конкретного дистрибутива выбрать - 32-битный или 64-битный. Для того, чтобы облегчить выбор, в FAQ помещена статья на эту тему: www.linux.org.ru/wiki/en/32_или_64_бита Материал будет расширяться и дополняться. Свободные обсуждения - в этом топике.

★★★★★

Ответ на: комментарий от emulek

Тянуть 32х ради «не падения производительности на дохлом железе»? Можно. В критичных случаях. Но не на массовых десктопах и рабочих станциях. И это стоит бабла. Тащить костыли.

dk- ()
Ответ на: комментарий от rogerw

Аксиома - фундаментальная истина, не требующая проверки

...аксиомы и проверяются особенно тщательно, ибо лежат в основе.

Догма — основное положение какого-либо учения, принимаемое в рамках данного учения истинным без требования доказательства.

лечи селективное зрение, и научись цитировать.

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

только он медленнее получается. Подумай о том, как в такой список вставлять.

Нормально там все вставляется, т.к. массивы (чанки) берутся небольшого размера. И скорость произвольного доступа действительно выше, чем у простого списка.

no-such-file ★★★★★ ()
Ответ на: комментарий от dk-

Тянуть 32х ради «не падения производительности на дохлом железе»?

не. Я не об этом. ИМХО нужно переходить на 64 бита. Даже ценой апгрейда памяти или замены дохлого железа.

И это стоит бабла

угу. Как раз тот случай, когда скупой платит дважды. Не будут разработчики ориентироваться на 32 бита, если это не кофемолка без интернета и одной кнопки.

emulek ()
Ответ на: комментарий от no-such-file

Нормально там все вставляется, т.к. массивы (чанки) берутся небольшого размера.

они у тебя получаться разные, что усилит фрагментацию памяти. Будет очень много дыр в твоей памяти. Причём всё это ещё и усугубляется тем, что памяти мало. Её мало просто из-за маленькой шины в 32 бита, и с этим ты ничего не сделаешь. Кроме того, ломается последовательный доступ, т.е. ты уже не можешь выделять блоки 9001, 9002, 9003... После 9001 тебе придётся прыгнуть в 1234, а потом в 5343. Это ломает напрочь кеширование и упреждающее чтение, которое всё равно работает(т.е. пока ты обрабатываешь 9001й блок, процессор параллельно читает 9002й, но тебе нужен будет не он, а 1234й).

В итоге, приложения требующие хотя-бы 500 метров(e.g. браузер), работают заметно быстрее на 64х битах, хотя и жрут намного меньше 4х Гб.

И с этим ничего не поделать — браузер жрёт так много потому, что в этом вашем интернете web2.0 во все поля, и сайты пишут криворукие говнокодеры, вставляющие тонны жабоскриптов куда надо и не надо. Увы. В 2001ом такого не было. Да и с другими приложениями та же беда.

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

они у тебя получаться разные, что усилит фрагментацию памяти. Будет очень много дыр в твоей памяти.

Не обязательно. Можно перемещать/уплотнять чанки на лету. А можно и не на лету, а по запросу. В любом случае оверхэд сильно меньше, чем при вставке в сплошной массив.

Её мало просто из-за маленькой шины в 32 бита, и с этим ты ничего не сделаешь

Про это я ничего не говорил.

Это ломает напрочь кеширование и упреждающее чтение, которое всё равно работает(т.е. пока ты обрабатываешь 9001й блок, процессор параллельно читает 9002й, но тебе нужен будет не он, а 1234й).

Ничего это не ломает. Для управления предвыборкой есть специальные инструкции процессора, но, даже если это не учитывать, кэш работает не так тупо, как ты написал.

no-such-file ★★★★★ ()
Ответ на: комментарий от no-such-file

Не обязательно. Можно перемещать/уплотнять чанки на лету. А можно и не на лету, а по запросу. В любом случае оверхэд сильно меньше, чем при вставке в сплошной массив.

а если сравнить с простым списком, в котором всего два поля — значение, и указатель на следующий?

Её мало просто из-за маленькой шины в 32 бита, и с этим ты ничего не сделаешь

Про это я ничего не говорил.

не говорил, но IRL такой эффект наблюдается.

Это ломает напрочь кеширование и упреждающее чтение, которое всё равно работает(т.е. пока ты обрабатываешь 9001й блок, процессор параллельно читает 9002й, но тебе нужен будет не он, а 1234й).

Ничего это не ломает. Для управления предвыборкой есть специальные инструкции процессора, но, даже если это не учитывать, кэш работает не так тупо, как ты написал.

не, ну понятно, что я утрировал и преувеличивал, что-бы разъяснить суть явления. Но такое есть IRL. Конечно разница не очень большая, но всё же некоторый эффект есть начиная даже с 512Мб используемой памяти. И с каждым годом это всё сильнее и сильнее. Потому, для десктопов и лаптопов 32х битная архитектура подходит с каждым днём всё хуже и хуже.

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

А по сабжевой теме — я завёл на выходных две абсолютно идентичных виртуалки с Lubuntu, одна — 32бит, другая — 64 бит. Но руки не доходят исследовать софт.

Могу только сказать, что на свежеуствновленной и голой системе Firefox занимает после первого старта в 32 битной 87Мб RSS и 461Мб VIRT, а в 64 бит — 118Мб и 778Мб, соответственно.

http://i.imgur.com/l3pqUWE.jpg

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

Ну незнай, попробуй без мультилиба чоли.

Так, как раз, 64-х битный софт и жрёт-то больше. Хочешь экономии — как раз нужен мультилиб и 32 бита.

Кстати, это может быть ответом, почему Хром под Linux жрёт настолько больше ресурсов, чем под Windows. Под Win x64 он 32-х битный.

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

Слишком сложные непонятные программы

Это Firefox и Хром непонятные? :D Это один из основных инструментов большинства ЛОРовцев сегодня.

Запусти какой-нибудь gzip и посмотри сколько он жрат.

А вот gzip'ом пользуются редко. Тем не менее даже с ним:
http://i.imgur.com/pFX8BKo.png

748k vs 820k.

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

а если сравнить с простым списком, в котором всего два поля — значение, и указатель на следующий?

Возьмём список в котором 3 поля: 2 значения и указатель на следующий чанк. Произвольный доступ в 2 раза быстрее чем по простому списку, памяти жрёт меньше чем простой список (меньше указателей). При вставке перемещать что-либо нужно только в половине случаев, да и то только один элемент.

Потому, для десктопов и лаптопов 32х битная архитектура подходит с каждым днём всё хуже и хуже.

Потому, не потому - не надо ломиться в открытую дверь, само собой, что сегодня 32 бита это мало. Просто объёмы данных в бытовом использовании стали слишком велики для 32 бит.

no-such-file ★★★★★ ()
Ответ на: комментарий от KRoN73

Так, как раз, 64-х битный софт и жрёт-то больше. Хочешь экономии — как раз нужен мультилиб и 32 бита.

экономия на спичках получается. 118-87=31. Когда ты в последний раз видел DRAM на 32Мб?

emulek ()
Ответ на: комментарий от no-such-file

Возьмём список в котором 3 поля: 2 значения и указатель на следующий чанк. Произвольный доступ в 2 раза быстрее чем по простому списку, памяти жрёт меньше чем простой список (меньше указателей). При вставке перемещать что-либо нужно только в половине случаев, да и то только один элемент.

ок. Есть список ({1,2},{3,4},{5,7},{8,9},{10,11}), как вставить 6?

Потому, не потому - не надо ломиться в открытую дверь, само собой, что сегодня 32 бита это мало. Просто объёмы данных в бытовом использовании стали слишком велики для 32 бит.

с этим согласен.

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

({1,2},{3,4},{5,7},{8,9},{10,11}), как вставить 6?

Тут есть два варианта:

({1,2},{3,4},{5,6},{7},{8,9},{10,11}) или ({1,2},{3,4},{5,6},{7,notused},{8,9},{10,11}) notused выделяется но не используется пока не понадобится вставить что-нибудь между 7 и 8.

no-such-file ★★★★★ ()
Ответ на: комментарий от emulek

В итоге, приложения требующие хотя-бы 500 метров(e.g. браузер), работают заметно быстрее на 64х битах, хотя и жрут намного меньше 4х Гб.

В теории - да, на практике часто - нет.

Firefox 32 работает значительно быстрее, чем Firefox 64. Я про официальную сборку на mozilla.org

thespiritofbirdie ()