Процессорные архитектуры - кто есть ху (Отрезано от Вопрос новичка -> Разбивка дисков,swap и прочее...)

[NickLion]

64 потребляет почти в 2 раза больше памяти на теже задачи, не могу понять в чем эффективность 64 если это не сервер с 8 ГБ оперативы.

Очень зависит от программы, но не 2 раза в любом случае. Эффективность в том, что бинарные дистрибутивы для x86 собираются обычно как i386 (Ubuntu), i586 и в самом оптимистичном случае i686 (openSuSE). Т.е. в самом оптимистичном случае код оптимизирован под процессор Pentium II с набором инструкций MMX и не выше. Для задач обработки видео/аудио это важно. В вычислительных задачах тоже может быть важно.

[yars]

в самом оптимистичном случае i686 (openSuSE). Т.е. в самом оптимистичном случае код оптимизирован под процессор Pentium II с набором инструкций MMX и не выше

Вот как? Однако... Не знал, честно.
PS.

64-разрядная эффективнее будет, ставьте ее.

Я, когда это писал, думал, что эффективность заключается в том, что обработать 64 бита за раз быстрее, чем 32, а теперь вспомнил, что система команд х86-64 - это надмножество х86, а 64 бита за раз процессоры умеют обрабатывать еще с первых "Пентиумов". Так что да, неправда моя

[NickLion]

Ну, 64-х бытные вычисления на 64-х битной архитектуре будут быстрее всё равно. Которые MMX — без разницы, а вот самые обычные быстрее. Как и 128 битные. Правда 64-битная архитектура ещё одно преимущество имеет — увеличенное число регистров.

PS кстати, в первом Pentium не было 64-х бытных вычислений. Они появились только в Pentium MMX. В первом пне только шину увеличили до 64-х бит, что позволило ускорить 64-х битные вычисления (при правильном подходе), но производились они так же в несколько инструкций. Да и MMX не всегда удобны. Например, PADDQ не влияет на флаги, а значит нельзя определить факт переполнения/переноса и реализовать то же 128-битное или длинное сложение на основе этой операции.

[alv]

в самом оптимистичном случае код оптимизирован под процессор Pentium II с набором инструкций MMX и не выше

В общем случае это достаточно: скачок производительности - при установке флага gcc -O march=i686, всё что выше - добавляет обычно копейки. А вот проблем может создать на рубли - почему дистры общего назначения с агрессивной оптимизацией и не собираются. Это - святое право дженедужников
Без иронии - сам таким был.

Для задач обработки видео/аудио это важно.

Да, если зарабатывать на хлеб насущный оцифровкой звука, то есть смысл перебрать, скажем, lame с флагами типа -O3 march=максимально_точное_указание_процессора-из_man_gcc
В иных случаях это рояля не играет. Не говоря уж о том, что многие программы общего назначения при агрессино-мультимединых флагах могут просто не собраться.

Но на самом деле проще всего таки, учитывая, что у Дебиана нет проблемы с поддержкой варианта x86_64, ставить его и пусть вас не волнуют этих глупостей.

[NickLion]

В общем случае это достаточно: скачок производительности - при установке флага gcc -O march=i686, всё что выше - добавляет обычно копейки.

Да, но это в случае openSUSE. А в той же Ubuntu (как и прародителе Debian) используется i386. Значит, не будет даже MMX.

[taaroa]

А в той же Ubuntu (как и прародителе Debian) используется i386. Значит, не будет даже MMX.

даже mmx
mmx
инфа 100%.

проверим?

% ./scripts/analyze-x86.pl /bin/ls
Checking vendor_id string... GenuineIntel
Disassembling /bin/ls, please wait...
i486: 0 i586: 0 ppro: 120 mmx: 95 sse: 82 sse2: 9 sse3: 0 sse4.1: 0 sse4.2: 0
/bin/ls will run on Pentium IV (pentium4) or higher processor.

% ./scripts/analyze-x86.pl `which tar`
Checking vendor_id string... GenuineIntel
Disassembling /bin/tar, please wait...
i486: 0 i586: 0 ppro: 158 mmx: 380 sse: 122 sse2: 81 sse3: 0 sse4.1: 0 sse4.2: 0
/bin/tar will run on Pentium IV (pentium4) or higher processor.

p.s. это^ ubuntu 12.04.

[NickLion]

инфа 100%.

проверим?
...
p.s. это^ ubuntu 12.04.

