Кстати, судя по тому, что контроллер DDR или PCIe зачастую стоит дороже, чем процессорное ядро, то и сделать его сложнее, да и на FPGA не отпрототипировать. Так что GPU - это не самая большая проблема еще.
Я не говорил, что это просто. Как и любая продвинутая технология, разработка процессоров выглядит для непосвященных магией. Тем не менее, фактически процессорное ядро — это просто огромный набор кубиков, которые можно по-разному состыковать. Можно выбрать кубики разного цвета и разного размера, но они все друг с другом стыкуются, как лего. И они уже все придуманы и даже описаны в статьях. Разумеется, собрать динозавра из этих кубиков сложно, но это не магия. Просто нужны люди и время и деньги на зарплату, да и на сами кубики тоже. Лично на мой взгляд, сделать быстро и хорошо работающий многоядерный процессор сложнее, чем отдельное ядро (я уж молчу про софт для него).
Вот, кстати, их ускоритель AI на том же чипе — это уже другие кубики, какие-то треугольные.
Здесь есть нюанс. Чтобы сделать частоту процессора быстрее, вы жертвуете эффективностью. Например, вы добавляете больше стадий в конвейер, что влияет на латентность команд и увеличивает оверхед при неправильно предсказанных переходах, увеличивает энергопотребление, и т.д. Посмотрим на два гипотетических процессора, сделанных по одному техпроцессу. Один из них разработан, чтоб работать на частоте 1ГГц, а другой — 2ГГц. У них будут разные архитектурные решения, чтоб этого добиться. Теперь, если вы возьмете второй и запустите на 1ГГц, вы увидите, что он менее эффективен (по тем же IPC) и больше жрет, чем первый. Если для вашего приложения 1ГГц достаточен, или у вас ограничение по энергопотреблению, то лучше выбрать первый. Но это не значит, что архитектура первого лучше, просто она другая.
Ахах. Всего-то нужно добавить декодеров =) «Глупые» интеловцы и AMD-шники и ARM-овцы делают uOP кэш и разметку в L1I чтобы хоть как-то расширить узкие 4-5 wide декодеры.
А больше они и не могут сделать. Без VLE это проще,
поэтому в Power-печке 6/12-wide декодер.
Вы снова читаете не то, что я написал, а то, что вы хотите видеть. Не знаю, что там делают интеловцы со своей убогой ISA, но почему ARM не ставит больше декодеров? Поставить больше декодеров — это самое простое, что только можно сделать в процессоре (проще только кэш увеличить). Пока подумайте, ответ ниже.
Это делать не нужно. Вы не слышали про предсказатель ветвлений?
После всей сказочной ереси которую вы тут наговорили, я не удивлён.
Слышал, могу даже вам рассказать, как они работают. Кстати, они — одна из самых сложных частей процессора (при этом одна из самых маленьких). А теперь представьте себе обычный код: три команды, потом переход, потом две команды, еще переход, еще пять команд, потом два перехода подряд, потом еще пара команд. Итого 16. Некоторые переходы условные и зависят от результатов предыдущих команд. Теперь вы за раз вытаскиваете из кэша по 8 команд и декодируете их параллельно, а потом решаете, что делать дальше. Так вот, в этих 8 командах у вас два перехода, которые могут зависеть от результатов первой и второй команды соответственно. Окей, у нас предсказатель переходов, который говорит нам, что первый переход надо выполнить. Правда, за то время, за которое срабатывает предсказатель, мы спекулятивно вычитываем и декодируем еще, например, три раза по восемь команд. То есть мы достали и декодировали 32 команды, из которых смогли использовать только четыре. Ну ок. Возможно, этим оверхедом можно пожертвовать. Правда, на мой взгляд это как раз то, что превращает процессоры в печку. Что-то в этом есть от Pentium-4 :)
У меня есть замечательная книжка Майка Джонсона — одного из авторов AMD 29050. Это первый суперскалярный RISC от AMD — 1990 год, вроде бы. И в ней уже есть графики, сравнивающие эффективность декодера на 2 и 4 команды. Даже если мы забудем все доисторические мэйнфреймы, то декодер на четыре команды в обычном процессоре был представлен больше 30 лет назад! С тех пор частоты и количество транзисторов выросли астрономически, но до сих пор тот же ARM пихает декодер на те же четыре команды в самые распоследние Cortex-A7x. Вот же тупыыыые!
Непонятен ваш сарказм. Разумеется, равняется — чипы-то на деревьях не растут. Инженеры такие есть у всех компаний, что я перечислил, а еще у них много проектов — намного больше, чем вы думаете. Так что да, они занимаются другими задачами. Не хочу вторгаться в мир розовых пони, но я знаю, как работает эта индустрия.
А вы попробуйте сделать frontend с шириной 8. Intel/AMD тут и рядом не стояли. IBM может такое сделать в своих 200-300W печках.
Но в ядре с потреблением 4-6W не может.
При увеличение ширины запуска сложность соединений растёт очень быстро (квадратично).
И в чем конкретно проблема сделать frontend с шириной 8? Делаем шину в L1 I-cache шире, 512 бит или 1024 бит — сколько не жалко. Добавляем декодеров, и вуаля. Ах да, компилятором анроллим все циклы, чтоб было чем загружать execution units, что увеличивает размер кода в разы и трэшит нам L1 I-cache. Бинго! Не удивительно, что у них >=192кБ L1 кэша для команд. Про IBM смешно, если б у них стояла задача сделать чип для лаптопа, то 300-ваттная печка превратилась бы в 15-ваттную путем замены одной библиотеки стандартных ячеек на другую — пара месяцев работы (работала бы медленнее, да).
При увеличение ширины запуска сложность соединений растёт очень быстро (квадратично).
Это не critical path, так что пофиг.
Данные «в среднем по больнице» не интересны. Основное время код проводит в циклах.
Это никак не отменяет того, что я сказал.
Вот дураки — то в Интел и AMD. Не могут 1 строчку поправить :) А ещё и кэши не могут увеличить как у Apple. Ведь это 1 строчка в коде(с) Как сидели в 2003 с Pentium-M, так и сейчас сидят на 32/32 (L1I/L1D) в Comet Lake.
Не не могут, а не хотят. Потому что у них есть симуляторы, которые показывают, что это неэффективно. Но есть люди, которым всегда надо больше — больше МГц, больше ядер, больше мегапикселей, больше камер,… :D
Ничего, что размер структур напрямую влияет на энергопотребление и задержки? ARM не любит большие ROB, потому как это заметно ухудшает энергоэффективность.
Apple, в отличии от всех остальных может делать большие структуры, которые быстро работают и при этом энергоэффективны.
У Эппла какая-то другая физика, или просто 5нм? :)
1. По вашей же ссылке есть комментарий: «The i7-1165G7 is within 20% on single core performance of the M1. The Ryzen 4800U is within 20% on multi-core performance. Both are sustained ~25W parts similar to the M1. If you turned x64 SMT/AVX2 off, normalized for cores (Intel/AMD 4/8 vs Apple 4+4), on-die cache (Intel/AMD 12M L2+L3 vs Apple 32MB L2+L3) and frequency (Apple 3.2 vs AMD/Intel 4.2/4.7), you'd likely get very close results on 5nm or 7nm-equivalent same process. Zen 3 2666 vs 3200 RAM alone is about a 10% difference. The M1 is 4266 RAM IIRC.»
2. Ну если у вас есть процессор, который УЖЕ умеет все это, просто для трех команд в параллель, то как вы думаете, сложно ли переделать его, чтоб он делал то же самое для восьми? Ответ: это просто. Сделать так, чтоб при этом он не стал работать медленнее и жрать сильно больше — гораздо сложнее. Верифицировать это все — еще сложнее (но не думаю, что Эппл покажет Errata на этот чип :D )
3. Подождите, причем здесь смартфоны? Мы говорим про НОУТБУЧНЫЙ проц! Не видел ни одного хипстера в кофейне с самсунговским ноутом
4. Разработка дорогая. Один американский инженер стоит им как минимум $120к в год. Думаю, они делали этот чип минимум 2-3 года. Сколько народу работало — 100 или 1000 — я не знаю, но можете прикинуть сами. Плюс новый техпроцесс, который завсегда подкидывает проблем. Если бы AMD выпустил такой процессор, на нем должен был бы работать Windows и все игрушки.
Прошу прощения, что смею высказывать свое «ценное мнение», но и увеличение процессора «в ширину» не ново под луной. Проблема в том, что в среднем в обычном general-purpose коде всего четыре-пять команд между соседними командами ветвлений/переходов. И можно параллельно декодировать хоть 100, но КПД будет как у паровоза (если только это не спецпроцессор для DSP или AI). Да, глубина reorder buffer-а меняется одной строкой в коде (да и вообще, в процессоре изменение одной строки его кода может увеличить площадь в несколько раз — так, к сведению).
Что касается того, что никто другой в индустрии такого сделать не может — это неправда. Western Digital, например, скупил у Оракла всю команду разработчиков OpenSPARC для своих новых RISC-V — я уверен, что они могли бы сделать такое. Интел мог бы, АМД мог бы, Самсунг мог бы, Квалкомм мог бы, ХайСиликон мог бы. Просто это дорого, и кроме Эппла никто не смог бы такой процессор монетизировать. Здесь уже маркетинг и экосистема важнее.
Нет. Архитектор из 1980-х упал бы в обморок от количества EDA-софта, упрощающего разработку, и от скорости работы библиотек стандартных ячеек, но не от сложности процессора. Конечно, это сложный процессор. Но не сложнее интеловских, не уверен, что сильно сложнее какого-нибудь OpenSPARC или Power. Не прорыв. Не «The Next Big Thing».
Вот и ответ. Ничем принципиально M1 не отличается от других процессоров. Все то, о чем понаписано по ссылке, было изобретено еще в конце 1980-х. Просто куча железа + хороший техпроцесс + быстрая память. Идеальный вариант для ноутбуков. А теперь посмотрим, как они присобачат 32ГБ оперативки, которые от них уже видеографы всякие требуют :)
AMD серверные процессоры с ARM-овым декодером лет 10 назад стала разрабатывать — и что? Технически это вообще не проблема — тогда вопрос на засыпку: в чем же проблема? :)
С тем же успехом можно сказать, что VLIW вообще ортогональна RISC-у. Это просто один из способов распараллелить последовательные вычисления. Т.е. RISC может быть «классическим», суперскалярным или VLIW, в зависимости от того, кто и где параллелит.
E-PL тоже негуманных денег стоит. Был еще E-PM, который давно уже убили (у меня до сих пор лежит как запасной). Прицепить к нему какую-нибудь Сигму 60mm 2.8 — аналогов по качеству за такую цену не было бы ни у кого на рынке. Видимо, все равно не выгодно.
Нет. Это то же самое, что сказать, что софт надо писать на ассемблере, потому что иначе тяжело отлаживать. Если у вас верилога на 100 тысяч строк, как в каком-нибудь среднего пошиба проце, то удобность отладки верилога будет скомпенсирована количеством багов, которые вы понаделаете в этой вермишели. Не надо кривобокость инструментов приравнивать к недостаткам методологии.
Затем, что можно описать логику, которая не будет работать без констрэйнов. Даже если констрэйны есть, они могут быть неправильные и не совпадать с дизайном. Поэтому в нормальном языке дизайнер описывал бы требуемое поведение, а транслятор потом мог бы генерить LLHD IR, верилог, SDC и черта в ступе. Но для этого надо, чтоб люди сняли шоры, которые нацепили 30 лет назад, а это никому не надо. Проще респин чипа сделать :D
Зачем это надо? Раст, скала, пайтон, С++ — напридумывали уже черт знает чего. После этого любая ошибка в коде превращается в дамп на пятьдесят строк, говорящий не о том, где ошибка, а о том, что в какой-то библиотеке, вызванной из какой-то другой библиотеки, что-то отстрелилось в строке 17296.
Почитаю повнимательнее, но на первый взгляд основная проблема современных языков описания не решена. А проблема эта — искусственное разделение функционального описания и констрейнов. Не должно быть никаких Verilog + SDC + UPF, это должен быть один язык.
Кстати, раз уж прописали panic = "abort", то
extern "C" fn eh_personality() {}не нужна.Кстати, судя по тому, что контроллер DDR или PCIe зачастую стоит дороже, чем процессорное ядро, то и сделать его сложнее, да и на FPGA не отпрототипировать. Так что GPU - это не самая большая проблема еще.
Вот, кстати, их ускоритель AI на том же чипе — это уже другие кубики, какие-то треугольные.
Вы снова читаете не то, что я написал, а то, что вы хотите видеть. Не знаю, что там делают интеловцы со своей убогой ISA, но почему ARM не ставит больше декодеров? Поставить больше декодеров — это самое простое, что только можно сделать в процессоре (проще только кэш увеличить). Пока подумайте, ответ ниже.
Слышал, могу даже вам рассказать, как они работают. Кстати, они — одна из самых сложных частей процессора (при этом одна из самых маленьких). А теперь представьте себе обычный код: три команды, потом переход, потом две команды, еще переход, еще пять команд, потом два перехода подряд, потом еще пара команд. Итого 16. Некоторые переходы условные и зависят от результатов предыдущих команд. Теперь вы за раз вытаскиваете из кэша по 8 команд и декодируете их параллельно, а потом решаете, что делать дальше. Так вот, в этих 8 командах у вас два перехода, которые могут зависеть от результатов первой и второй команды соответственно. Окей, у нас предсказатель переходов, который говорит нам, что первый переход надо выполнить. Правда, за то время, за которое срабатывает предсказатель, мы спекулятивно вычитываем и декодируем еще, например, три раза по восемь команд. То есть мы достали и декодировали 32 команды, из которых смогли использовать только четыре. Ну ок. Возможно, этим оверхедом можно пожертвовать. Правда, на мой взгляд это как раз то, что превращает процессоры в печку. Что-то в этом есть от Pentium-4 :)
У меня есть замечательная книжка Майка Джонсона — одного из авторов AMD 29050. Это первый суперскалярный RISC от AMD — 1990 год, вроде бы. И в ней уже есть графики, сравнивающие эффективность декодера на 2 и 4 команды. Даже если мы забудем все доисторические мэйнфреймы, то декодер на четыре команды в обычном процессоре был представлен больше 30 лет назад! С тех пор частоты и количество транзисторов выросли астрономически, но до сих пор тот же ARM пихает декодер на те же четыре команды в самые распоследние Cortex-A7x. Вот же тупыыыые!
И в чем конкретно проблема сделать frontend с шириной 8? Делаем шину в L1 I-cache шире, 512 бит или 1024 бит — сколько не жалко. Добавляем декодеров, и вуаля. Ах да, компилятором анроллим все циклы, чтоб было чем загружать execution units, что увеличивает размер кода в разы и трэшит нам L1 I-cache. Бинго! Не удивительно, что у них >=192кБ L1 кэша для команд. Про IBM смешно, если б у них стояла задача сделать чип для лаптопа, то 300-ваттная печка превратилась бы в 15-ваттную путем замены одной библиотеки стандартных ячеек на другую — пара месяцев работы (работала бы медленнее, да).
Это не critical path, так что пофиг.
Это никак не отменяет того, что я сказал.
Не не могут, а не хотят. Потому что у них есть симуляторы, которые показывают, что это неэффективно. Но есть люди, которым всегда надо больше — больше МГц, больше ядер, больше мегапикселей, больше камер,… :D
У Эппла какая-то другая физика, или просто 5нм? :)
2. Ну если у вас есть процессор, который УЖЕ умеет все это, просто для трех команд в параллель, то как вы думаете, сложно ли переделать его, чтоб он делал то же самое для восьми? Ответ: это просто. Сделать так, чтоб при этом он не стал работать медленнее и жрать сильно больше — гораздо сложнее. Верифицировать это все — еще сложнее (но не думаю, что Эппл покажет Errata на этот чип :D )
3. Подождите, причем здесь смартфоны? Мы говорим про НОУТБУЧНЫЙ проц! Не видел ни одного хипстера в кофейне с самсунговским ноутом
4. Разработка дорогая. Один американский инженер стоит им как минимум $120к в год. Думаю, они делали этот чип минимум 2-3 года. Сколько народу работало — 100 или 1000 — я не знаю, но можете прикинуть сами. Плюс новый техпроцесс, который завсегда подкидывает проблем. Если бы AMD выпустил такой процессор, на нем должен был бы работать Windows и все игрушки.
Что касается того, что никто другой в индустрии такого сделать не может — это неправда. Western Digital, например, скупил у Оракла всю команду разработчиков OpenSPARC для своих новых RISC-V — я уверен, что они могли бы сделать такое. Интел мог бы, АМД мог бы, Самсунг мог бы, Квалкомм мог бы, ХайСиликон мог бы. Просто это дорого, и кроме Эппла никто не смог бы такой процессор монетизировать. Здесь уже маркетинг и экосистема важнее.
AMD серверные процессоры с ARM-овым декодером лет 10 назад стала разрабатывать — и что? Технически это вообще не проблема — тогда вопрос на засыпку: в чем же проблема? :)