Cпецификации мягко говоря впечатляют

вы что курили? для Итаника создаются отдельные ОСи и специально пишется софт, который не имеет ничего общего с привычным х86

Linux + gcc/icc. Ничего спецом под него не пишется.
Кстати, а разве из потребителей Итаника не осталась одна HP?

Ну и эгсперты тут собрались

Омереканска подделка под наш Эльбрус 2000 тоже не взлетела, да

Пузо Под чего там подделка?

ARM означает Advanced RISC Machines.

Добавлено спустя 2 минуты 40 секунд:


ага, видяхи считаю приблизительно, а центральные процессоры - точно.
вы про стандарты на вычисления слышали?

x86 внутри тоже RISC уже давно, с середины 90-х.
И вообще, Итаник - это VLIW/EPIC.

Да нормальные процы,для тех у кого есть бабло!!!

Настолько сложные, что всего 4 процессора осилили?

Ага, по одному на модель =)

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

Я бы сказал, что узкий круг задач нельзя распараллелить. Фактически все задачи легко параллелятся на тысячи параллельных процессов.

Добавлено спустя 47 минут 9 секунд:
Какие задачи можно параллелить:

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

- Там где есть объекты одного класса. Обработка внутри одного объекта чаще всего не влияет на обработку внутри других объектов.

Например, в играх, стратегиях реального времени, пошаговых стратегиях, или 3D-аркадах, существует множество объектов (юнитов- боевых единиц, строений и т.д.) расчёт для каждого объекта, в большинстве действий не зависит от остальных. Но программисты, по старинке, выстраивают их в очередь, считают сначала один, потом другой и т.д. превращая многопоточную задачу в однопоток.

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

В проигрывателе, архиваторе, кодере и подобном - работа с однообразным потоком данных в цикле - можно разбивать на параллельные потоки. Работа с таблицами, построение графиков - опять параллельная работа. Объекты Windows (окна, буквы, линии, картинки , задачи) - тоже не нуждаются в последовательном выжидании, обрабатывать можно одновременно.

Есть задачи, которые не распараллелить:

- Решение уравнения методом половинного деления.
- Шифрование данных, где ключом шифрования каждого следующего символа является результат шифрования предыдущего.
- Вычисление отдельной функции типа cos(x), не разбивается на независимые задачи.
- и т.д.

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

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

Я работаю программистом и ниодна из моих программ не была однопоточной. Распараллелить можно почти все программы. Вопрос стоит только в величине потерь на синхронизацию. НО даже дураку понятно что в любой системе работает несколько десятков, а то и сотен-тысяч процессов. В винде среднее количество 200 процессов. Эти процессы не взаимодействуют и каждый работает в отдельном потоке. Поэтому нашлепка в х86 для обеспечении многопоточности сильно нагружена и в ней происходят большие потери. И уже только из-за этого Itanium является идеальной архитектурой для любой системы, а не только серверного сегмента.
Интел могла бы не перенимать набор команд AMD64, а смастерить свой двухядерный процессор x86+IA-64, это позволило бы плавно перевести всех на Itanium. В будущем можно было бы исключить x86 из процессоров. Действовать нужно силой, а не просьбами. Протокол IPv6 уже 10 лет пытаются продвинуть, назначают всякие даты. А толку нет.

1. Процессы буду точно так же конкурировать за ресурсы процессора.
2. Для итаниума придется почти вручную раскидывать данные по конвеерам процессора (ок, компилятор поможет), но издержки тупой идеологии EPIC все равно останутся.



TSS? Ты прикладной программер, я так понимаю? Потому как TSS нигде не используется, слишком накладно. В основном вместо него програмная смена контекста используется.

Itanium - тупая горячая числодробильня, но не более. Конкурент у нее - POWER, и назвать ее

язык не поворачивается. Костылей там лепить придется много больше, чем в x86.

Могут. Не в том дело. А в том, что для ГПУ пока еще нужен проц, указывающий, что же делать блокам ГПУ.


Бред. На какое ядро в х86 код загрузят - то ядро его и будет исполнять, и никто ничего не распараллеливает на уровне железа. Так же и на других архитектурах.

Радикальное отличие итаника - то, что у него VLIW архитектура. Т.е. - из памяти выгребается строка с набором из N команд, и подается прямиком на исполнительные устройства, минуя декодер команд и блок внеочередного выполнения. Т.е. порядок исполнения команд задается еще на этапе компиляции. Это упрощает кристалл, но ломает совместимость - любая модификация архитектуры требует перекомпиляции софта.

У интела не было вариантов, продвигать новую архитектуру в одиночку, когда рядом х86 с тоннами софтов и конкурент, который запилил 64-х битность с обратной совместимостью, попутно выпилив некоторые костыли х86.
И где 8 ядер неэффективны? Там где они используются, масштабируемость 100%. Что и покажет даже элементарная синтетика в виде cinebench с выключенным HT или тот же boinc или fah. Когда это ядра стали общаться через шину? Вроде как л3 есть, который у интела теперь еще и работает на частоте ядер. У 2-4-х сокетных плтформ все аналогично, у интела есть два двухсторонних qpi контроллера в каждом xeon e5, у амд по сути все так же, только 16-ти ядерники шину захламляют, но видимо на производительности общение 2-х кристалов через шину не сильно сказывается.

У Itanium есть вполне понятные конкуренты - POWER и SPARC. И если честно спецификации пока не впечатляют. Тот же IBM уже молотит 32 потока на кристалл. SPARC вообще позиционируют как самый мощный проц, и такой монстр как ORACLE обеспечит его отличным ПО.
А Итаниум дохнет, и не понятно что его может спасти, предшественник этой серии был очень слаб =((

тут несколько НО:
- набор команд. У итаниума архитектура была революционной, а у хамера еволюционной. Следовательно НИКАКОЙ старый софт на итаниуме не пошел. На хамере же шел. А так как тогда о многоядерности никто не думал, а приоритетотм было 64 бита тоначали использовать архитектуру от амд. Это позволило иметь64 бита и совместимость с старым софтом. Да и многоядерность тогда смотрелась чудачеством- кому нужно тот использовал многопроцесорность. Кстати и на этом поле амд нехило вырвалось вперед, деталей непомню но оптероны 2005 года были куда поефективней интеловских процов в плане многоядерности. У интела каждое ядро связывалось с каждым и как следствие слишком много междупроцесорных связей. Как было у оптерона непомню.

Примерно так и есть.
Только речь шла не о затратах на удушение, а несколько об ином.
И 9-я линейка (которую многие уже не ожидали увидеть) - очередное тому подтверждение.



Не надоело чушь через тему писать?
Хотя бы приписывайте "ИМХО" или "по-моему", а то раз за разом в неловкие ситуации попадаете.



Ну да. Какая разница, какой проц, если медиапоток всё равно декодируется силами UVD, PV или ICV (теоретически невозможно в системе с Itanium).