Если это результаты для 32-битной версии, то значит сами разработчики вводят в заблуждение, указывая i386, хотя получается, что это никакое не i386.

[taaroa]

Если это результаты для 32-битной версии

для amd64.
для i386 tar (tar_1.26-4ubuntu1_i386.deb) результат следующий:
tar will run on Pentium Pro (i686 or pentiumpro) or higher processor.

[NickLion]

для amd64.

Ну, дык это не интересно. 64-х битная версия ясно, что может использовать вплоть до SSE3 (в минимальном наборе). Вопрос был в 32-х битной версии.

для i386 tar (tar_1.26-4ubuntu1_i386.deb) результат следующий:
tar will run on Pentium Pro (i686 or pentiumpro) or higher processor.

А результаты по инструкциям какие?

UPD
Собственно скачал и проверил. Ни одной MMX инструкции. Но инструкции Pentium pro используются, такие как cmov**. Так что это уже не i386, однозначно. В заблуждение вводят.

[alv]

В заблуждение вводят.

Так и есть. Причём давно. Под чистый i386, чтобы его действительно можно было запустить на i386, собирали что-то типа 3-го Дебиана.

[watashiwa_daredeska]

сами разработчики вводят в заблуждение, указывая i386

i386 — исторически слежавшаяся маркировка.

However, Debian GNU/Linux squeeze will not run on 386 or earlier processors. Despite the architecture name "i386", support for actual 80386 processors (and their clones) was dropped with the Sarge (r3.1) release of Debian[2]. (No version of Linux has ever supported the 286 or earlier chips in the series.) All i486 and later processors are still supported[3].

http://www.debian.org/releases/stable/i386...tml.en#id583669

[alv]

support for actual 80386 processors (and their clones) was dropped with the Sarge (r3.1) release of Debian

Где-то так. Debian 3.0 на антикварной настоящей трёшке запустить ещё можно было. Всё, что позднее - уже нет.
А вот FreeBSD 5.x ещё запускалась - если удавалось воткнуть 6 Мбайт памяти для sysinstall'а - конечно, не 6, а 8, иначе не получалось, симки на 386DX надо было ставить в банк по 4.
Самое смешное, что после установки на 4 Мбайт работала.
Позднее уже не проверял.
Да и музейной трёщки не стало

[NickLion]

В заблуждение вводят.

Так и есть. Причём давно. Под чистый i386, чтобы его действительно можно было запустить на i386, собирали что-то типа 3-го Дебиана.

i386 — исторически слежавшаяся маркировка.

Странная логика. Ну, обозначили бы x86 — не конкретная архитектура, а семейство. Было бы логичнее.

PS посмотрел на openSUSE там тоже i586 в основном. С i686 собираются только какие-то выборочные пакеты, да Packman под "i586" собирает с поддержкой SSE (тоже вводя в заблуждение).

Так что правильно, что я давно перешёл на x86_64

[drBatty]

Странная логика. Ну, обозначили бы x86

дык историческая. что поделать? воспринимайте как географические названия, или как название утилиты grep.

[taaroa]

Странная логика. Ну, обозначили бы x86 — не конкретная архитектура, а семейство. Было бы логичнее.

возможно, но оно не только у.
http://ftp6.ru.freebsd.org/pub/FreeBSD/
http://ftp.eu.openbsd.org/pub/OpenBSD/5.1/
ftp://iso.netbsd.org/pub/NetBSD/iso/5.1.2/
http://www.oracle.com/technetwork/server-s...oads/index.html

[NickLion]

taaroa
Oracle Solaris как раз x86 использует.
Остальные — да, i386, но может они никого и не обманывают и действиельно собраны под i386?

[Gineaser]

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

[watashiwa_daredeska]

Странная логика. Ну, обозначили бы x86 — не конкретная архитектура, а семейство. Было бы логичнее.

Ага, и сломало бы обновление всем, кто поставил i386. Например, мне — ведь я прозрачно обновлялся woody → sarge → etch. Сменить архитектуру при обновлении — задача нетривиальная. Чтобы без проблем сработало у всех, нужно либо зеркально собирать, хранить и поддерживать (лет 10 как минимум) две архитектуры, которые ничем, кроме названия не отличаются, либо вкручивать одноразовые костыли в APT/DPkg, чтобы можно было обновляться с i386 на x86. Ну нафиг. Кому надо и так прекрасно знают или прочитают.

