LINUX.ORG.RU

32 vs 64


1

0

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

★★★★★

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

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

я тоже про неё, и если разница и есть, то на глаз её не видно. Естественно я про Linux (в венде говорят не так), к тому же про нативные 32 бита. И к тому же на нативном железе, а не на эмуляторе.

emulek ()

поскольку - статья ориентирована что бы помочь с выбором 32bit или всё таки 64bit

Я бы добавил в заключении - дабы не смущать пользователей которым трудно во всё написанное вникнуть и окончательно определиться с выбором -
Что то вроде такого:
Linux 32bit(X86) прекрасно видит и работает с опер.памятью свыше 4 Гб(в отличии от виндовс). И если Вы не имеете конкретных задач(то бишь не пишете свой 64bit софт, не используете особые программы нуждающиеся именно в 64bit архитектуре). То остановитесь на 32bit(X86) Linux - в будущем будете иметь значительно меньше проблем с установкой сторонних программ, игр, драйверов для вашего ПК.

Не сомневайтесь 32bit(X86)Linux будет выжимать все соки из вашего железа, все ваши 4 (8, 16 и т.д.) ядер процессора и все 8 (16, 32)Гб оперативной памяти будут использоваться на 100%. Ни чего не будет висеть мёртвым грузом, была бы нужда ;)

beta9092 ()

То остановитесь на 32bit(X86) Linux - в будущем будете иметь значительно меньше проблем с установкой сторонних программ, игр, драйверов для вашего ПК.

фишка в том, что конечно установка 32 на 64 имеет некоторые(незначительные, кстати) проблемы, установка 64 на 32 невозможна AFAIK.

Не сомневайтесь 32bit(X86)Linux будет выжимать все соки из вашего железа, все ваши 4 (8, 16 и т.д.) ядер процессора и все 8 (16, 32)Гб оперативной памяти будут использоваться на 100%. Ни чего не будет висеть мёртвым грузом

висеть не будет. Будет работать наполовину.

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

Будет работать наполовину.



Бред - а вот то что не будут задействованы 64 битные инструкции процессора это да.. Но дело в том что по мимо их ещё есть и другие которые так же без хозны и производителями внесены(оставлены) для совместимости.

Чтож поделать :) Нам смертным юзерам не предоставляют выбор с каким набором возможностей покупать ЦП, что там нам надо а что нет :))) Бери что есть.

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

Бред - а вот то что не будут задействованы 64 битные инструкции процессора это да

64х битная виртуальная память тоже не будет задействована. Код будет оптимизирован под i486, максимум i586.

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

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

Чтож поделать :) Нам смертным юзерам не предоставляют выбор с каким набором возможностей покупать ЦП, что там нам надо а что нет :))) Бери что есть.

мы можем использовать нативные возможности. мы можем использовать легаси режим совместимости. Да, решать вам. Я уже решил.

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

щито!? о_О

не забывай, что не у всех гента. Патрег так вообще ядро не так давно собирал под i80486 :) Вот пруф: http://mirror.yandex.ru/slackware/slackware-13.37/slackware/a/ В других дистрах(пакетных, которые штабильные) тоже такая ерунда.

emulek ()

Есть у кого опыт успешно жизнеподдержания 64-битной системы на 1гб оперативки? Достался недавно древний ноут с амд турион х2, ставить 64 бита как-то страшно. Понятно, что гнома и кеды туда ставить не буду, но все равно.

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

добавь. У меня там было 512, я добавил гиг(года 2 назад), стало 1.5, нормально работает, не сильно хуже компа, который я жене в том году собрал, об апгрейде не думаю пока, разве что туда SSD купить планирую.

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

imho: переходить на 64 бит вроде бы только начали. серверная винда только в последнем релизе на 1 архитектуре 64. дистрибутивы по умолчанию на сайтах только начали вывешиваться в 64 битной версии.

parker ()

Я вот перечитал все что возможно и так и не понял - будет ли 32 разрядная программа которая знает про PAE режим работать в режиме совместимости на 64 битном окружении (64 битное ядро +32+64 битные библиотеки) .Поясняю вопрос ,программы которые написаны с учетом PAE могут выходить за пределы 3 гиг на приложение ,через костыли но тем не менее работает .И что с режимом PSE 36 ,с ним хоть что то работает ,или эта фича оказалась некому не нужна ?

maximnik0 ★★ ()

Есть Gentoo ~x86 и лишняя планка 2Gb, в сумме с которой будет 4Gb. Все это живет на EP35-DS3 под руководством C2D E8400.
Ядро собрано так:

# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y 


Я правильно понимаю, что возможны следующие варианты:
1) Выкинуть лишние 2Gb и спокойно провести выходные
2) Собрать ядро с CONFIG_HIGHMEM64G=y и довольствоваться 3.6 - 3.8Gb, а так же жжением в области поясницы от снижения производительности на 0,000001% из-за PAE
3) Собрать ядро с CONFIG_HIGHMEM64G=y и пересобрать мир с ACCEPT_KEYWORDS=«~amd64» (или правильно «~x86_64»?)


Я думаю самый оптимальный - 2-й вариант, 3-й вообще возможен?

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

