ой какие вы далекие люди от ассемблера...

смешно читать...

Хотя есть умные мысли. В основном про количество регистров в x86. А про ширину регистров - такой бред...

пока читал, появились новые сообщения. Появились умные мысли про ширину. ключевое слово - сопроцессор. Для тех кто не знает - у сопроцессора регистра 80-битные. Начиная с 8087.

>Прально, ибо везде пеарят AMD64. Юзеры покупают с ним компы и
>на всю мощь используют возможности процессора по эмуляции
>32-битного режима.

Вы где живете? Я не видел рекламы от АМД, везде крутят от
Intel....

>Ибо венды нормальной под AMD64 так и нет. С драйверами
>проблемы хуже чем у Solaris 10 x86 :))

Как это нет? WinXP 64 вышла пол года назад, а Win2003 64
еще раньше, но вот с драйверами беда. Под Linux'ом нет
таких проблем, все практически поддерживается, даже
USB ADSL модемы....

>>> х86_64 - старое название

>>x86_64 - НОВОЕ название

>Есть сайт amd.com, есть сайт amd.ru - зайди и убедись

Ок, я был не совсем прав, постоянно где-то переименовывают одно в другое, например https://bugs.eclipse.org/bugs/show_bug.cgi?id=81722

>>> Просто аппаратная поддержка скажем 2^40, или 2^64 степени будет работать существенно быстрее чем програмная эмуляция.

>>Аппаратная поддержка чего??

>Доступное адрессное пространсво порядка 2^(40+еще что то)

Может я докапываюсь к словам, но для меня "аппаратная поддержка 2^40 степени" и "адресное пространство 2^40 байт" - разные вещи.

> И уж если говорить о 64 битах, то сами по себе 64 бита на десктопе нифига не дадут.

+1

$ uname -srmpio
Linux 2.6.14-gentoo-r5 i686 AMD Athlon(tm) 64 Processor 2800+ AuthenticAMD GNU/Linux

т.е. на десктопе в конце концов перешёл на под i686, т.к. прироста скорости практически нет, а проблем с amd64 немного, но больше.

>Вы где живете? Я не видел рекламы от АМД, везде крутят от Intel....

AMD просто грамотнее поступает. Когда приходишгь в любой компьютерный магазин, там всё завалено буклетами про немерянную круть amd64 :)

На AMD64 есть порт микроядра L4. Для Itanium такого порта нет.

<Может я докапываюсь к словам, но для меня "аппаратная поддержка 2^40 степени" и "адресное пространство 2^40 байт" - разные вещи.>

Опять таки, 2^40 это не доступное виртульное адрессное пространво, которое равно 2^64, а доступное физическое адрессное пространство, так что это логично считать аппаратной поддержкой. Если не согласен, тогда просто скажи как ты хочешь их отделять.

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

>На AMD64 есть порт микроядра L4. Для Itanium такого порта нет.

Это самый реальный аргумент :), побежал покупать Итаниум.

> 1970 + число секунд, которое помещается в time_t. Проблема какого года?

2038-ого.

Ага.

http://pw2.netcom.com/~rogermw/Y2038.html

Да при кодировании видео (и аудио, возможно, точно не знаю)
при матем. преобразованиях используется множество тригонометрии...
Но как было сказано, дела это "сопроцессорные", вот и ни при чем здесь эти 64 бита.

>Если бы кто-нибудь из вас читал архитектуру itanium'а, то вы бы долго еще плевались от amd64

to dmitrmax А вот я сейчас портирую свою систему на Itanium (SGI Altix) и ни как не пойму, а надо ли это? Использую MEncoder, GraphicsMagic, Java5.0 MySQL/PostgreSQL. Но ни кто не может мне подсказать, какие реальные преимущества я получу, кроме маркетинговых, по сравнению с Opteron решениями?

>Кстати, Microsoft уже давно заявила, что они сворачивают винду на итанике. Поэтому линукс - это единственное, что его теперь поддерживает

А как же хпукс ? :-)

Чпуск нервно курит в сторонке. :)))

Чпукс, конечно же поддерживает Итаны. И давно. Ее создатель пошел дальше и реализовал программу по переходу с ихнего PA-RISC на Итаны. Вроде как даже все удачно получилось.

