LINUX.ORG.RU

32 vs 64


1

1

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

★★★★★

при оперативной памяти ноутбука 2Gb есть смысл использовать 64 bit с или лучше 32 bit linux mint 14 mate ?

так как довольно сильно тормозит и linux , и windows 64 битные .

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

Я в линуксе полный новичок,как - то неудобно указывать на ошибки.Всё же скажу.64 бита хороши для многопоточных параллельных вычислений,при большой нагрузке на процесс.Работа с RAW изображениями,на каждый файл приходится иногда меньше указателей в 2*32,чем размер файла,и HD видеомонтаж.Скалярные вычисления.При чём здесь размер файла(приходилось обьяснять когда-то) и общее количество оперативки,если дома никто подобными вещами не занимается,а те,кому действительно нужны подобные перделки,это очень малое количество домашних пользователей.Проблема будет тогда,когда буфер начнёт переполняться во время выполнения типичных задач,это просмотр видео или работа с текстурами и фото,видео идёт кусками и если во время обработки файл будет забивать память,то будут тоооооооооооооорррррррррммммоооооооооозззззззааааааааааааааааааааааааааааа...................Предела скорости ,при которой память будет заполняться быстрей,чем процессор 32 бита,не сможет её обрабатывать,ещё не достигли Помидорами не кидаться

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

Я уже много лет сижу на x86_64 Linux-е и серьезные проблемы мне так и не встретились, особенно в Ubuntu 12.04+ - оно сразу multiarch и можно ставить/запускать пакеты только для 32-бит без проблем

I-Love-Microsoft ★★★★★ ()

есть бук с 8 гигами памяти стоит ubuntu 12.04 x32 оставить так или все же поставить x32_64? или подскажите другой способ дабы не очень хочется переставлять

fallout4all ★★★★★ ()

от оперативки зависит

на VPS хостингах и мобильных носимых устройствах, где оператива в дефиците в пределах 4 гиг - 32 бита выгоднее

остальное 64, потому что под 32 даже ZFS нормальной нету и чтобы не было 100500 отличий сервера от рабочей станции по пакетам и функционалу/глюкам

sanyock ★★ ()

Кстати, не подскажите такой вопрос? Правда ли, что на 32 битную систему можно поставить 64 битный VirtualBOX и устанавливать в нём 64 битные гостевые ОС?

PS: У меня несколько систем для разных нужд, но основная всё же 64 битная винда 7. Необходима была именно такая конфигурация т.к. занимался видеомонтажём и использовал Adobe Premiere (который исключительно 64-битный)

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

Хм... Я тут подумал, а если на компе стоит 32 битная система которая не видит больше 4 Гб ОЗУ, а по факту памяти установлено больше.

Можно ли в программах типа виртуал-бокса использовать невидимую для системы память для работы гостевых ОС?

Мне это кажется весьма сомнительным (Ведь именно основная ОС выделяет ресурсы для виртуал-бокса), но всё же вдруг это как-то возможно?

Было бы весьма полезно. Т.к. на работе стоят компы с лицензионной 32 битной виндой и нужно поставить виртуальные машины с линуксом для некоторых специфических задач.

Hemulo ()

у тебя в статье так и не появился список задач, которым так уж нужны больше 4Гб на один процесс.

Также у тебя не появился список дистрибутивов32 без PAE, за исключением WinXP.

А вот интересно было-бы, ибо в своей статье, ты так говоришь, как будто-бы эти списки не пустые.

ЗЫЖ про рандомизацию адресного пространства — посмеялся. Так и представляю хакера, который один из 4х миллиардов байтов силой мысли выбирает, а вот на 64х битах — не осиливает ☺

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

Можно ли в программах типа виртуал-бокса использовать невидимую для системы память для работы гостевых ОС?

с 1995го года все процессоры умеют PAE. Вопрос потому довольно странный.

на работе стоят компы с лицензионной 32 битной виндой

а… тогда на винфак. Думаю No Way.

drBatty ★★ ()

Небольшое наблюдение

32 бита

до:

             total       used       free     shared    buffers     cached
Mem:          1991       1672        319          0         14        316
-/+ buffers/cache:       1341        650
Swap:         1506        286       1220

okular some-big-book.pdf

             total       used       free     shared    buffers     cached
Mem:          1991       1876        115          0          2        570
-/+ buffers/cache:       1304        687
Swap:         1506        439       1066

