LINUX.ORG.RU

32 vs 64


1

1

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

★★★★★

Вот у меня, например Maverick x64. И всё отлично идёт. Ведь 64-битная система поддерживает и 32-битные приложения. К примеру драйвер на WiFi у меня 32 бита. Так что 64-битная более универсальна, так как поддерживает 64 и 32 бита, а 32-битная только 32. Она ни чем не лучше, просто универсальнее.

tesla-nt ()

Еще один вариант есть с 64 разрядными системами. Вот буквально только что дособирал себе. Суть создаем chroot с чисто 32разядным окруженим, монтируем туда dev, proc и прочие tmp.

Особый плюс — после того как 32битная программа перестала быть нужна можно просто прибить папочку c окружением. ну или иметь несколько окружений.

А еще меньше проблем с дровами, они все 64 разрядные как и иксы. Если развить идею,то можно устроить хитрый гибрид из 64 разрядных иксов (во избежания проблем с дроавми и плюс производительности) и 32 битным частичным юзерспейсом.

Вобщем имею рабочий цхрут с 32битной гентой в 64битной. задавайте ваши вопросы.

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

> Суть создаем chroot с чисто 32разядным окруженим, монтируем туда dev, proc и прочие tmp.

Тоже так сделал. Ещё /home тоже туда прибиндил. Основную систему сделал no-multilib. На деле вышло, что чрутом и не пользуюсь :) Но на всякий случай держу.

const86 ★★★★★ ()
Ответ на: комментарий от tesla-nt

>Так что 64-битная более универсальна, так как поддерживает 64 и 32 бита, а 32-битная только 32

Вообще-то это фича ядра, можешь в любом 32-битном дистре поставить 64-битный самосбор, и будет тебе счастье:)

annulen ★★★★★ ()

Стоило бы больше написать про source-based дистрибутивы ведь там всё несколько меняется в плане производительности. На моей nocona, например, преимущества от long mode сводятся на нет увеличениями размера кеша (если собирать с -march=native). На intel core ix всё кардинально склоняется в другую сторону

Elemir ()

везде перелез на 64 бита, до этого не давал флешь, теперь даже под винду 64х разрядный вышел, 8 гигов очень довольны. да и архиваторы вроде бы стали работать шустрее.

druganddrop-2 ★★ ()

Зависимость от скорости доступа к ОЗУ...

Немного специфичный вопрос по производительности...

Какая будет разница в работе с памятью на 32 и 64 битных архитектурах?

Где то читал, что на 32 битах вроде как быстрее доступ, чем на 64, т.к. размер регистра меньше. Соответственно будет выйгрыш в программах которые часто обращаются к памяти. Интересно какие это могут быть программы.

P.S. Пытался гуглить на эту тему, но ничего не обнаружил, думаю что возможно этот вопрос неактуален ввиду того что собственный кэш процессора полностью компенсирует этот недостаток, т.е. большинство приложений не используют частый доступ к памяти большего размера чем кэш процессоров?

Osceola ()
Ответ на: Зависимость от скорости доступа к ОЗУ... от Osceola

>Где то читал, что на 32 битах вроде как быстрее доступ, чем на 64, т.к. размер регистра меньше.

Прекращай нести бред, услышанный от однокласников.

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

«Не обнаружил» потому, что этот бред - это чисто ваш школьный фолклёр

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

+_+ |~LOL~| +_+

Где то читал, что на 32 битах вроде как быстрее доступ, чем на 64, т.к. размер регистра меньше.

Прекращай нести бред, услышанный от однокласников.

Твой бред прекратит только модератор. Или бригада медиков. Или обои :D

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

«Не обнаружил» потому, что этот бред - это чисто ваш школьный фолклёр

Как раз таки в этой теме про мой вопрос есть конкретная ссылка на вики где в общих чертах описана как раз именна эта проблема. Так что получается что «чисто ваш школьный фолклёр» - http://www.linux.org.ru/wiki/en/32_или_64_бита - это текст автора темы с количеством постов под сотню и полугодом обсуждения. Я в этом сильно сомневаюсь... Если тут есть технически грамотные люди в этом вопросе, то думаю эту статейку на вики можно дополнить.

Osceola ()
Ответ на: Зависимость от скорости доступа к ОЗУ... от Osceola

