LINUX.ORG.RU

32 vs 64


1

1

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

★★★★★

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

> 64 бит регистры вообще были добавлены до кучи

Давай пруфлинк или 4.2

В чём профит 64бит? В длинной адресации? Наверно да, но без неё жить можно.


Бгг. С твоей логикой, и на 16-битных машинах прекрасно живется, а 32 бита не нужны.

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

>Бгг, ну да, там как раз написано, что 16-разрядных АЛУ достаточно. %)
Так и есть, достаточно даже 16-разрядных. Думаешь интел просто так сделала внутри 16-разрядные алу?

64 бит регистры вообще были добавлены до кучи


Давай пруфлинк или 4.2

Пруф выше, если даже 16-разрядных достаточно, то что говорить о 64-разрядных.

Бгг. С твоей логикой, и на 16-битных машинах прекрасно живется, а 32 бита не нужны.

Кое-где даже на 8-битных жили нормально.

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

> Думаешь интел просто так сделала внутри 16-разрядные алу?

Во-первых, 16-разрядные АЛУ в pentium-4 выполняют лишь простейшие арифметические операции: сложение, вычитание и некоторые побитовые. Для умножения и деления никаких 16 бит нет.

Во-вторых, 16-ти разрядные АЛУ pentium-4, чтобы не сильно терять в производительности относительно традиционных 32-битных, вынуждены работать на удвоенной (!) частоте. В результате АЛУ pentium-4 являются самой тепловыделяющей точкой кристалла, и именно они ограничивают частотный потенциал.

Подробнее про АЛУ можешь прочитать здесь: http://www.fcenter.ru/online.shtml?articles/hardware/processors/11289 . А безграмотный высер с xakep.ru про «содержит меньше транзисторов, выделяет меньше тепла и лучше работает на повышенной тактовой частоте» лучше затолкай автору этого высера в то самое место.

Ты сослался на авторитет Интел - объясни тогда, почему Интел добавила в SSE2 64-бит целочисленную арифметику. «Просто так»? :D

64 бит регистры вообще были добавлены до кучи


Давай пруфлинк или 4.2


Пруф выше, если даже 16-разрядных достаточно, то что говорить о 64-разрядных.


Выше вместо пруфа ты привел какую-то бредятину. С какого бодуна ты решил, что у инженеров АМД в голове такой же понос, как у редакции xakep.ru?

Кое-где даже на 8-битных жили нормально.


Ну, тюринг-полнота, конечно, не теряется. Жизнь-на-костылях.

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

> Не спорю что 64, 128, 256, ... бит хорошо, но нужность и профит экспонециально уменьшаются.

Нужность определяется объемом и характером данных, с которым нужно работать. Например, образ dvd-диска в 32-бит адресное пространство не помещается (невозможно сделать mmap на файл целиком, и работать с ним дальше как с обычным массивом).

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

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

>Нужность определяется объемом и характером данных, с которым нужно работать. Например, образ dvd-диска в 32-бит адресное пространство не помещается (невозможно сделать mmap на файл целиком, и работать с ним дальше как с обычным массивом).
Для чего? Для того чтобы был нехилый своп? Ну нет у меня столько памяти.

Ты сослался на авторитет Интел - объясни тогда, почему Интел добавила в SSE2 64-бит целочисленную арифметику. «Просто так»? :D

В SSE2-то профита поболее, так как можно параллелить. Хотя и тут скорее всего применение довольно узко.

Где и для чего нужна целочисленная арифметика? В цикле от 0 до 100 элементов? Сложить 5 бананов и 2 яблока? Уж про то, что где-то надо поделить или умножить, это вообще по пальцам пересчитать. Где-то оно конечно надо, но где? Архитектура ALU это как пример того, что где-то проводились исследования и на их основе что-то было сделано, а не пример последней инстанции.

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

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

Моё мнение, что 64бит регистры нужны для адресации, но никак не для арифметики. Без надобности в адресации никто-бы не стал их городить.

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

> Моё мнение, что 64бит регистры нужны для адресации, но никак не для арифметики. Без надобности в адресации никто-бы не стал их городить.

GPR есть GPR, адресация или арифметика - не играет никакой роли.

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

> Для чего?

Для того, чтобы упростить программу.

Для того чтобы был нехилый своп?


В отсвопливании нуждаются только модифицированные страницы.

Ну нет у меня столько памяти.


Для работы с образом dvd как с массивом, столько памяти и не нужно. А вообще сейчас даже ноутбуки продаются с 6 Гб ОЗУ на борту.

