32 vs 64

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

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

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

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

> По-моему достаточно объективно. ^)

Бгг, ну да, там как раз написано, что 16-разрядных АЛУ достаточно. %)

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

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

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

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

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

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

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

> Думаешь интел просто так сделала внутри 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-битных жили нормально.

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

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

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

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

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

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

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

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

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

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

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

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

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

>GPR есть GPR, адресация или арифметика - не играет никакой роли.
Да, но не надо писать что из-за этого какой-то профит. Просто поддержка 64 режима.

http://www.linux.org.ru/jump-message.jsp?msgid=4785800&cid=4792182

А что для деcктопа 4 гига таки мало?

> Для чего?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>Почему не надо? Профит есть. Кодировщики работают быстрее.
Не будут ли они быстрее работать на SSE? Да, и что за кодировщики которые работают с 64бит?

Возможно, для кого-то и мало.

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

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

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

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

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

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

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

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

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

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

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

>Целочисленные - нет.
Почему?

> Согласен

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

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

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

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

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

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

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

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

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

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

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

Кста, хеш таблицы выровнены по степени 2. А тут уже можно передавать команде множитель.

> никакого преимущества тут перед 32 битами не будет.

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

> Кста, хеш таблицы выровнены по степени 2.

Не всегда.

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

Не всегда.

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

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

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

Почему?

Если моя память мне ни с кем не изменяет, SSE - набор команд для плавающей арифметики.

Про SSE я общно выразился, во второй версии целочисленные имеются.

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

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

>Ну, если кривые opensource компиляторы не получают выигрыш, то нормальный javac от 64-бит получает выигрыш в 2,25 согласно SPECjvm2008
А может 32-бит версия гогно? ^)

> PAE можно поддержать как со стороны ос, так и со стороны приложений.

это по процессам по 2 гига чтоль бить? а жопа не треснет ?

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

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х бит умудриться надо найти.

Считается что javac тупой как 2 копейки, он же ничего не оптимизирует, поэтому и гогном считаться не может

А в 64-битной системе size_t «из коробки» 64-битный, или все равно придется в шапке каждый раз писать

#define _FILE_OFFSET_BITS 64
#define _LARGEFILE64_SOURCE

64'х битный, естественно. и off_t 64'х битный. _FILE_OFFSET_BITS 64 _LARGEFILE64_SOURCE влияют на off_t, а не на size_t

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

>нормальный javac от 64-бит получает выигрыш в 2,25 согласно SPECjvm2008
Где можно посмотреть?

>Разница существенна.
Ничего не понятно. SSE не в кассу, остальное не раскрыто.

Запусти SPECjvm2008 под 32 и под 64, сравни.

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

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х битной системе, но это уже задротство.

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

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

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

>Запусти SPECjvm2008 под 32 и под 64, сравни.
Сравнить пока не могу. Небось снова собрано фиг знает с какими флагами.

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

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

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

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

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

> Кэш это те же регистры

Занавес.

>Занавес
Ты в театре?

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

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