закрыли okular

             total       used       free     shared    buffers     cached
Mem:          1991       1479        512          0          2        192
-/+ buffers/cache:       1285        706
Swap:         1506        420       1085

64 бита

до:

             total       used       free     shared    buffers     cached
Mem:          1877       1780         97          0         29        358
-/+ buffers/cache:       1391        486
Swap:         2384        774       1609

okular some-big-book.pdf

             total       used       free     shared    buffers     cached
Mem:          1877       1796         81          0         20        322
-/+ buffers/cache:       1452        425
Swap:         2384        781       1603

закрыли okular

             total       used       free     shared    buffers     cached
Mem:          1877       1730        147          0         21        322
-/+ buffers/cache:       1386        491
Swap:         2384        781       1603

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

А зря. Иначе бы увидел, что проблема нехватки виртуального адресного пространства начинается гораздо раньше увеличения физического адресного пространства до 4Г и проявляет себя уже при наличии всего 2Г физической памяти.

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

Иначе бы увидел, что проблема нехватки виртуального адресного пространства начинается гораздо раньше увеличения физического адресного пространства до 4Г и проявляет себя уже при наличии всего 2Г физической памяти.

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

В общем и целом, для большинства приложений, и если памяти больше 1Гб, то примерно то на то и выходит. Очевидных преимуществ сегодня нет ни у 32х бит, ни у 64х.

С другой стороны, переходить всё равно придётся.

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

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

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

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

Товарищ идиот не в курсе, что указатели обрабатываются в адресных регистрах

ты уверен, что указатели никогда этих регистров не покидают, и что все указатели там и лежат? У меня для тебя плохие новости: есть только одна структура данных, для которой это так, это примитивный линейный массив. Во _всех_ остальных структурах данных приходится хранить указатели в памяти. Возьми к примеру любую СУБД, как ты думаешь, что такое «индекс БД»? Ага, многие сотни и тысячи миллионов указателей. ИЧСХ, в отличие от данных, 80% которых почти никогда не нужны, индекс нужен _весь_, и именно в памяти.

Вдвое дольше адреса будут обрабатываться только в софтовой эмуляции.

если у тебя есть два указателя в регистрах, и тебе их надо сложить, то очевидно, время сложения будет одинаковым, хоть они 8 бит, хоть 128. Проблема в том, что скажем для самого примитивного списка, у тебя в регистре лежит лишь адрес головы, и что-бы получить пятый эл-т, тебе надо прочитать пять указателей, ИЧСХ, этот процесс в принципе не кешируется (если список не лезет в кеш целиком конечно. А он не лезет, ибо кому интересно при 2Гб памяти обрабатывать списки в 4Мб?).

Если ты думаешь, что СУБД не нужны, обрати внимаение на СУБД из FireFox, Nepomuk, или всю венду возьми, с её реестром, который, внезапно, тоже СУБД.

drBatty ★★ ()

вставлю и свои пять копеек.

джва года назад ставил Arch Linux х86_64 и таки ужаснулся, что памяти съелось в полтора-два раза больше обычного. решил сидеть пока на i686.

недавно собрал LFS х86_64. памяти съедает столько же, сколько Arch Linux i686, а то и меньше. потому что нет не нужных мне не используемых библиотек.

так-то. и все зависит от дистрибутива.

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

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

джва года назад ставил Arch Linux х86_64 и таки ужаснулся, что памяти съелось в полтора-два раза больше обычного.

что ты удивляешься, если там удвоенный набор библиотек? (но начиная с гигабайта RAM это не имеет значения)

Не ставь мультилиб, и всё будет работать (кроме зондов типа скайпа конечно)

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

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

Более детально с данной тематикой можете ознакомиться в википедии.

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

Если вкратце, первым 64-биный проц придумали в Intel

А персональный компьютер изобрели в Microsoft.

Не надо нести бред. IA64 появился гораздо позже 64битных MIPSов.

x86-64 имеет с IA-64 столько же общего, сколько с 64битными MIPSами.

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

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

ЗЫ: кажется, ситуация с поддержкой софтом [ur=Не собирается Telegram messenger CLI]изменяется на противоположную. Ну и абсолютное большинство десктопов на онтопике давно 64битные.

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

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

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

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

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

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

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

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

PS: drBatty не читает уведомления. Не может. По решению голосования модераторов.

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

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

По моему первый внятный аргумент

по твоему это всем надо?

emulek ()