В SSE2-то профита поболее, так как можно параллелить.


Ну да, 128-ми битные регистры, по два целочисленных 64-битных операнда в каждом. Это в sse2. Вот и рассказывай про ненужность 64-бит арифметики.

Уж про то, что где-то надо поделить или умножить, это вообще по пальцам пересчитать.


Попробуй без умножения проиндексировать массив с размером элемента, не являющимся степенью 2.

Моё мнение, что 64бит регистры нужны для адресации, но никак не для арифметики.


Э-ээ, интересно, а как должна выглядеть адресация _без_ арифметики?

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

>>GPR есть GPR, адресация или арифметика - не играет никакой роли.

Да, но не надо писать что из-за этого какой-то профит.

Почему не надо? Профит есть. Кодировщики работют быстрее.

Просто поддержка 64 режима.

Есть 64-бит DSP, на которых >4Г памяти нет и не планировалось.

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

>Для работы с образом dvd как с массивом, столько памяти и не нужно. А вообще сейчас даже ноутбуки продаются с 6 Гб ОЗУ на борту.
Даёшь гарантии что отсвопления не будет? У кого-то всего 512 метров и что?

Ну да, 128-ми битные регистры, по два целочисленных 64-битных операнда в каждом. Это в sse2. Вот и рассказывай про ненужность 64-бит арифметики.

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

Попробуй без умножения проиндексировать массив с размером элемента, не являющимся степенью 2.

Э-ээ, интересно, а как должна выглядеть адресация _без_ арифметики?


Чегой? array[0], не?




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

> Даёшь гарантии что отсвопления не будет? У кого-то всего 512 метров и что?

А у кого-то и вовсе 256 метров. И кде4 загоняет его машину в своп. А кде с LiveCD умирает от OOM-киллера. И что, по твоей логике кде теперь не место на десктопе? :D

Чегой? array[0], не?


Ты не понял. Пусть sizeof(A)==1030, нужно обратиться к i-тому элементу массива из элеметов типа A. Напиши код на ассемблере, который делает это без умножения.

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

>Возможно, для кого-то и мало.
Реально для чего? Тут уже пробегали темы вроде - «чем мне заполнить мои гигабайты?». На всяких вислах я ещё могу понять, там минимальные требования по-сути от 2 гигов. Опять же всякие крайзисы. И то далеко не факт.

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

>Ты не понял. Пусть sizeof(A)==1030, нужно обратиться к i-тому элементу массива из элеметов типа A. Напиши код на ассемблере, который делает это без умножения.
Согласен, но не согласен, что это обязательно нужно делать на 32битах. Да и произвольный доступ как правило это не слишком частая операция, а при последовательном можно и сложением обойтись.

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

>>Почему не надо? Профит есть. Кодировщики работают быстрее.

Не будут ли они быстрее работать на SSE?

Целочисленные - нет.

Да, и что за кодировщики которые работают с 64бит?

Ыыы, да ты походу не читал обсуждаемую страницу. Все кодировщики - от bzip2 до flac.

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

> Согласен

Итого ты согласен, что для адресации нужна арифметика, в том числе умножение?

не согласен, что это обязательно нужно делать на 32битах


Это уже зависит от размера массива.

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


Некоторые структуры данных опираются на произвольный доступ. Хэш-таблицы - это редкость по-твоему? :)

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

>Gentoo/Arch/Slackware в качестве контрпримеров

А какие проблемы в Gentoo с 32-битными библиотеками? Как раз там все работает, причем даже без компиляции.

P. S. довольный пользователь 64-битной генты вот уже около 5 лет.

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

>Итого ты согласен, что для адресации нужна арифметика, в том числе умножение?
Согласен, но она нужна далеко не всегда. И никакого преимущества тут перед 32 битами не будет.

Некоторые структуры данных опираются на произвольный доступ. Хэш-таблицы - это редкость по-твоему? :)

Нужно. Так вроде всё логично, арифметика нужна, но нужна она для поддержания соответствующей адресации. Сама по себе, для каких-то других вычислений она малополезна.

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

>Суть в том, что 64-бит адресация без 64-бит арифметики - это крайне криво. Почти что бессмысленно.
Согласен, признаю что погорячился с ненужностью оного. Но профита всё равно с фигу, что то там реально ускорить оно не может.

Не всегда.

Как так? Не встречал такого.

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

Компиляторы быстрее не стали


Ну, если кривые opensource компиляторы не получают выигрыш, то нормальный javac от 64-бит получает выигрыш в 2,25 согласно SPECjvm2008. Просто авторам gcc нужно качать скиллы :)

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