Так что правильно, что я давно перешёл на x86_64

Ай, у Debian и этого нет. Есть amd64. :)

[NickLion]

Ага, и сломало бы обновление всем, кто поставил i386. Например, мне — ведь я прозрачно обновлялся woody → sarge → etch. Сменить архитектуру при обновлении — задача нетривиальная. Чтобы без проблем сработало у всех, нужно либо зеркально собирать, хранить и поддерживать (лет 10 как минимум) две архитектуры, которые ничем, кроме названия не отличаются, либо вкручивать одноразовые костыли в APT/DPkg, чтобы можно было обновляться с i386 на x86. Ну нафиг.

И всё же правильнее было один раз поставить отдельную маленькую тулзеньку по обновлению с i386 на x86. С инструкциями.

Кому надо и так прекрасно знают или прочитают.

А я не буду долго выискивать что да как. Если написана конкретная архитектура, значит собрана под неё. Заметьте на странице скачивания Debian нет ни слова, под какую архитектуру в реальности собирается i386, ни одного уточнения.

Так что правильно, что я давно перешёл на x86_64

Ай, у Debian и этого нет. Есть amd64.

Тут нет претензий, это в общем-то одно и то же, одни так называют, другие иначе. amd64/x86_64 — это не конкретная архитектура.

[Ism]

Почемуто забыли про sse http://ru.wikipedia.org/wiki/SSE , а грамотно оптимизированная под низ программа может работать в разы быстрее, да и OpenCL наступает. , поэтому нужно не собирать под архитектуру , а смотреть возможности программы задействовать способы ускорения вычислений
Например flash без sse становится дохлой клячей

[NickLion]

Почемуто забыли про sse http://ru.wikipedia.org/wiki/SSE , а грамотно оптимизированная под низ программа может работать в разы быстрее

Как раз не забыли, говорили уже. Большинство стандартных 32-х битных версий дистров собираются без их поддержки — как видим, ни Ubuntu, ни openSuSE не поддерживают в 32-х битном режиме даже MMX, не говоря уже о SSE, SSE2, SSE3. А в 64-битной архтектуре гарантирована поддержка до SSE3 включительно. Под вопросом остаются только более старшие: SSSE3, SSE4.1, SSE4.2, AVX и т.д.

[Ism]

Как раз не забыли, говорили уже. Большинство стандартных 32-х битных версий дистров собираются без их поддержки — как видим, ни Ubuntu, ни openSuSE не поддерживают в 32-х битном режиме даже MMX, не говоря уже о SSE, SSE2, SSE3. А в 64-битной архтектуре гарантирована поддержка до SSE3 включительно. Под вопросом остаются только более старшие: SSSE3, SSE4.1, SSE4.2, AVX и т.д.

Дело в том, что программа должна сама проверять и решать включать sse или нет , вне зависимости от вариантов компиляции, иначе новейшие технологии задействуются очень нескоро тупо потому, что некто не включил флаг компиляции
Хотя данный вопрос не совсем ясен, можно ли в код i386 включить процедуры sse вне зависимости от флагов компиляции

[alv]

грамотно оптимизированная под низ программа может работать в разы быстрее

Да не может. Лет 10 назад, когда я серьёзно занимался этим вопросом, то получал массу гневных писем: типа я пересобрал lame/mencoder/нужное_дописать и получил нев...ероятный выигрышь в производительности. Да вот только ни одной цифири об этой производительности не было.
А у меня были. И это было около 10% выигрыша для мультимедийных приложений. При риске, что другие приложения с такими флагами просто не соберутся. Или будут тормозить нипадецки - с march=P4 именно так и было.
С тех пор процессоры стали избыточно мощными для любых пользовательских задач, и на этом фоне любые ухищрения по оптимизации, просто теряются.

данный вопрос не совсем ясен, можно ли в код i386 включить процедуры sse вне зависимости от флагов компиляции

Данный вопрос много лет назад был исчерпывающе прояснён в руководстве по gcc (под редакцией RMS), в разделе о флагах компиляции: там всё расписано, какие флаги от каких зависят, какие при каких включаются и так далее.

[NickLion]

Дело в том, что программа должна сама проверять и решать включать sse или нет , вне зависимости от вариантов компиляции

Нет. Это путь распространения бинарников. Там по-другому нельзя. В мире open source просто можно перекомпилировать с поддержкой всех фич текущего процессора. Зачем усложнять программу run-time проверками?

