Как стать автором
Обновить

AMD и Intel собираются конкурировать с архитектурами ARM и RISC-V. Что ожидает индустрию?

Время на прочтение4 мин
Количество просмотров9.9K
Всего голосов 46: ↑43 и ↓3+57
Комментарии27

Комментарии 27

оставаясь основными конкурентами в области х86-процессоров, вынуждены объединиться перед лицом серьезных вызовов со стороны ARM и RISC-V.

Похоже на какой-то старый картельный сговор монополистов, против любых инноваций

А мне показалось, что инвесторы, глядя как сдувается Intel, порешали, что AMD должна будет его тянуть вверх. Для видимости союза закинули туда ещё двоих персонажей вряд ли разбирающихся в дизайне и разработке процессоров. Ведь никто не мешает Intel и AMD вскочить в поезд вместе со всеми и делать ARM или RISC-V процессоры.

Торвальдс во всяком случае считает себя спецом по x86, и уже работал в этом качестве а компании Transmeta

AMD было некогда создано Intel вследствие претензий в монопольном положении

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

Вообще-то AMD вполне себе существовала в 1970-е годы, когда ни у кого никаких монополий на рынке микроэлектроники ещё не было, да и быть не могло.

AMD была создана в 1969 году, спустя полгода после создания Intel и за два года до того, как Intel создала свой первый процессор - 4004. Единственное, что их объединяет - это то, что создали обе компании выходцы из Fairchild.

Похоже на какой-то старый картельный сговор монополистов

Не просто похоже, а так оно и есть. Для пущего пеару прикупили пучок заслуженных дедов:

вошли Тим Суини, основатель Epic Games и разработчик Unreal Engine, и Линус Торвальдс, создатель операционной системы Linux. Их участие в проекте подчеркивает стремление AMD и Intel усилить свои позиции за счет экспертной поддержки и опыта ведущих разработчиков программного обеспечения

PS Intel и AMD подвела жадность: два десятилетия, с условного 2000-го искусственно блокировали выпуск на массовый рынок дешёвых многоядерных чипов, и "доили" его 2-4 ядерными процами.

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

PS Угу.

У интела огромный запас технологий, экспериментальные 80ти ядерные процы они делали 15 лет назад.

https://habr.com/ru/companies/selectel/articles/851894/#comment_27437352

PS Intel и AMD подвела жадность: два десятилетия, с условного 2000-го искусственно блокировали выпуск на массовый рынок дешёвых многоядерных чипов, и "доили" его 2-4 ядерными процами.

У AMD был 8 и 6 ядерный Bulldozer  в 2011.

Они только формально были 8-ми ядерными, по факту это был Hyper-Threading на стероидах, FPU делилось между двумя ядрами, поэтому в играх было все печально, возможно эти процессоры неплохо могли крутить базы данных и компилировать код, но кому из домашних пользователей оно нужно, к тому же у интел были HEDT под 2011 сокет, только за очень много денег. АМД сейчас то же жмется, у них есть 12-ядерные чиплеты(судя по EPYC) только в домашние процессоры они их не ставят, да и каналов памяти пора бы докинуть, ставить два канала 15 лет подряд, такое себе. Но основная проблема как понимаю не в многоядерности сейчас, ее потанцевал до сих пор никто толком раскрыть не может, игры не больше 8-ми ядер используют(потому что в приставках столько), в графически и видеоредакторах видеокарта все быстрее сделает. А вот с однопотоком что у интел что у амд в последних линейках процессоров беда, нет прироста скорости, в отличие эплового М4. Когда увидел Ryzen 9000 линейки подумал ну вот и провал у АМД, но потом начала появляться информация о Core Ultra 200, на фоне них 9000 линейка от АМД еще хорошая вышла.

к тому же у интел были HEDT под 2011 сокет, только за очень много денег

Из-за "очень много денег" они совсем не конкурировали. Ближайшее у AMD - склейка из двух FX'ов (Opteron 6300, до 4 сокетов).

FX в некоторых задачах дотягивались до i7, стоя гораздо дешевле. Благо были i7 без графики с 20% скидкой в виде Xeon E3.

Тезис, что "подвела жадность" у @MasterMentor- ерунда:

  • Intel теперь продаёт для нейронок Gaudi, но должен выкинуть HBM-память и вернуть x86-ядра а-ля Xeon Phi, чтобы стало хуже?

  • Нишу GPGPU AMD и Intel позорно отдали производителям GPU, среди которых AMD, Intel...

  • Но допустим, что из производства дешёвых много-многоядерников можно извлечь выгоду, пусть и непонятную мне. Тогда бы он знал, что потомок 80-ядерника вышел в продажу в виде ~60-ядерных Xeon Phi, которые распродавались в 2014-2015 по $200-$300. Что с ними делать?

  • 10 лет назад в сервер можно было упихнуть 48 "больших" x86-ядер, 9 лет назад - уже 144. Зачем терять деньги, предлагая то же самое потребителям со скидкой? Получится нехорошая конкуренция между товарами. Зачем им было спешить с многоядерностью, если конкурентов тогда не было? Сейчас надо догонять Apple и проблема тоже не в количестве ядер.

(48 ядер - что я посчитал?.. 15 шт. в E7-8xxx v2 * 8 сокетов = 120)

Не знаю, что Вы поняли из написанного мною, я лишь сказал, что за 20 лет "достижения" Intel и AMD по наращиванию вычислительной мощности и скорости их процессоров в сравнении с GPU - смехотворны.

When we compare GPUs with CPUs over the last decade in terms of Floating point operations (FLOPs), we see that GPUs appear to be far ahead of the CPUs
When we compare GPUs with CPUs over the last decade in terms of Floating point operations (FLOPs), we see that GPUs appear to be far ahead of the CPUs

