LINUX.ORG.RU

32 vs 64


1

1

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

★★★★★

В дебиане и убунте очень удобно сделано. Т.е. у меня 64битный дистрибутив, но я без вообще каких либо проблем запускаю 32битные приложения, после установки пакета которое оно попросило. Т.е. скайпы, флеши, даже эмулятор сони плейстейшн 2 который хардкорно под 32бит онли. Плюс например MainActor даже работает, единственный внятный видеоредактор под линукс (проприетарный ибо). Все это без каких либо плясок с бубном.

Разве в остальных дистрах это сложнее ?

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

Кодировщики и расчетные задачи не предлагать.


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

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

>> Кодировщики и расчетные задачи не предлагать.

да все задачи если их правильно реализовать будут на 64бит быстрее

Компиляторы быстрее не стали, полагаю, что то же и с браузерами. Ссылок на тесты воспроизведения видео в LOR Wiki нет.

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

>Доктор, покажите мне _класс нагрузок_, которые выигрывают от 64-битности хотя бы 10% производительности. Кодировщики и расчетные задачи не предлагать.

Это уже клиника. 64 бит выруливает там где много математики. В энкодерах и расчетах её больше всего. man amd64.

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

>то же и с браузерами

32 битный ФФ выдает на peacekeeper чуть меньше баллов, чем 64 битный, на том же процессоре, тут была тема где мерились производительностью

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

>>Доктор, покажите мне _класс нагрузок_, которые выигрывают от 64-битности хотя бы 10% производительности. Кодировщики и расчетные задачи не предлагать.

Это уже клиника.

Доктор, по-моему, вы купили диплом в подземном переходе. И кстати, у вас волчанка^Wдислексия.

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

> 32 битный ФФ выдает на peacekeeper чуть меньше баллов, чем 64 битный, на том же процессоре

О чем и речь. Так где профит? Кодировщики и расчетные задачи мне не интересны.

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

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

Видео сейчас аппаратно декодят, через видеокарту.
Браузеры - хз, я хром использую, он как то летает так быстро что трудно понять где быстрее %-)

Тут был топик тоже очередной про 64бит, там был линк на фороникс, если тебе интересно - поищи, недавно это было, там можно посмотреть где в каких задачах какая ситуация. Хотя я думаю тут просто все. Если софтина оптимизирована под 64бит и новые инструкции процессоров - будет быстрее, а большинство софта на 64бит просто пересобирают, видимо, сейчас, а компиляторы тоже наверное только начали оптимизировать что бы они сами собирали в 64бит качественные бинари. Но процесс идет, и уже сейчас 64бит зачастую быстрее. На серверах там, или в видеомонтаже/графике сложной, поэтому я смысла не вижу ставить на 64бит систему 32бит дистр, поскольку писал выше - обратная совместимость в дебиан базед дистрах замечательная, получаем профиты 64битной системы + совместимость с 32бит бинарниками

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

Кста, про браузеры, по идее 64бит должно быть быстрее при очень интенсивной работе через ssl (шифрование типа ушустряется сильно на 64бит). Наверное и VPN должно быстрее работать, потом вот тебе пример из жизни - торренты, клиенты считают MD5 огромных файлов + DC++ тоже, ну и так если подумать то наверное много набежит того о чем забыли

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

> Код gcc должен по идее шустрей выдавать за счёт большего количества регистров.

Ээ... генерируемый код должен быть быстрее? Это от задачи зависит, для кодировщиков он и правда значительно быстрее, но _мне_ это не интересно. А сам компилятор работает с той же скоростью или даже чуть медленнее, если верить LOR Wiki :)

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

>Ээ... генерируемый код должен быть быстрее? Это от задачи зависит, для кодировщиков он и правда значительно быстрее, но _мне_ это не интересно.

Ну тупо регистровые переменные по идее самые шустрые, а регистров у x86 традиционно было сильно меньше, чем у нормальных процессоров.

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

>сам компилятор работает с той же скоростью или даже чуть медленнее, если верить LOR Wiki :)

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

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