Ну, MMX-регистры на самом деле - мантиссы регистров FPU. Есть ещё расширения SSE 1,2,3, 3DNow, но они есть не на всех процах. А вот взять общие регистры с 64 битами - это дело. Опенофису это не нужно, а вот в mplayer, mencoder, lame используется.

>то там регистров общего назначения 128 штук

Это потому, что итаники есть не сто иное, как продолжение процов i80860. Итаниумы - это классические VLIW процессоры. То, что делает Трансмета и итаниумы - это близнецы-братья. Со всеми преимуществами и недостатками VLIW.

>Используйте интелевский компилер для итаниума

Именно потому, что итаниумы - VLIWы. Все, что можно, посчитает сам компилер. Он же должен выполнить роль блока предсказания ветвлений. Тогда да - НАМНОООГО повысится производительность софтины. Ибо проц в любой момент времени будет всегда ТОЧНО знать какие данные в какой регистр в следующий момент времени загрузить и что с ними надо будет сделать. Ну и, конечно, заранее затребовать дату из оперативки - чтобы уменьшить время простоя.

Как только код будет "непредсказуемым" - как, например, в случае эмуляции какой-нибудь другой архитектуры - так Итаники все и сливают. Кстати, так же поступают и трансметовские Efficeonы.

Друзья, вы такой бред пишете, что читать смешно. Какой, нах, синус с повышенной точностью? Как можно с помощью ММХ команд производить операции с плавающей точкой? Бред полный.

Очень легко. Ни FPU, ни MMX, ни SSE, ни SSE2, ни SSE3, ни 3dNow! на самом деле не существует. Это нечто виртуальное. Есть единый математический процессор (физически являющийся частью CPU), который может работать в разных режимах.

>а) я не учёный, я простой студент
могли бы не утруждать себя сообщать - это и так видно

>б) если он 64-х битный, то это значит что в него можно целиком запихать большое число(пояснения специально для тебя: 64 знака в двоичной системе счисления). Т.е на действие с ним уйдёт меньше тактов.

может и 2 + 3 быстрее сложит? Не зачет, студент ;-)

>Вы где живете? Я не видел рекламы от АМД, везде крутят от
Intel....

В профайле написано.
Intel Itanium здесь точно не крутят :))
А с AMD64 идёт очень много компов (в том числе и бюджетных)


>Как это нет? WinXP 64 вышла пол года назад, а Win2003 64
еще раньше, но вот с драйверами беда. Под Linux'ом нет
таких проблем, все практически поддерживается, даже
USB ADSL модемы....

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

Если честно, то VLIW+EPIC была очень неплохая идея уйти от суперскаляра. Жалко, если она накроется. Но у Intel это не первый и не последний пролет, был например провальный iAPX432. VLIW очень мало кто рискнул делать. Transmeta умерла, да и не работала никогда в native VLIW. E3m - просто смешно. Есть парочка DSP-шек VLIW и все.

Непонятно, почему Intel не разгоняют Itanium до предела своего кремния 3GHz.

> Непонятно, почему Intel не разгоняют Itanium до предела своего кремния 3GHz.

Как раз понятно. 3..3,5 ГГц можно только на P-IV нормально сделать - у него специально заточенная на частоту архитектура. Итаник или, скажем, P-M больше чем на 2..2,6 нифига не заведется. И на такую частоту и при объемах выпуска итаника выход годных будет никакущщий, и себестоимость огромная. Оно и так не дешевое, а 3-ГГц - будет стоить своего веса в калифорнии (который металл ;)

Кстати, концепция Много-Суперскаляров-на-Чипе может оказаться нисколько не хуже VLIW+много_запчастей_от_проца. Cложность компилятора под VLIW слишком велика. А компиляторы к суперскаляру тоже стали э... весьма изощренными. Насколько знаю, у Sun в Niagara аж 8 SPARC-ов на чипе.

> Очень легко. Ни FPU, ни MMX, ни SSE, ни SSE2, ни SSE3, ни 3dNow! на самом деле не существует. Это нечто виртуальное. Есть единый математический процессор (физически являющийся частью CPU), который может работать в разных режимах.

а вот и неправда:

http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions
"On the Pentium III, however, SSE is implemented using the same circuitry as the FPU, meaning that, once again, the CPU cannot issue both FPU and SSE instructions at the same time for pipelining. The separate registers do allow SIMD and scalar floating point operations to be mixed without the performance hit from explicit MMX/floating point mode switching..."

видимо на P4 и далее circuitry для SSE отличалась от таковой для FPU, и действительно:

http://en.wikipedia.org/wiki/SSE2
"The addition of 128-bit integer SIMD operations allows the programmer to completely avoid the eight 64-bit MMX registers "aliased" on the original IA-32 floating point register stack. This permits mixing integer SIMD and scalar floating point operations without mode switching required between MMX and x87 floating point operations..."

> Именно потому, что итаниумы - VLIWы. Все, что можно, посчитает сам компилер. Он же должен выполнить роль блока предсказания ветвлений. Тогда да - НАМНОООГО повысится производительность софтины. Ибо проц в любой момент времени будет всегда ТОЧНО знать какие данные в какой регистр в следующий момент времени загрузить и что с ними надо будет сделать. Ну и, конечно, заранее затребовать дату из оперативки - чтобы уменьшить время простоя.

а вот и неправда:

http://en.wikipedia.org/wiki/IA-64
"The downside is that a program's runtime-behaviour is not always obvious in the code used to generate it, and may vary considerably depending on the actual data being processed. The out-of-order processing logic of a mainstream CPU can make decisions on the basis of actual run-time data which the compiler can only guess at. That means that it is possible for the compiler to get its prediction wrong more often than comparable (or simpler) logic placed on the CPU..."

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

Может, я несколько неправильно выразился. Скорее, так "компилятор берет на себя роль блока предсказания ветвлений 1-го уровня".

В остальном - бред. VLIWы имеют преимущества перед суперскалярами ТОЛЬКО в том случае, если проц знает какую дату и когда загрузить из оперативки и что с ней сделать. В случае ошибочной загрузки данных, простой получается настолько большим, что сводит на нет все преимущество VLIWов над суперскалярами. Кроме того, без информации и том "что и когда делать" VLIW процессор тормозит, поскольку вынужден загружать на выполнение по одной команде (вместо выполнения блока команд в "нормальном" режиме).
Кстати, если бинарники для суперскаляра оптимизировать теми же методами что и для VLIWов, то и суперскалярные процы покажут куда более высокую производительность (потому, что блок предсказания ветвлений будет меньше ошибаться).

>SSE is implemented using the same circuitry as the FPU

"SSE спользует ту же схему, что и FPU". Где неправда в моем постинге была???

>CPU cannot issue both FPU and SSE

Правильно. Ибо вычислительному блоку надо было переключаться между режимами работы.

>This permits mixing integer SIMD and scalar floating point operations without mode switching required between MMX and x87 floating point operations

Теперь ему переключаться не надо, он на лету выполняет любые инструкции.

Так в чем я ошибался-то, я не пойму?

> Если вы посмотрите на debian, то обнаружите, что _весь_ юзерспейс там 32-битный, а всё потому что нафиг там не нужны эти 64-бита, кроме как память кушать.

Что курил? У меня стоит 64-битный Debian, там 64-битный юзерспейс и ОПЦИОНАЛЬНО - отдельные библиотеки для 32-битных приложений!!! amd64.debian.net

Это тоже самое что делала трансмета или другое

> Очень легко. Ни FPU, ни MMX, ни SSE, ни SSE2, ни SSE3, ни 3dNow! на самом деле не существует. Это нечто виртуальное. Есть единый математический процессор (физически являющийся частью CPU), который может работать в разных режимах.

Дык с этим никто и не спорит. Я говорил о том, что в 64-битном процессоре синус считается с такой же точностью, что и в 32-битном. И что с помощью MMX-инструкций нельзя выполнять операции с плавающей точкой.

Кстати, дя спорщиков. На сайте самой AMD есть пример выполнения умножения двух 64 битных чисел. Так, если я правильно помню, на 32-х битном проце это занимает 15 тактов, а на 64 - 3. Разницу посчитать сумеете?