https://www.r-bloggers.com/2011/01/cpu-and-gpu-trends-over-time/

https://www.researchgate.net/publication/262379237_Parallel_computing_in_economics_-_an_overview_of_the_software_frameworks

При этом стоимость многоядерников Intel - просто зашкаливает.

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

(При этом для "офисных нужд" - уже с головой хватало мощности их процессоров начала 2000-х.)

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

Это уже давно не "числодробилки".

Из каких частей состоит графический процессор?

Шейдерные процессоры
Текстурные блоки
Блоки трассировки лучей
Блоки матричных вычислений
Тензорное ядро

https://club.dns-shop.ru/blog/t-99-videokartyi/122040-ustroistvo-graficheskih-protsessorov-gpu/

И, эти все узкоспециализированные узлы, с специфичной математикой, и скажем что даже 8051 микроконтроллер просто реализует, в этом супер-пупер процессоре тупо не получится реализовать, даже если реализовать в нём узлы ввода-вывода.

Вы сказали, что x86 мог занять некую нишу, занятую теперь GPU.

Я в ответ спросил, что компании потеряли, если они обе производят GPU и как конкурировать со специализированными ускорителями?

Ничего не потеряли ("подвела жадность" - это возмущение несправедливостью), а если конкурировать, то тоже путём специализированного ускорения (AVX-512, AMX, HBM-память внутри процессора, NPU).

Флопсы говорят о рафинированном "числодроблении". На первом графике могли по ошибке смешать FP32 и FP64 ("Data ... was mainly Wikipedia and the odd mailing list post" ситуацию не проясняет), на втором в конце процессоры отстают в 3 раза в FP64 (график от nvidia, процессоры не уточняются).

К чему был кивок на экспериментальный 80-ядерный процессор? Чтобы возмутиться, что направление осталось экспериментальным. Но нет, x86-числодробилки пошли в продажу. И ради желанного дробления чисел им недостаточно было обрасти ядрами, пришлось мутировать и обзавестись 16-канальной распаянной GDDR5 (а в следующем поколении типа-HBM на подложке + 6 каналов DDR4). Подозреваю, что такие мутанты с распаянной памятью не интересны, но именно они хорошо дробят числа - надо бояться своих желаний.

Зачем обосновывать позицию "CPU так отстают от GPU из-за сговора" ссылкой (второй) на это?

GPUs obtain high FLOP rates because they are specialized for highly parallel computations and they have more transistors dedicated to data processing rather than flow control or data caching as in the case of a CPU.

"Сдувающийся" Интел имеет оборот в 3 раза больше АМД, на сколько я помню жирный кусок АМД принадлежит основным акционерам Интел, от антимонопольки они так ушли лет 15 - 20 назад. У интела огромный запас технологий, экспериментальные 80ти ядерные процы они делали 15 лет назад.

Интересно, а duckduckgo это не зонтичный проект Гугла для тех же целей?

Во всяком случае, Firefox — это, можно сказать, зонтичный проект для хрома, учитывая, что мозиллу именно гугл в основном финансирует

Ну что, мо-лод-цы. Взять и запихнуть в статью про RISC-V в раздел про RISC-V копипасту из другого своего поста, в которой говорится про Loongson и их, цитирую, "собственная архитектура LoongArch". Внезапно. В статье, где в заголовке упомянуты Intel, AMD, ARM, RISC-V - рассказывается про Intel, AMD, ARM и Loongson, и нет ничего про RISC-V.

Видимо не спроста акции Loongson  идут в гору. Жаль их в России не прикупить((

Мне вот очень любопытно, есть люди сведущие в современном процессоростроении, кто сможет рассказать?

Какая доля транзисторного бюджета расходуется на поддержку легаси инструкций и обеспечения совместимости с какими-то экзотическими древними системами?

Мне почему-то думается, что на границе перехода от Win 7 к 8-ке и 10-ке, коллаборация Wintel могла сделать удачный финт: разделить процессорные линейки и ОС на две ветки — условно, Stable, на основе Win 7, где важна совместимость со старым кодом, потихоньку патчить безопасность и постепенно обновлять и выпускать новые середнячковые процы, с 4-8 ядрами на более новых, но не самых передовых и экономически выгодных тех. процессах. И bleeding edge с директ иксами 15, поддержкой самых современных процессоров, видеокарт, но (!) без тянущего назад груза легаси, раздутого кода ОС, с которым ещё нужно постоянно мучаться, чтобы не сломать какую-то условную совместимость (да, и с облаками и подписками, хе-хе, куда без них). Для геймеров, тех, кому нужна производительность и самые современные технологии.

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

А тем, у кого 32 ядра и 4090 с ИИ моделями, вот прямо, жить не могу, нужен 20-ти летней давности код, похороненный где-то глубоко в недрах?

По моим ощущениям, выкинув всё неактуальное, для топовых процессоров можно было бы сразу получить 30% буст в производительности. Ещё и упростив дальнейшую разработку.

Будет забавно, если пресловутая "совместимость", которую многие ставят как неоспоримую заслугу, как раз линейку x86 и погубит.

Какая доля транзисторного бюджета расходуется на поддержку легаси инструкций и обеспечения совместимости с какими-то экзотическими древними системами?

В одной из статей серии «Made at Intel» упоминается такое:

С каждым shrink (переходом на более совершенный процесс изготовления чипов) площадь, необходимая для поддержки legacy инструкций, “сжимается” в два раза.

Intel уже работает над x86S — сокращённом варианте x86 без легаси.

Но как много будет говна, из-за того что например в приложениях пользователей будет, например MSVCRT** и там в какой-либо редкой функции будет использован этот код.

потеряв полную совместимость они как раз и потеряюсь свое главное конкурентное преимущество

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий