32 vs 64
Часто задают вопрос о том, какой вариант конкретного дистрибутива выбрать — 32-битный или 64-битный. Для того, чтобы облегчить выбор, в FAQ помещена статья на эту тему: www.linux.org.ru/wiki/en/32_или_64_бита Материал будет расширяться и дополняться. Свободные обсуждения — в этом топике.
В теории — да, на практике часто — нет. Firefox 32 работает значительно быстрее, чем Firefox 64. Я про официальную сборку на mozilla.org
я тоже про неё, и если разница и есть, то на глаз её не видно. Естественно я про Linux (в венде говорят не так), к тому же про нативные 32 бита. И к тому же на нативном железе, а не на эмуляторе.
поскольку — статья ориентирована что бы помочь с выбором 32bit или всё таки 64bit
Я бы добавил в заключении — дабы не смущать пользователей которым трудно во всё написанное вникнуть и окончательно определиться с выбором —
Что то вроде такого:
Linux 32bit(X86) прекрасно видит и работает с опер.памятью свыше 4 Гб(в отличии от виндовс). И если Вы не имеете конкретных задач(то бишь не пишете свой 64bit софт, не используете особые программы нуждающиеся именно в 64bit архитектуре). То остановитесь на 32bit(X86) Linux — в будущем будете иметь значительно меньше проблем с установкой сторонних программ, игр, драйверов для вашего ПК.
Не сомневайтесь 32bit(X86)Linux будет выжимать все соки из вашего железа, все ваши 4 (8, 16 и т.д.) ядер процессора и все 8 (16, 32)Гб оперативной памяти будут использоваться на 100%. Ни чего не будет висеть мёртвым грузом, была бы нужда 😉
То остановитесь на 32bit(X86) Linux — в будущем будете иметь значительно меньше проблем с установкой сторонних программ, игр, драйверов для вашего ПК.
фишка в том, что конечно установка 32 на 64 имеет некоторые(незначительные, кстати) проблемы, установка 64 на 32 невозможна AFAIK.
Не сомневайтесь 32bit(X86)Linux будет выжимать все соки из вашего железа, все ваши 4 (8, 16 и т.д.) ядер процессора и все 8 (16, 32)Гб оперативной памяти будут использоваться на 100%. Ни чего не будет висеть мёртвым грузом
висеть не будет. Будет работать наполовину.
Бред — а вот то что не будут задействованы 64 битные инструкции процессора это да.. Но дело в том что по мимо их ещё есть и другие которые так же без хозны и производителями внесены(оставлены) для совместимости.
Чтож поделать 🙂 Нам смертным юзерам не предоставляют выбор с каким набором возможностей покупать ЦП, что там нам надо а что нет :))) Бери что есть.
Бред — а вот то что не будут задействованы 64 битные инструкции процессора это да
64х битная виртуальная память тоже не будет задействована. Код будет оптимизирован под i486, максимум i586.
Но дело в том что по мимо их ещё есть и другие которые так же без хозны и производителями внесены(оставлены) для совместимости.
процессоры изначально с микрокодом внутри. Т.е. лишние команды не мешают, и не требуют аппаратного оверхеда. Только места в таблице кодов, а она сейчас большая.
Чтож поделать 🙂 Нам смертным юзерам не предоставляют выбор с каким набором возможностей покупать ЦП, что там нам надо а что нет :))) Бери что есть.
мы можем использовать нативные возможности. мы можем использовать легаси режим совместимости. Да, решать вам. Я уже решил.
Код будет оптимизирован под i486, максимум i586.
64Bit, а под 32 бит фигню вроде win софта по вайном можно и в виртуалке запускать.
не забывай, что не у всех гента. Патрег так вообще ядро не так давно собирал под i80486 🙂 Вот пруф: http://mirror.yandex.ru/slackware/slackware-13.37/slackware/a/ В других дистрах(пакетных, которые штабильные) тоже такая ерунда.
а, ну бинарный ад на то и ад.
В газенваген, быстра б.
Давайте посритесь с баттей, это будет забавно со стороны :3
Есть у кого опыт успешно жизнеподдержания 64-битной системы на 1гб оперативки? Достался недавно древний ноут с амд турион х2, ставить 64 бита как-то страшно. Понятно, что гнома и кеды туда ставить не буду, но все равно.
Есть у кого опыт успешно жизнеподдержания 64-битной системы на 1гб оперативки?
Slackware64-current на iPentium4+1500Mb. Не хуже, чем 32.
Добавлю туда, пожалуй, памяти еще хотя бы гиг, а потом можно и 64 будет поставить.
добавь. У меня там было 512, я добавил гиг(года 2 назад), стало 1.5, нормально работает, не сильно хуже компа, который я жене в том году собрал, об апгрейде не думаю пока, разве что туда SSD купить планирую.
imho: переходить на 64 бит вроде бы только начали. серверная винда только в последнем релизе на 1 архитектуре 64. дистрибутивы по умолчанию на сайтах только начали вывешиваться в 64 битной версии.
Ты откуда вылезло, чудо?
Здесь явно ошибка. Должно быть
Я вот перечитал все что возможно и так и не понял — будет ли 32 разрядная программа которая знает про PAE режим работать в режиме совместимости на 64 битном окружении (64 битное ядро +32+64 битные библиотеки) .Поясняю вопрос ,программы которые написаны с учетом PAE могут выходить за пределы 3 гиг на приложение ,через костыли но тем не менее работает .И что с режимом PSE 36 ,с ним хоть что то работает ,или эта фича оказалась некому не нужна ?
x86 и лишняя планка 2Gb, в сумме с которой будет 4Gb. Все это живет на EP35-DS3 под руководством C2D E8400.
Ядро собрано так:
Я правильно понимаю, что возможны следующие варианты:
1) Выкинуть лишние 2Gb и спокойно провести выходные
2) Собрать ядро с CONFIG_HIGHMEM64G=y и довольствоваться 3.6 — 3.8Gb, а так же жжением в области поясницы от снижения производительности на 0,000001% из-за PAE
3) Собрать ядро с CONFIG_HIGHMEM64G=y и пересобрать мир с ACCEPT_KEYWORDS=«
amd64» (или правильно «
Я думаю самый оптимальный — 2-й вариант, 3-й вообще возможен?
В тутошней вики написано, что C2D могут потерять в скорости в 64-битном режиме.
программы которые написаны с учетом PAE
снижения производительности на 0,000001% из-за PAE
Ядро x86_64, всё остальное оставить как есть.
Ядро x86_64, всё остальное оставить как есть.
Почитай статью из OP.
Собрал с CONFIG_HIGHMEM64G=y, видно все 4Гб. Без него 3.5
Жжение не такое сильное, как я ожидал. Теперь хотя бы игорь целиком в память помещается и не обращается к свопу. 🙂
Скорее всего PAE у тебя и так был включён.
Не могут они выходить за 3 с чем-то гиг на приложение (если там не 100 разных процессов(не путать с потоками)) 😉 PAE даёт возможность использовать больше 4 Гб на 32-ух битном железе, но при этом на 1 процесс не может выделяться больше 3 с чем-то гигабайт.
Четыре, при нормальном размере страниц, остальное дело ОС.
PAE даёт возможность использовать больше 4 Гб на 32-ух битном железе, >но при этом на 1 процесс не может выделяться больше 3 с чем-то >гигабайт.
Можно выходить за пределы 4 Гб на приложение ,правда это будет через э «ж..у » страничная обработка ,самое главное чтобы ось поддерживала этот режим и приложение тоже могло работать в этом режиме .Только негде не поесняется как это делается -фокусы с обработкой страниц ,как допустим организовали режим совместимости в стандарте Vesa или комбинацией PAE+PSE 36 .
PS:
Не пойму почему некоторые программы не работают в режиме PAE ,например kubuntu-devel-release-upgrade вылетает на ровном месте ,вроде бы не должно нечего ломаться с совместимостью если приложение не знает про режим PAE .
Del me plz motherfucker
Странная попытка «выбора». Покажите мне современное десктопное железо с 32-битным процессором. «Офисные» обрезки не предлагать.
VDS/VPS
Граждане, понимаю, что вопрос, подобный моему, вас всех уже достал, но всё же: собираюсь создать дроплет на digitalocean, беру самый маленький (512Mb, 1CPU), и он по дефолту предлагает x64 ОСь. Но, если я ещё не сошел с ума, для столь маленького дроплета х64 только во вред, хотя с другой стороны, если со временем я буду расширяться, то возможно и дорасту до больших ресурсов. На дроплете планирую разместить сайтик и проксю. Что посоветуете?
CONFIG_HIGHMEM64G это pae а не amd64
программы которые написаны с учетом PAE
64 ставь — летает компьютер.
Ubuntu 14.10 Linux 32-bit vs. 64-bit Performance
Краткий итог: в большинстве случаев выигрыш 64-битной версии в производительности составляет десятки процентов, реже — единицы процентов, в тесте OpenSSL 64 бита быстрее на 437%, в тесте PostMark — в десять раз.
32-bit это какая архитектура? i386, i686, -march=native? Между ними разница может быть существенная.
Это 32-битная убунта. Я не знаю, с какими флагами её собирают.
у бубунты вроде банальный i686
Краткий итог: в большинстве случаев выигрыш 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 был заметно шустрее 🙂
я специально, интереса ради сравнивал работу совершенно идентичных x86 и x86_64 систем на одном железе на примере Lubuntu — вариант x86 был заметно шустрее
И на потенции х86 положительно сказывается, да.
Ну, педобиру, наверное, это виднее. Я как-то разницы не заметил.
интереса ради сравнивал работу совершенно идентичных x86 и x86_64 систем на одном железе на примере Lubuntu — вариант x86 был заметно шустрее 🙂
подтверждаю на Gentoo
Ставить 32-битную систему на 64-битный процессор? Тем более если это не какой-нибудь древний проц, а что-то выпущенное в последние несколько лет? ИМО не нужно
$ 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
Судя по всему, у вас обоих плацебо или днищепроцессоры вроде core2.
В теме не раз отмечали, что вопрос перекодирования, как раз, очевидно тот, где amd64 шустрее. Но это одна из немногих таких задач.
i7 3770 — это днище, да 😀 А совершенно объективные измеряемые параметры потребления памяти — это точно плацебо.
Источник