Синус действительно с одинаковой точностью считаться будет. Но... за разное время. Особливо, если SSE2 использовать, к чему есть даже специальные библиотеки (стоит поискать их на сайте Intel)

Про скорость, особенно с длинными числами, никто не спорил.

ЗЫ: В этой интеловской библиотеке синус считается быстрее, чем оригинальной функцией fsin? Интересно было бы посмотреть. Может найдете ссылку, у меня не получается...

>Дык с этим никто и не спорит. Я говорил о том, что в 64-битном процессоре синус считается с такой же точностью, что и в 32-битном. И что с помощью MMX-инструкций нельзя выполнять операции с плавающей точкой. А как же эмуляция?

> А как же эмуляция?

Эмуляция чего? Эмуляция операций с плавающей точкой с помощью MMX-инструкций? Это как гланды удалять через задницу.

sizeof(time_t) = sizeof(int)

posix
рекомендует
но не требует для time_t использовать 64 бита
это так, для неумеющих читать
некоторые системы используют long long
некоторые нет
основная проблема - обратная совместимость

Быстрее, в том и дело. Правда, справедливо только для Интеловских процов с их слабым FPU. Библиотеку поищу, только не сию секунду.

> у сопроцессора регистра 80-битные. Начиная с 8087.

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

--

SVK

>Да при кодировании видео (и аудио, возможно, точно не знаю)

а ты не стесняйся. посмотри код mencoder-а

>Но как было сказано, дела это "сопроцессорные

mmx,mmx2,3dnow,3dnow2,sse(2(3))

> посмотри код mencoder-а > mmx,mmx2,3dnow,3dnow2,sse(2(3))

mmx2??? Я что-то пропустил? :)

sse3 точно используется?

> >Кстати, Microsoft уже давно заявила, что они сворачивают винду на итанике. Поэтому линукс - это единственное, что его теперь поддерживает

> А как же хпукс ? :-)

...а исчо открытая внутриматочная спираль ;) (OpenVMS). К примеру: http://www.hp.com/products1/servers/integrity/entry_level/index.html

> Но... за разное время. Особливо, если SSE2 использовать, к чему есть даже специальные библиотеки (стоит поискать их на сайте Intel)

Есть мнение, что SSE*-инструкции в процессорах AMD присутствуют для галочки под названием "совместимость". И никакого увеличения производительности при их использовании нет (и так все быстро).

> Есть мнение, что SSE*-инструкции в процессорах AMD присутствуют для галочки под названием "совместимость". И никакого увеличения производительности при их использовании нет (и так все быстро).

А приведите кто-нибудь пример программы, реально выигрывающей от sse и mmx. И чтоб можно было убедиться при помощи gcc с флажками типа msse, mfpmath

Ага, в это время мелкомягкие вместе с АМД перекурили неправильных веников :( Одно только:"Migration of 32-bit and 64-bit UNIX applications to 64-bit Windows enabling customers to deploy their UNIX/Linux applications on AMD64." на сайте AMD http://developer.amd.com/devtools.aspx#Compilers чего стоит млин....?

Так что обсуждаемые нами тут темы ничто по сравнению с тараканами в АМД, Интел и Майкрософте.

> Есть мнение, что SSE*-инструкции в процессорах AMD присутствуют для галочки под названием "совместимость". И никакого увеличения производительности при их использовании нет (и так все быстро).

Засуньте это мнение в гудок тому, кто это сказал.

2108-ого.

>> Если вы посмотрите на debian, то обнаружите, что _весь_ юзерспейс там 32-битный, а всё потому что нафиг там не нужны эти 64-бита, кроме как память кушать.

> Что курил? У меня стоит 64-битный Debian, там 64-битный юзерспейс и ОПЦИОНАЛЬНО - отдельные библиотеки для 32-битных приложений!!! amd64.debian.net

Читай внимательнее, я про UltraSPARC говорил, а не про твое добро.

64 битный десктоп - суксь

вот уж точно "нахрена козе баян", 64 бита только серверам для расширения адресного пространства и нужны, десктопу один только вред - поинтеры и интежер в два раза толще (8 байт вместо 4-х) и в результате память/кеш выкушивается этими 4-мя дополнительными байтами бессмысленно, а шины гоняют их бесцельно.