Есть программка

64 bit (-O3):

$ file ./bin/test_chafe
./bin/test_chafe: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

$ ldd ./bin/test_chafe
        linux-vdso.so.1 =>  (0x00007fff51b98000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb55c240000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fb55bfbe000)
        libgomp.so.1 => /usr/lib64/libgomp.so.1 (0x00007fb55bdb1000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb55bb9b000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb55b980000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fb55b622000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fb55c54b000)
        librt.so.1 => /lib64/librt.so.1 (0x00007fb55b41a000)

$ ./bin/test_chafe test_schafe -f ../sf5.txt -d -t 1
#loading mesh ...
#done ...
#preparing mesh ...
#done ...
#points -- 10242
#inner points -- 10241
#outer points -- 1
#triangles -- 20480
using double
elapsed: 5.786547

32 (-O3 -msse2 -fpmath=sse):

$ file ./bin/test_chafe
./bin/test_chafe: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

$ ldd ./bin/test_chafe
        linux-gate.so.1 =>  (0xffffe000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf7662000)
        libm.so.6 => /lib/libm.so.6 (0xf763a000)
        libgomp.so.1 => /usr/lib/libgomp.so.1 (0xf762c000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf760f000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xf75f4000)
        libc.so.6 => /lib/libc.so.6 (0xf7493000)
        /lib/ld-linux.so.2 (0xf7778000)
        librt.so.1 => /lib/librt.so.1 (0xf7489000)

$ ./bin/test_chafe test_schafe -f ../sf5.txt -d -t
1
#loading mesh ...
#done ...
#preparing mesh ...
#done ...
#points -- 10242
#inner points -- 10241
#outer points -- 1
#triangles -- 20480
using double
elapsed: 23.928634

32 bit (-O3)

$ ./bin/test_chafe test_schafe -f ../sf5.txt -d -t 1
#loading mesh ...
#done ...
#preparing mesh ...
#done ...
#points -- 10242
#inner points -- 10241
#outer points -- 1
#triangles -- 20480
using double
elapsed: 59.165753

Разница существенна.

Стал я разбираться в чем дело и оказалось, что без sse тормозит

inline double
ipow (double x, int p)
{
        int i;
        double r = 1;
        for (i = 0; i < p; i++)
        {
                r *= x;
        }
        return r;
}

Запускается эта штука очень много раз и всегда с p от 0 до 4, поэтому «умное» умножение только замедляет алгоритм.

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

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

Тьфу, про off_t я и спрашивал. А то поддержка позиционирования в файлах с размером >2Гб как-то через одно место в 32-битных реализована (хоть и работает, если эти define'ы сделать).

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

Ты запусти вот это в цикле и удивись

inline double 
ipow (double x, int p) 
{ 
        int i; 
        double r = 1; 
        for (i = 0; i < p; i++) 
        { 
                r *= x; 
        } 
        return r; 
} 

Без sse оно работает в 8 раз медленней. sse на 64х битах включено по-умолчанию.

Возможно, что остальная разница вылазит из-за libm, который на 32х битах по-умолчанию использует fpu, а не sse. Да можно конечно генту использовать и собрать всё с -mfpmath=sse и возможно получим те же 5 секунд, что и на 64х битной системе, но это уже задротство.

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

>Ты запусти вот это в цикле и удивись

Да можно конечно генту использовать и собрать всё с -mfpmath=sse и возможно получим те же 5 секунд, что и на 64х битной системе, но это уже задротство.

Кому как, генту как раз по мне именно за оптимизацию под целевую платформу. Это не сравнение архитектур.

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

Кроме fpmath'а есть еще работа с uint64_t и большими объемами памяти, тут тебе никакие флаги не помогут.

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

Это вопросы не только производительности, но и удобства.

Reset ★★★★★ ()

А вот человек решает практическую типичную задачу, разбор html, http://www.rsdn.ru/forum/decl/3772687.flat.aspx или что еще хуже, текста. Неужели при увеличении количества правил для разбора «Существует набор правил в виде регулярных выражений, которые и определяют содержимое этой строки. Правил может быть много, и они могут добавляться со временем» 64-битный режим с его дополнительными регистрами не даст выигрыша?

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

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

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

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

немного не в тему, но в мире есть достаточно много 32битных процов (пень 4, целероны последних лет) с поддержкой sse2 и даже 3. Выходит, что задротство с -mfpmath=sse может иметь применение

annulen ★★★★★ ()