>Где то читал, что на 32 битах вроде как быстрее доступ, чем на 64, т.к. размер регистра меньше. Соответственно будет выйгрыш в программах которые часто обращаются к памяти. Интересно какие это могут быть программы.

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

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

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

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

Потому что у меня Ос Windows и на вики как бы получается не то написано для меня Прирост производительности колеблется от 0.6% до 45% (Сравнение производительности 32-битной и 64-битной версий дистрибутивов Fedora 9, OpenSUSE 11.0, Ubuntu 8.04.1). Возникает благодаря: увеличенному количеству процессорных регистров amd64 по сравнению с IA-32 (уменьшается так называемый «register pressure», компилятор порождает меньше операций spill/fill); использованию SSE2 взамен инструкций fp-сопроцессора x87 (The resulting code should be considerably faster in the majority of cases and avoid the numerical instability problems of 387 code ... This is the default choice for the x86-64 compiler.); улучшенному ABI (выравнивание fp-переменных, «red zone»).

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

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

4+Gb + больше регистров + больше разрядность как правило и дают те самые %% где на это рассчитывают (операции с большими числами/мультимедиа), в целом переход на любом более-менее современном железе на 64-битную ОС оправдан

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

:D

Вообще последние новшества в сфере IT напоминают мне эволюцию динозавров - тупиковый путь просто увеличивать объёмы и для этого мощности. Щас есть условия для нормальной работы любых приложений (для обычных пользователей) без увеличения оперативки или физической памяти на hdd. Однако складывается такое ощущение что всем охота поскорее забить как можно больше памяти и смотреть как это всё подтормаживает.

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

Да и вообще мировая информационная наука в тупике. С времён изобретения транзистора ничего принципиально нового нет. Только размеры элементов уменьшаются.

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

>хто на 32 мешает этому? о_О
Здравый смысл. Использование mfpmath=sse на x86 не бесплатно и может привести к падению производительности если у тебя не числодробилка (хотя с числодробилкой всё это часто пофиг, поскольку там идут другие оптимизации).
А ещё mfpmath=sse требует изменения ABI для нормальной работы. На x86-64 проблем с этим, естественно, нет.
Да-да, я знаю, что у тебя всё работает.

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

скорее вопрос совместимости с древними процессорами без sse2, у 64 битных у всех есть sse2, поэтому и используется

32 битные есть с sse (не совсем еще разложившиеся amd),
с недо-sse (без регистров) GeodeLX, и вообще без sse

для нормальной математики нужен sse2, хотя лучше sse3

-mstackrealign теперь включен по умолчанию с gcc 4.5, да и раньше оно к проблемам производительности особенно не приводило, с стабильноcтью - да, бывало.

с avx можно будет использовать только половинки от половины YMM регистров, так что x86 понемножку закапывают

Sylvia ★★★★★ ()

Linux Debian x64

Тред читал не полностью. Раньше был Debian 32. Но как только установил FreeBSD x64 - сборка ядра показала 1,5 раза прирост скорости.
Незадумываясь, поставил Debian amd64 - При запуске и работе с обычным офисом[OpenOffice] - уже визуально заметил более быструю работу.
После этого - только 64-битные версии дистрибутивов устанавливал.

xwicked ★★ ()
Ответ на: Re: Linux Debian x64 от xwicked

Re: Linux Debian x64

Если учесть, что ядро пишут нормальные программисты, то скорость компиляции - показатель. А так код коду рознь, первый вариант моей программки под 64бит вообще не собирался. В общем-то, он и сейчас собирается через дырочку для рабства - ну не программист я, что уж тут поделаешь.

anonymous ()
Ответ на: Re: Linux Debian x64 от CTAPK

Формулировка

Ну, если не сформулировали правильно - то действительно Ваш пост был лишний :)
Я объясняю знающим и понимающим людям - остальным в ясли :)

xwicked ★★ ()
Ответ на: Re: Формулировка от CTAPK

Комп

Железо у всех разное - правильно, программы используемые тоже разные - не всегда, но тоже правильно.
Я не говорил, что летает.
Поработаете год с одним(32) и год с другим(64) - будете понимать о чём я говорю. Потом над собой посмеётесь :)

xwicked ★★ ()