А ты оптимист!

Собрал с CONFIG_HIGHMEM64G=y, видно все 4Гб. Без него 3.5

Жжение не такое сильное, как я ожидал. Теперь хотя бы игорь целиком в память помещается и не обращается к свопу. :)

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

Не могут они выходить за 3 с чем-то гиг на приложение (если там не 100 разных процессов(не путать с потоками)) ;) PAE даёт возможность использовать больше 4 Гб на 32-ух битном железе, но при этом на 1 процесс не может выделяться больше 3 с чем-то гигабайт.

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

PAE даёт возможность использовать больше 4 Гб на 32-ух битном железе, >но при этом на 1 процесс не может выделяться больше 3 с чем-то >гигабайт.

Можно выходить за пределы 4 Гб на приложение ,правда это будет через э «ж..у » страничная обработка ,самое главное чтобы ось поддерживала этот режим и приложение тоже могло работать в этом режиме .Только негде не поесняется как это делается -фокусы с обработкой страниц ,как допустим организовали режим совместимости в стандарте Vesa или комбинацией PAE+PSE 36 .

PS:
Не пойму почему некоторые программы не работают в режиме PAE ,например kubuntu-devel-release-upgrade вылетает на ровном месте ,вроде бы не должно нечего ломаться с совместимостью если приложение не знает про режим PAE .

maximnik0 ★★ ()

Странная попытка «выбора». Покажите мне современное десктопное железо с 32-битным процессором. «Офисные» обрезки не предлагать.

anonymous ()

VDS/VPS

Граждане, понимаю, что вопрос, подобный моему, вас всех уже достал, но всё же: собираюсь создать дроплет на digitalocean, беру самый маленький (512Mb, 1CPU), и он по дефолту предлагает x64 ОСь. Но, если я ещё не сошел с ума, для столь маленького дроплета х64 только во вред, хотя с другой стороны, если со временем я буду расширяться, то возможно и дорасту до больших ресурсов. На дроплете планирую разместить сайтик и проксю. Что посоветуете?

Strannik-j ()

Ubuntu 14.10 Linux 32-bit vs. 64-bit Performance

http://www.phoronix.com/scan.php?page=article&item=ubuntu_1410_32v64&...

Краткий итог: в большинстве случаев выигрыш 64-битной версии в производительности составляет десятки процентов, реже - единицы процентов, в тесте OpenSSL 64 бита быстрее на 437%, в тесте PostMark - в десять раз.

pedobear ()
Ответ на: Ubuntu 14.10 Linux 32-bit vs. 64-bit Performance от pedobear

Краткий итог: в большинстве случаев выигрыш 64-битной версии в производительности составляет десятки процентов

Мало того, что Фороникс, так ещё и испорченный телефон. Тесты по порядку:
— Flexible IO = +9.3%
— PostMark = в 10 раз(!?)
— Tesseract = +1%
— Xonotic = +0.1%
— FFTE = +30%
— Jhon The Ripper = +13%
— VP8 lipvpx encoding = +10%
— Graphics Magic = +22%
— Himeno = +0.7%
— Kernel Compilation = -0.9%

И так далее. То есть в тех случаях, где происходит массовая обработка числовой информации, что не удивительно, x86_64 оказывается быстрее. Только обычно не на «десятки», а не «десяток-два» процентов. В остальных случаях выигрыш близок к нулю.

На практике же вопросы кодирования всплывают не так часто, а рост потребления памяти (в некоторых случаях, типа Гуглохрома просто катастрофический, до 3..4 раз!) даже снижает эффективность работы системы в целом.

И, да, я специально, интереса ради сравнивал работу совершенно идентичных x86 и x86_64 систем на одном железе на примере Lubuntu — вариант x86 был заметно шустрее :)

KRoN73 ★★★★★ ()
Последнее исправление: KRoN73 (всего исправлений: 1)
Ответ на: комментарий от KRoN73

я специально, интереса ради сравнивал работу совершенно идентичных x86 и x86_64 систем на одном железе на примере Lubuntu — вариант x86 был заметно шустрее

И на потенции х86 положительно сказывается, да.

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

интереса ради сравнивал работу совершенно идентичных x86 и x86_64 систем на одном железе на примере Lubuntu — вариант x86 был заметно шустрее :)

подтверждаю на Gentoo

armbox ()

Ставить 32-битную систему на 64-битный процессор? Тем более если это не какой-нибудь древний проц, а что-то выпущенное в последние несколько лет? ИМО не нужно

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

$ for i in 1 2 3;do time ./flac32 --best --stdout /dev/shm/test.wav &>/dev/null ;done |& grep ^real
real 0m1.800s
real 0m1.811s
real 0m1.800s

$ for i in 1 2 3;do time ./flac64 --best --stdout /dev/shm/test.wav &>/dev/null ;done |& grep ^real
real 0m1.488s
real 0m1.478s
real 0m1.477s

Собрано с

CFLAGS='-pipe -march=native -O2' CXXFLAGS='-pipe -march=native -O2' ../flac-1.3.1/configure --disable-shared --enable-static

nvidia ()