> пруф мне найти будет достаточно тяжело, просто попадался тест какой-то уровня вороникса, у них скорость компиляции была ниже на 64 бит системе по сравнению с 32 битной.

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

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

в принципе вот, оценочный тест на атоме

openssh 5.4p1 / GCC 4.4.4-svn-redhat

32 bit: (и 32 битный GCC)
real 0m54.840s
user 1m28.955s
sys 0m8.861s


64 bit: (и 64 битный GCC)

real 1m5.706s
user 1m46.649s
sys 0m11.664s


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

Sylvia ★★★★★ ()

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

Прирост производительности колеблется от 0.6% до 45% (Сравнение производительности 32-битной и 64-битной версий дистрибутивов Fedora 9, OpenSUSE 11.0, Ubuntu 8.04.1)


использованию SSE2 взамен инструкций fp-сопроцессора x87


У меня на этих дистрах был нехилый прирост просто от перересборки ядра под целевой процессор. В общем этот бенчмарк тут не совсем корректен.

увеличенному количеству процессорных регистров amd64 по сравнению с IA-32 (уменьшается так называемый «register pressure», компилятор порождает меньше операций spill/fill);

Использование памяти ещё не означает падения производительности, на это у процессоров есть кеш.

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

Короче, если не сервер, не суперкомп и нет какой-то реальной необходимости в 64битном-онли ПО, слазить с 32х бит не надо.

Обычный ноутбук, ArchLinux x86_64 only, ЧЯДНТ?

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

Для обычных программ да, а вот числодробильня ускоряется существенно больше чем на 5%. Да и большие объемы данных можно сразу засасывать в память mmap'ом и не изобретать читалку.

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

>Для обычных программ да, а вот числодробильня ускоряется существенно больше чем на 5%.
Отчего такой профит? Как говорится пруф в студию.

Да и большие объемы данных можно сразу засасывать в память mmap'ом и не изобретать читалку.

Это да. По моей информации именно размер виртуальной памяти и послужил точком для amd64, а не что-либо другое.

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

>GCC будет всегда использовать (как минимум) SSE2 на amd64,
Спасибо не знал, но немного странно. Кстати писать, что sse уделывает fpu тоже не совсем правильно. Там где можно векторизовать/распараллелить, то да.

Booster ★★ ()

Да и то это спорный вопрос, зависит от железяк. У amd всегда был мощный fpu, на самом деле даже несколько fpu с возможностью параллельной работы.

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

Ээ... генерируемый код должен быть быстрее? Это от задачи зависит, для кодировщиков он и правда значительно быстрее, но _мне_ это не интересно.

SBCL на 64-х битах быстрее работает :)

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

> Надо использовать нормальный дистрибутив, который предоставляет полный комплект 32'х битных библиотек.

Да, об этом и речь. Было бы желательно видеть эту формулировку на вики, с Мандривой и Федорой (?) в качестве примеров, Debian/Ubuntu в качестве «середнячка» и Gentoo/Arch/Slackware в качестве контрпримеров.

P.S. Как я уже сказал, я пользуюсь Gentoo с multilib overlay, который как раз дает возможность указать, от каких именно пакетов нужна 32-битная сборка в дополнение к 64-битной.

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

Значит пока буду сидеть на 32. Память более 4 гиг на линукс декстопе не слишком нужна, а в производительность amd64 я не верю, пруфов никто не привёл. Под целевой процессор на генте и так всегда собирается.

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

> О чем и речь. Так где профит? Кодировщики и расчетные задачи мне не интересны.

А полустодвадцативосьмибитная жабка не быстрее? Если да, то профит тебе в затмении явный должен быть.

Lumi ★★★★★ ()

Когда люди забудут наконец эту чушь про «увеличенное число регистров»? Везде давно есть register renaming, и количество *архитектурных* регистров не так важно.

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

Когда люди забудут наконец эту чушь про «увеличенное число регистров»? Везде давно есть register renaming, и количество *архитектурных* регистров не так важно.

У людей, пишущих код с использованием регистров, того самого ренейминга нет.

mv ★★★★★ ()