32 vs 64

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

/0

Ну не у всех главная работа десктопа - смотреть fullhd аниме :-P

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

а у тебя гента что ли ? зачем тебе компилятор что бы быстрее работал ?

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

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

> а у тебя гента что ли ?

Debian

зачем тебе компилятор что бы быстрее работал ?

ВНЕЗАПНО, на LOR есть программисты :)

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

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

Ты по кухонному таймеру замеряешь время? Оно заметно. Тебя никто на amd64 силком не тащит.

> Ты по кухонному таймеру замеряешь время?

Доктор, примите уже успокоительное, у вас бред начинается. Перед пациентами же неудобно.

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

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

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

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, а атом это очень особенный процессор, для достоверности, хорошо бы потестировать сборку чего-нибудь побольше и на нормальном процессоре типа корки

>При сборке пакетов не используются возможности новых процессоров такие, как 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);

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

emt64 обязательно включает sse2? Впервые такое слышу.

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

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

А ты и не залезал :}}

Как проходила сборка, тестирование?

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

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

Например, в Мандриве можно поставить поставить 32х битную версию ЛЮБОЙ библиотеки, а всё потому, что нет идиотизма с ia32-libs как в бубунтах.

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

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

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

> Отчего такой профит?

В ссылке в первом сообщение написано

Как говорится пруф в студию.

кодом поделиться не могу

GCC будет всегда использовать (как минимум) SSE2 на amd64,
отключается -mno-sse*

>В ссылке в первом сообщение написано
На заборе тоже много чего написано.

Не только в sse дело.

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

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

допишите уже про таки увеличенное адресное пространство и mmap. Главный плюс же

emt64 обязательно включает sse2? Впервые такое слышу.

Уши чистить надо.

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

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

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

Ну всё, уболтал.

>Уши чистить надо.
Как обычно хамим?

Как обычно хамим?

Что вы! Только взываем к разуму. Подобная информация ищется за две минуты на любой википедии.

>Что вы! Только взываем к разуму. Подобная информация ищется за две минуты на любой википедии.
Признаю, профан.

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

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

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

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

С 32-мя меньше всего проблем. Преимущество 64-х еще не раскрыто на 100%.

Оно раскроется когда 4 гига оперативы будет мало, пока не особо нужно.

> с Мандривой и Федорой (?) в качестве примеров,

да, Федора подходит

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

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

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

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

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