дистрибутив чего?

Дистрибутив не обязательно должен быть дистрибутивом чего-то, кроме того, чем он является. Это просто форма распространения (что и означает импортное distribute). Так что "дистрибутив openSuSE" (ибо названия "дистрибутив Linux", "дистрибутив GNU/Linux" одинаково неверные). Который содержит ядро "Linux", окружение "GNU", сервер графического режима "Xorg", фреймворк "Qt4" десктопное окружение "KDE SC 4", и т.д.

[NickLion]

грамотно оптимизированная под низ программа может работать в разы быстрее

Да не может. Лет 10 назад, когда я серьёзно занимался этим вопросом, то получал массу гневных писем: типа я пересобрал lame/mencoder/нужное_дописать и получил нев...ероятный выигрышь в производительности. Да вот только ни одной цифири об этой производительности не было.

При грамотном использовании MMX, SSEx могут значительно увеличить производительность. Но не в разы, конечно, если не о синтетических тестах говорим. Подвох в том, что компилятор gcc (не знаю как интелловский) может прооптимизировать сишный код с использованием этих инструкций далеко не всегда. Поэтому, чтобы получить выигрыш в скорости приходится писать несколько реализаций под различные флаги компиляции. Не всегда это делают. Плюс, как показывает практика, основную часть выигрыша дают MMX.

[alv]

При грамотном использовании MMX, SSEx могут значительно увеличить производительность.

Это "значительно" - в лучшем случае 10%. Если Вы не зарабатываете на хлеб насущный оцифровкой аудио- или видеозаписей в промышленных масштабах, очень важно, оцифруется файл за один час или за 54 минуты? Ведь всё равно это делается в фоне.

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

Я думаю, что это не делают никогда, разве что создатель Mplayer'а и mencoder'а чем-то подобным развлекался, почему и был категорически против распространения своих программ в бинарниках.
И плюс к этому разные программы придётся перебирать каждую со своими флагами. А это занятие даже не для дженедужника, а для продолжателя дела Великого Герхарда, доведёного до логического абсурда.

[NickLion]

openSUSE - это способ комплектации, установки и распространения именно Линукса.

Не соглашусь. openSuSE — это установка не только Linux, не только GNU, а и ещё всякого добра. Поэтому нельзя сказать, что это является формой распространения чего-то конкретно. Просто укомплектованный набор ПО под названием openSuSE.

Это "значительно" - в лучшем случае 10%. Если Вы не зарабатываете на хлеб насущный оцифровкой аудио- или видеозаписей в промышленных масштабах, очень важно, оцифруется файл за один час или за 54 минуты? Ведь всё равно это делается в фоне.

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

Я думаю, что это не делают никогда, разве что создатель Mplayer'а и mencoder'а чем-то подобным развлекался, почему и был категорически против распространения своих программ в бинарниках.

Делают. x264, ffmpeg, например, содержат оптимизации под разные процессоры (не только x86 архитектуры).

[Ism]

Нет. Это путь распространения бинарников. Там по-другому нельзя. В мире open source просто можно перекомпилировать с поддержкой всех фич текущего процессора. Зачем усложнять программу run-time проверками?

Типов процов много и чтоб задействовать всю мощность , то поможет только run-time проверка , тогда программа сама будет знать на что способен проц и нагрузить его по полной
А перекомпиляция - удел немногих , только несколько раз пересобирал программу и то для поиграться

[drBatty]

Как раз не забыли, говорили уже. Большинство стандартных 32-х битных версий дистров собираются без их поддержки — как видим, ни Ubuntu, ни openSuSE не поддерживают в 32-х битном режиме даже MMX, не говоря уже о SSE

ВНЕЗАПНО: а оно надо? Если надо, то зачем?

При грамотном использовании MMX, SSEx могут значительно увеличить производительность.

производительность ЧЕГО????!!11

А перекомпиляция - удел немногих , только несколько раз пересобирал программу и то для поиграться

а я уже вижу, что вы никогда не смотрели видео на первом пне. Тогда это было критично. Сейчас - нет. Потому программы можно собирать даже под 80486 дырка-то в другом месте... Проверяйте сами, гента вам в руки...

[Ism]

При грамотном использовании MMX, SSEx могут значительно увеличить производительность.

производительность ЧЕГО????!!11

Математических вычислений

А вообще что, может ограничимся командами i386 и Математический сопроцессор выкинуть ?

Похоже вы старовер