Комментарии 70
Три аспекта, обсуждение которых хотелось бы видеть в статьях такого рода.
Я сейчас скажу страшное, но производительность ядра в TOPS уже давно не является единственной ключевой характеристикой. Масса задач упирается в подсистему памяти, и для них архитектура CPU не является критичной. А вот минимизация задержек и расхода места в кэшах, в т.ч. за счет более компактного кода у правильных CISCов - очень даже. И если с экономными процессорами ARM работать умеет, то насчет эффективной подсистемы памяти есть вопросы.
Вопреки утверждению автора, x86 в эмбеде вполне используется. Речь идет как о промышленной автоматизации, так и о честном эмбеде. Правда, этим зачастую занимается совсем не Интел - например, Тесла недавно подписала контракт с AMD, что-то делают и совсем третьи производители, которых на десктопе и в серверной не видно и не слышно.
Плюс, при взгляде на мобильный процессоры забыт еще один крайне важный аспект - встроенные ускорители. Речь идет как об ускорителях, оформленных в виде отдельных ядер (DSP для обработки видео/звука, тензорное ядро для ML, видеокодек, еще что-нибудь), так и о расширениях системы команд под задачу. На x86 с этим довольно тухловато.
А вот минимизация задержек и расхода места в кэшах, в т.ч. за счет более компактного кода у правильных CISCов — очень даже.
Интересно знать о каком именно CISC вы говорите.
AArch64 код компактнее чем у х86_64, раздутый за счёт префиксов и невыразительной ISA.
У «правильных» ARM-ов к тому же кэша гораздо больше и помещается туда в разы больше инструкций (у M1 192КБ L1I и 128КБ L1D).
И если с экономными процессорами ARM работать умеет, то насчет эффективной подсистемы памяти есть вопросы.
Какие вопросы? Со времён Cortex-A8/A9 расклад сильно поменялся.
У того же M1 недосягаемая для текущих х86 процессоров эффективность подсистемы памяти — одно ядро M1 Pro способно тянуть из памяти 102ГБ/c.
www.anandtech.com/show/17024/apple-m1-max-performance-review/2
Ядро у M1 может качать 58ГБ/c — легко забивает 100% интерфейса к памяти.
www.anandtech.com/show/16252/mac-mini-apple-m1-tested
Латентность обращения к кэшу L1 такая же (1ns).
На A15 в определённых условиях она может выполняться за 1 такт, т.е. в 3(!) раза быстрее чем у Интел.
Опять же L2 кэш 4-6 мегабайт на ядро. Против смешных 512Кб для конкурентов.
Современные ARM процессоры имеют ПСП 200ГБ-1ТБ/c. А в следующем году будет уже с ~2ТБ/c.
AArch64 код компактнее чем у х86_64, раздутый за счёт префиксов и невыразительной ISA.
Плюс-минус такой же, судя по имеющимся данным. Это при том, что сейчас x86 код крайне редко оптимизируют под объем. Но и объем AArch64 достигается за счет раздутой системы команд, что тоже не очень круто.
Какие вопросы?
Латентность, штраф протокола когерентности кэша, штраф блока страничной трансляции и в частнсоти промаха страничного кэша. Happy path оптимизировать нетрудно, только доминирующая парадигма ООП порождает довольно дурацкие паттерны доступа к памяти, которые к этому happy path имеют весьма отдаленное отношение. Опять же, объем кэша сам по себе не так уж много говорит, потому что его эффективность очень сильно зависит от организации.
Что касается голых циферок - я бы подождал, пока конкуренты выкатят мейнстримное предложение для DDR5 платформы.
Ядро у M1 может качать 58ГБ/c — легко забивает 100% интерфейса к памяти.
Это умеют все современные процессоры. Дурацкое дело нехитрое.
Плюс-минус такой же, судя по имеющимся данным.
Из того что я замерял, на AArch64 часто получается меньше инструкций и сравнимый размер или меньше.
Может мне просто везёт?
Напомню, вы утверждали про более компактный код у правильных CISC.
в т.ч. за счет более компактного кода у правильных CISCов — очень даже
Вы так и не назвали ни одного.
А как насчёт THUMB2, RV32C и т.д.?
Но и объем AArch64 достигается за счет раздутой системы командРаздутой в каком именно месте?
С какого это момента выразительная ISA вдруг стала считаться «не очень круто»?
В чём негативный момент для программиста?
Речь идёт не о захламлении пространства команд неиспользуемыми инструкциями. Например SVE не отменяет NEON. В каких-то местах выгоднее использовать именно NEON. И делать это можно одновременно. Совсем другая ситуация чем с MMX/SSE/AVX, которые дублируют функциональность друг друга (MMX так вообще мёртвый груз) и использование их вместе сопряжено с пенальти.
Латентность, штраф протокола когерентности кэша, штраф блока страничной трансляции и в частности промаха страничного кэша.
По ссылкам, которые я привёл, вы могли ознакомиться с данными измерениями (кроме «штрафа протокола когерентности кэша»).
только доминирующая парадигма ООП порождает довольно дурацкие паттерны доступа к памяти
И тут в дело вступает MLP.
lemire.me/blog/2018/11/13/memory-level-parallelism-intel-skylake-versus-apple-a12-a12x
Конечно эти процессоры старенькие, но Интел до сих пор не достиг уровня A12 (40 fill buffers):
fuse.wikichip.org/news/6111/intel-details-golden-cove-next-generation-big-core-for-client-and-server-socs
increased the fill buffer to 16 to support more misses.
Что касается голых циферок — я бы подождал, пока конкуренты выкатят мейнстримное предложение для DDR5 платформы
Постой паровоз, не стучите колёса(с)
M1 работает с LPDDR4X.
Это умеют все современные процессоры. Дурацкое дело нехитрое.Это мягко говоря неправда. К чему эти оправдания?
www.7-cpu.com/cpu/Ice_Lake.html
RAM Read B/W (Parallel Random Read) = 6 ns (or less) / cache line
RAM Read B/W (Read, 16-64 Bytes step) = 24-25 GB/s
RAM Read B/W (Read, 64 Bytes step — pointer chasing) = 18 GB/s
RAM Write B/W (Write, 8-64 Bytes step) = 18 GB/s
ark.intel.com/content/www/us/en/ark/products/196597/intel-core-i71065g7-processor-8m-cache-up-to-3-90-ghz.html
Max Memory Bandwidth: 58.3 GB/s
www.anandtech.com/show/14605/the-and-ryzen-3700x-3900x-review-raising-the-bar/2
Deeper into the DRAM regions, however we see that AMD is still lagging behind Intel when it comes to memory controller efficiency, so while the 3900X improves copy bandwidth from 19.2GB/s to 21GB/s, it still remains behind the 9900K’s 22.9GB/s. The store bandwidth (write bandwidth) to memory is also a tad lower on the AMD parts as the 3900X reaches 14.5GB/s versus Intel’s 18GB/s.
ark.intel.com/content/www/ru/ru/ark/products/186605/intel-core-i99900k-processor-16m-cache-up-to-5-00-ghz.html
Макс. пропускная способность памяти: 41.6 GB/s
Производительность STREAM Triad с разным количеством потоков можно посмотреть тут:
www.anandtech.com/show/16529/amd-epyc-milan-review/4
----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----
qw1
Ответ на habr.com/ru/company/selectel/blog/592749/#comment_23791627
Карма не позволяет ответить на два поста. Так что придётся объединить.
Насколько я знаю, байты самих опкодов никто не кеширует.
«Не кешируют» не только лишь все(с)
МОП кэши используют всего несколько компаний-разработчиков процессоров.
Intel начиная с SandyBridge (впрочем сюда можно причислить P4 трейс-кэш)
AMD Ryzen.
ARM Cortex-A77 и последующие.
Apple не использует МОП кэш. У них классический fetch 8 инструкций за такт.
Почему так? Потому что МОП кэш это лишь средство сделать fetch/decode более эффективными, но он имеет свои ограничения.
llvm.org/devmtg/2016-11/Slides/Ansari-Code-Alignment.pdf
Когда-то давно разделили кеш на инструкции и данные, а чуть позже в кеше инструкций вместо байтов стали хранить декодированные микрооперации.
У вас наверное и ссылка есть, чтобы подтвердить ваши утверждения? =)
Максимум там может хранится информация предекодера — маркировка длин инструкций в случае х86 (и совершенно бесполезная для RISC).
В L1I хранится оригинальные инструкции, потому как в х86 можно сделать JMP в середину инструкции.
Если же вы говорите про МОП кэш, то он установлен не вместо L1I, а это отдельная структура. При отсутствии кода в МОП кэше, инструкции читаются из кэша инструкций, а оттуда уже попадают в декодеры и потом наконец в IDQ (allocation queue).
en.wikichip.org/wiki/intel/microarchitectures/sunny_cove
Как вы видите кэш инструкций находится в самом начале конвейера.
DSB (МОП кэш) это лишь опциональный источник микроопераций.
И более того, МОП кэш может содержать только то, что есть в L1I:
stackoverflow.com/questions/67011520/is-the-l1-dcache-the-ultimate-data-cache-and-is-dsb-also-a-cache-that-can-be-sim
The L1i cache is inclusive of the uop cache. The uop cache is virtually-addressed, so TLB lookups aren't needed. But it has to be evicted on TLB invalidation as well, I guess.
И тут уже их размер и плотность от фронтендовой архитектуры не зависит.
Зависит и ещё как. В МОП кэше лежат не какие-то инструкции абстрактной ISA, а вполне конкретные МОП-ы х86.
ark.intel.com/content/www/ru/ru/ark/products/186605/intel-core-i99900k-processor-16m-cache-up-to-5-00-ghz.htmlОдно замечание: это на указанном в спецификации типе памяти, Для 9900K — 2666 мгц, в то время как там и за 4000+ уйти не то чтобы трудно.
Макс. пропускная способность памяти: 41.6 GB/s
AIDA рисует у всех современных процессоров AMD и INTEL (на памяти с частотами 3200 и выше) чтение и запись выше 50GB\s, обычно ближе к 60. Только у одночиплетных AMD запись, вроде, проседала. Но возможно исправили в 5XXX, я не следил.
Интересно знать о каком именно CISC вы говорите.
AArch64 код компактнее чем у х86_64, раздутый за счёт префиксов и невыразительной ISA.
Это просто неправда. x86 ISA многократно более выразительна на инструкцию, хотя бы потому, что не ограничена load-store. Другое дело, что компиляторы не умеют ею пользоваться и полностью возможности по уплотнению кода не раскрывают, в отличии от примитивного в этом смысле ARM. Просто поищите, что люди делали на эту тему, я за вас этого делать не буду (и нет, на слабо меня вы не разведете)
Это мягко говоря неправда. К чему эти оправдания?
Действительно, к чему. Ширина шины между L2 и L3 в современных x86 - как раз 400 Гб/с плюс-минус, а вот латентность сильно ниже. И до памяти у современных x86 латентность ниже. Ну не шмогла Эппл в кэш L3 и латентность, пришлось продавать широкую шину - которую так и так пришлось делать для видеоядра.
M1 работает с LPDDR4X.
Чип с ограничением в 16 Гб оперативки по нынешним временам годится только в мобилки и ноуты начального уровня, в приличный ноут и тем более в десктоп уже не годится. Поэтому я не вижу смысла обсуждать этот огрызок. 64 Гб от M1 Max еще туда сюда, и то для хай-эндовых рабочих станций может хотеться побольше.
Это просто неправда, x86 ISA многократно более выразительна на инструкцию,
Только вот программы (к вашему сожалению) обычно состоят более чем из одной инструкции.
Впрочем, давайте посоревнуемся в выразительности =)
BICNE R0,R1,R2,ROR R3
Т.е. r0 = (smth != 0)? (r1 & ~(rotate_right(r2, r3))): r0
mov ecx, ebp
ror eax, cl
not eax
and eax, edx
test edi, edi
cmove eax, esi1 инструкция на 4 байта против 6 на 13 байт.
Где же ваши примеры? Давайте, выкладывайте что у вас есть. Небось тангенс какой-нибудь с х87 сопроцессора? =)
Просто поищите, что люди делали на эту тему, я за вас этого делать не буду (и нет, на слабо меня вы не разведете)
Ахаха. Отличная аргументация. Поищи то, не знаю что(с)
Не будете? Вы хоть одну ссылку привели? Вы для меня ничего не сделали, так зачем этот угрожающий тон?
Вы хоть можете объяснить толком, что мне искать?
Если вы не заметили, мои утверждения основаны на личном опыте и/или подтверждены ссылками на экспертов. Я так привык.
Мне не сложно найти нужную информацию.
Если вы голословно что-то заявляете, извольте это подтвердить. Лично вы что делали?
Ширина шины между L2 и L3 в современных x86 — как раз 400 Гб/с плюс-минус, а вот латентность сильно ниже.
Я вам дал несколько ссылок на измерение ПСП. Измерения наглядно показывают, что одно ядро не способно вытянуть и 50% ПСП. Какие ваши доказательства(с)?
Теперь давайте проверим ваши голословные утверждения. (Где ссылки?)
en.wikichip.org/wiki/intel/microarchitectures/ice_lake_(client)
Ring Clock — The frequency at which the ring interconnect and LLC operate at. Data from/to the individual cores are read/written into the L3 at a rate of 32B/cycle operating at Ring Clock frequency.
Ring Clock меньше или равен частоте процессора.
Т.о. максимальная скорость чтения или записи в L3 не может быть больше 5ГГц*32Б = 160ГБ/с
myth busted©?
И до памяти у современных x86 латентность ниже.
До DDR4 меньше, а вот до LPDDR4, которую использует Apple, точно такая же или хуже.
Перейдём к моей любимой рубрике — пруфам:
1065G7 — 130нс (ага, ниже некуда)
1185g7 — 98нс
www.anandtech.com/show/16084/intel-tiger-lake-review-deep-dive-core-11th-gen/4
M1 — 96нс
www.anandtech.com/show/16252/mac-mini-apple-m1-tested
myth busted©
Ну не шмогла Эппл в кэш L3 и латентность, пришлось продавать широкую шину — которую так и так пришлось делать для видеоядра.
WAT? SLC выполняет другую роль в Apple Silicon — он используется для связи всех блоков внутри чипа. Процессор работает с огромным L2. Ему не сильно нужен третий. Причём тут вообще видеоядро?
в приличный ноут и тем более в десктоп уже не годится
У меня «неприличная» модель с 8ГБ. Хватает за глаза.
Как это связано с быстродействием процессора? Да никак.
Поэтому я не вижу смысла обсуждать этот огрызок.
Напомню, что мы обсуждали плотность кода и производительность.
Ядра M1 и M1 MAX используют одинаковые.
К объёму памяти это никак не относится.
Так что мне кажется, что у вас пригорает от другого =)
У чипа PS5, который кастомный ASIC на базе AMD ZEN пропускная способность к памяти — >440 Гб/с. Т.е. как минимум AMD в широкую полосу к памяти оч. хорошо умеет.
Эта ПСП для GPU. Данный SoC не только можно купить отдельно (с отключенным GPU), но можно даже найти результаты тестирования ПСП.
www.tomshardware.com/reviews/amd-4700s-desktop-kit-review-ps5-cpu/4
К сожалению однопоточного доступа нет, но в многопотоке он может вытянуть лишь 17% от физически доступной ПСП.
Так что опять ваши голословные утверждения не подтвердились :)
Более того, в отличии от NVidia видюхи AMD тоже имеют не очень-то широкую шину памяти — и все равно остаются вполне на уровне. Так что не все упирается в пропускную способностью.
ПСП у GPU и CPU это две большие разницы(с)
Не нужно их смешивать.
Современные GPU AMD опираются на огромный кэш с большой ПСП.
> BICNE R0,R1,R2,ROR R3
Этот пример откровенно ни о чём по двум причинам:
1) Это для ARM/32. Контекст статьи относится к ARM/64, захват вероятно уползающего от Intel рынка серверов, возможный возврат на телефоны. В ARM/64 (AArch64) вам придётся сделать или условный переход, или CSEL. Одной команды уже не будет.
2) Компиляторы такую команду вряд ли сгенерируют. Попробуйте найти пример генерации такой команды в GCC или Clang, пусть для ARM/32… что-то я сомневаюсь.
Даже если несколько мелких кусков критических путей будет написано на ассемблере, 99.99% кода сгенерировано компиляторами. По объёму кода, количеству команд и т.п. надо ориентироваться только на их выхлоп. Та же RISC-V уже изначально строится по принципу «делаем команды, чтобы LLVM легче генерировал». Поэтому я приводил рядом пример с компиляцией.
> Где же ваши примеры? Давайте, выкладывайте что у вас есть. Небось тангенс какой-нибудь с х87 сопроцессора? =)
См. рядом. Если хотите, могу повторить цифры, взяв что-то с известным кодом, но нужно, чтобы не имело серьёзной системной привязки (типа графики) и компилировалось одним куском (если много мелких плагинов, будут потери на секции связи и всё такое), давайте кандидатов.
> Если вы не заметили, мои утверждения основаны на личном опыте и/или подтверждены ссылками на экспертов. Я так привык.
Только вот неуместное упоминание команды 32-битного ARM в этом контексте всё портит.
Чтоб полностью закрыть вопрос пропускной способности.
У чипа PS5, который кастомный ASIC на базе AMD ZEN пропускная способность к памяти - >440 Гб/с . Т.е. как минимум AMD в широкую полосу к памяти оч. хорошо умеет. Но на десктоп этого не тянет - не спроста же? Более того, в отличии от NVidia видюхи AMD тоже имеют не очень-то широкую шину памяти - и все равно остаются вполне на уровне. Так что не все упирается в пропускную способностью.
Чем меряли и как? Мой результат не так давно. AArch64 код толще, чем x86, на 1%. (Код под NDA, но какие-то характерные куски могу подпольно показать. Надо подумать и выбрать freesource эквивалент.)
По ассемблеру можно понять, за счёт чего так происходит — несмотря на префиксы, «невыразительную ISA» и так далее, очень много коротких команд у x86, в 2 байта или около того. А всякие push/pop/ret многие вообще по байту :)
> Современные ARM процессоры имеют ПСП 200ГБ-1ТБ/c. А в следующем году будет уже с ~2ТБ/c.
Думаете, Intel не догонит?
минимизация задержек и расхода места в кэшах, в т.ч. за счет более компактного кода у правильных CISCовНасколько я знаю, байты самих опкодов никто не кеширует. Когда-то давно разделили кеш на инструкции и данные, а чуть позже в кеше инструкций вместо байтов стали хранить декодированные микрооперации. И тут уже их размер и плотность от фронтендовой архитектуры не зависит.
Это всё фантазии. План Интела примерно такой:
Слиться в борьбе с АМД на рынке десктопных процов и датацентров
Слиться в борьбе с Apple на рынке ноутбуков и смартфонов
Слиться вообще и тихонько умирать следующие 20 лет, еле-еле держась на поставках железа и обновлений таким же умирающим компаниям-динозаврам, где 80-летние ИТ-директора помнят, что "Интел - это круто".
В этот момент их купят китайцы (привет, IBM-Lenovo) и будут под брендом Интел клепать всякую дичь (а может и не дичь).
Единственно верный способ выжить (перейти на ARM) им не позволит гордость, а все остальные пути - только в могилу.
Возможно выпуск "alder lake ultra mobile" как-то сдвинет эту "борьбу" с мертвой точки?
Поскольку Intel не может поставлять чипы на важный рынок планшетов и смартфонов
Со смартфонами - да, не вышло, а вот с планшетами вполне. Серия Surface и мелкие прочие - тому доказательство. Энергоэффективность оставляет желать лучшего. Но если сравнивать планшет с Intel на Windows и ПК - возможности сравнимы. В то же время iPad и MacBook имеют существенно разные возможности.
Спекуляция в чистом виде. Предположим, что на рынке появятся устройства от Intel c не x86 архитектурой. И тут возникнет толстый вопрос. С какой математикой можно будет эксплуатировать подобные железяки. Ответ на этот вопрос могут дать компании Googe, Apple или Microsoft. Или у Intel есть некий туз в рукаве?
Ничего не понял, вы про какую математику?
Анекдот в том, что а) такие устройства были (у интел была линейка i860, XScale) и б) есть сейчас (под эгидой Интела выпускаются разнообразные FPGA SoC с ARMами)
С какой математикой можно будет эксплуатировать подобные железяки
Всмысле, что на них можно будет выполнять?
Ну тут все просто - сначала эмуляция x86, потом продвижение в массы и поддержка разработчиков нативного софта. Все как у Apple, как же ещё?
Apple является разработчиком собственных ОС, и может подобные стратегии реализовывать. Intel в части ОС зависит от Microsoft в первую очередь. В тот момент когда они начнут продвигать устройства с альтернативной архитектурой без MS на рынок ПК, они начнут конкурировать сами с собой, вытесняя с рынка собственную продукцию x86. При падении спроса на традиционные ПК это, конечно, может случиться, но пока мы видим рост продаж ..
Андроид. Опять правда придется транслятор писать из ARM в эту архитектуру для бинарного кода. но для x86 же делали. Правда нужна поддержка Google.
Windows. как бы поддержка архитектур других есть. Правда учитывая что с ARM-версией творится (даже транслятор x86 поддержку x64 получил не так давно) — выглядит странно. Ну и убедить разработчиков что им оно — надо будет сложно. И нужна поддержка MS.
Linux. тут просто. Но Linux-на-десктопе ой мало места занимает.
Любую. Если пойти примерно путем Эльбруса и воткнуть транслятор x86 в firmware и запускать поверх него что угодно, да возможность переходить в "нативный" режим. Но большие требования к быстродействию железа а также сложный транслятор (придется x86 поддерживать целиком, та же Rosetta 2 например совсем не все поддерживает, из-за чего пока что не слышно например про поддержку x86 в vmware fusion/parallels desktop на m1)
Дело не в максимальной производительности, а в производительности на Вт, об этом и надписано в тексте.
AWS выбрали то, что выгоднее, а значит x86 проиграл и потерял долю у гигантского клиента серверных CPU. И потеряет еще больше — уже вышел Graviton3.
Рынок оценивается не по стоимости устройства, а по выручке со всеми устройств. И рынок мобильных SoC гигантский по сравнению с десктопами и серверами.
Скаэем так, GPGPU сейчас не на острие. Недаром AMD решила купить Xilinx, да и Intel про свой FPGA бизнес не забывает.
В больших чипах да, об этом сказано в посте.
Это ж насколько надо было не договориться с AWS, что они ввязались в собственную разработку. Похоже что у AMD и Intel что то совсем не так.
Все равно он больше и быстрее растёт чем прочие рынки CPU. А про дата центры смотри пункт 2:)
Это ж насколько надо было не договориться с AWS, что они ввязались в собственную разработкуНичего удивительного. Амазон мог заявить: лицензируйте нам архитектуру, на условиях, как это делает ARM, или ещё выгоднее. AMD & Intel, конечно, на такое не согласны. Амазону же, с его масштабами, выгоднее производить свои чипы и не платить маржу всей цепочке производства. Прибыль за всякие наценки на бренд у себя останется.
Дело не в максимальной производительности, а в производительности на ВтДа что ж вы так за производительностью за единицу электроэнергии носитесь-то?! Эта величина имеет смысл только при равной производительности в первую очередь, ведь если процессор X потребляет в 10 раз меньше за операцию чем Y, но выполняет в 100 раз меньше операций в секунду — он всё равно в 10 раз хуже Y. Просто потому что вы процессор ставите чтоб считать, а не энергию экономить, и для одних и тех же расчётов вам понадобится аж 100 X вместо 1 Y (хоть и уйдёт всего 10 X энергии).
Вообще-то, нечто подобное есть. Сравните STM32F7 с STM32L4, плата за в разы меньше потребление - в разы меньшая производительность.
На самом деле техпроцессы у высокопроизводительных и энергоэффективных CPU одного класса, обычно, не отличаются. Транзисторы те же. Другое дело, что если в высокопроизводительных CPU часть транзисторов отвечают за повышение быстродействия (например, спекулятивное исполнение команд), то в энергоэффективных - за отключение питания неиспользуемых блоков и отказ от спекулятивного выполнения, как необоснованного расхода энергии.
Например, имеем такой код:
x = (f(a)>f(b)) ? a/b : a*b;
Высокопроизводительный CPU может выполнить обе операции умножения и деления параллельно еще до того, как будет определено, что нужно было выполнить только одну из них. Энергоэффективный CPU станет умножать или делить только после вычисления выражения f(a)>f(b), чтобы не тратить энергию на спекулятивные операции.
то это значит, что пачка первых процессоров
Потребует еще и пачку материнок, оперативки, БП, мест в стойке, охлаждения и прочей обвязки, что помножит на ноль всю вашу экономию + еще и расходы на обмен данными между кучей CPU.
Как говорится «100 фонариков не заменят 1 прожектор».
Дело не в максимальной производительности, а в производительности на Вт, об этом и надписано в тексте.
Если процессор в принципе не может справиться с какой-то задачей (не хватает максимальной производительности) — то уже безразлично на сколько энергоэффективно он не справляется.
О соревнованиям по производительности на Вт (в рамках ПК и серверов, а не носимых обрубков) стоит задумываться после достижения идентичной пиковой производительности, ИМХО. Ибо вариант «наш CPU слабее, но ест меньше» равносилен формулировке «наш CPU как младшая линейка CPU конкурента».
Да и в носимой — розетки и павербанки никто не отменял. Ибо если телефон/ноутбук у играющего человека энергоэффективно тормозит вместо того, чтобы выполнять свою задачу несмотря на жор батареи — пользователь будет куда более недоволен т.к пофиксить производительность ему будет куда сложнее чем воткнуть в розетку кабель питания.
Ага, но в этом то и идея. Что начинаем с маломощных но эффективных процов. Потом прокачиваем их мощность масштабируя ядра сохраняя эффективность. И получаем монстра типа M1max
Абсолютно верный комментарий. Плюс в статье есть множество других фактических ошибок, из которых следуют неверные выводы. Но главную суть вы изложили в данном комментарии совершенно чётко, на мой взгляд.
Например какие ошибки?
Следующие:
Подсказкой к тому, что замышляет Intel — это попытка приобретения SiFive. Компания выложила 2 миллиарда долларов на стол, но этого оказалось недостаточно
Это утверждение основано лишь на слухах, которые могут быть вообще далеки от реальности. Например, от людей из недр кремниевой индустрии я слышал ровно обратное мнение - что это SiFive пытается продаться и потому проводит такого рода пиар компанию.
x86, по сути, является устаревшим CISC-чипом
Когда вы делаете миниатюрные и более простые чипы, избыточность x86, выраженная в количестве транзисторов, становится более значительной частью от общего количества
Это неверно. x86 является вполне себе нормальным чипом. Они вполне могут делать на нём процессоры на все ниши, включая мобильный рынок, где некоторое усложнение декодера принципиально ни на что не влияют (у Arm, кстати, есть тоже всякие сложности в декодере, заключающиеся в поддержке Thumb и legacy Armv7, например). Проблема тут именно рыночная - это низкомаржинальные продукты, что плохо в текущую бизнес модель Интела вписывается (о чём автор изначального комментария абсолютно верно упомянул)
Никто из действительно крупных производителей чипов еще не использует RISC-V.
Использует. Nvidia, например.
Если вы посмотрите, например, на процессор Cortex-A5 ARM и сравните его с процессором RISC-V Rocket с аналогичным кэшем и производительностью, размер кристалла RISC-V окажется в два раза меньше, чем у процессора ARM. Затраты на чип растут вместе с квадратом площади чипа. Таким образом, при том же объеме производства чип RISC-V будет в 4 раза дешевле, чем ARM
Это некорректное сравнение. Тут долго расписывать подробности, но скажем так, легко найти бенчмарки, где Cortex-A5 будет разрывать Risc-V ядро. Тут просто есть некоторое фундаментальное заблуждение, что архитектура Risc-V как-то принципиально лучше, чем Arm. Но по факту это обе Risc архитектуры. И по мере взросления Risc-V его характеристики по площади будут приближаться к Arm-овским. Преимущество Risc-V именно в бизнес-модели, а не в каких-то технических вопросах в первую очередь.
Как RISC-V достигает этого? 32-разрядный ARM имеет около 500 команд, в то время как 64-разрядный ARM имеет уже около 1000 команд. RISC-процессор со всеми наиболее типичными функциями обладает всего 122 инструкциями (RV32G). Почему так мало? RISC-V основан на расширениях. Минимальный процессор RISC-V должен поддерживать всего 47 инструкций
Собственно, это в догонку к предыдущей реплике. Это может иметь значение для каких-то микроконтроллеров, но для более-менеее серьёзных чипов всё вышенаписанное имеет минимальное значение.
Esperanto Technologies создает большие чипы для машинного обучения на основе множества ядер RISC-V. Чтобы втиснуть много ядер, которые могут работать параллельно, нужно, чтобы они были по архитектуре простыми и с низким количеством транзисторов
Главное преимущество RISC-V ядер от Эсперанто для AI - в специализированном векторном расширении для AI в каждом ядре. В качестве самого ядра там ещё более выгодно взять минималистичное своё ядро. Ну т.е. RISC-V само по себе мало причём, в данном случае это больше маркетинг
RISC-V имеет важные преимущества, которые позволят Intel конкурировать на рынке встраиваемых систем и не конфликтовать с x86
RISC-V по своей сути конфликтует с x86. Развивать конкурента для Интел просто бессмысленно
Коротко напишу автору о его заблуждениях.
Единственный адекватный тест производительности это Xmrig Benchmark Единственный полезный а не синтетический.
Так как это реальные деньги а не синтетические попугаи.
Это своеобразный аналог суперкомпьютерного Linx.
И что же показывает в нем АПЛ М1?
2300!!! При 17Вт мощности. И это на 5нм, Карл.
Это уровень младших Райзенов, таких как Ryzen 3 или Ryzen 5 1600 старых поколений сделанных по 7нм.
Новые десктопные Ryzen 9 5900 более 15000 дают. Вот где мощь и сила. В 6-7 раз больше. При 100-120Вт.
Вот она дутая РЕАЛЬНАЯ мощь процев Apple M1 и их реальная энергоэффективность.
Ничуть не лучше современных топовых процессоров.
Видео же кодируется не процем а спец кодеком вшитым в кремний. Он либо вшит либо нет. Это узкоспециализированная ASIC задача.
Например мой пред топовый Ксиаоми с 865 драконом даёт в тесте xmrig всего 600. Вот она истинная мощь ARM)))
Так что снимайте очки. Никаких реал преимуществ ни в силе ни в эффективности у ARM и М1 перед х86 не было и не будет.
Там только процы малой мощности до 5Вт клепать лучше получается.
И не сравнивайте их с ноутбучными Core i7 i9 ИТП. Во первых процы Интел это мусор. А у ноутбучных от i7 там название только.
Сейчас лидер это AMD Ryzen.
Поток сознания в котором я ничего не понял =)
На всякий случай уточню, я правильно понял что результаты JetStream 2, geekbench 5, cinebench r23 или тестовый проект в том же самом blender, вообще ничего не показывает?
И еще, я конечно не доктор но не уверен что xmrig, про который вы писали, собран корректно под m1, но даже если допустить что данные корректны то сравнение с Ryzen 9 5900 как минимум не корректно, вы сами пишете про большое отличие в tdp, и даже при такой разнице если отбросить в сторону стоимость железа m1 получается выгоднее по потреблению электроэнергии, кстати если уж сравнивать то тот же Ryzen 7 2700X выдает всего 6000 в этом тесте при тдp за сотню.
Или тот факт что на air m1 идут виндовые игры через виртуалку с виндой, лучше чем на моем старом ноуте от xiaomi c 4 ядерным 8 поточным i5 и диcкретным gpu от nvidia.
А насчет asic вы уж извините за прямоту какая разница как они это реализовали, если это нормально работает.
Да насколько я помню у intel тоже декодирование видео идет аппаратно, это вроде как минимум последнии лет 10 достаточно распространено.
Чем хороши числодробилки, вроде монеро майнинга, так это как раз грубой силой. И эппловский процессор находится где-то на уровне i7-3770k . Да, это безумно круто для мобильного процессора. Но это совершенно не "топ из топов, среди всех топов, которые только существовали на планете и эппл боги сделали лучшее из лучшего, как его представляют" ... И в этом плане, под мои программерские задачи у него нет абсолютно никаких преимуществ перед тем же моим Ryzen 1700x (который обладает шикарным показателем, мощность/$
Однако если мы будем рассматривать, не только числодробилки, но и более приземлённые вещи, аля базы данных, то кластер из 1700x справится с ними мало того, что лучше, так и ещё будет стоит на порядки дешевле.
И это не считая самого важного. Всё ещё нет адекватной поддержки Linux/BSD, т.е в реальной работе использовать M1 попросту нельзя. Даже если очень хочется.
По истории успеха x86 мы знаем, что побеждает не самый лучший. Поэтому делать ставку на "производительность на ватт" может быть не так разумно, как кажется. Здравый смысл в маркетинге мирового масштаба редко побеждал.
кстати и apple подозревают в переходе на risc-v в течении нескольких лет, они нанимают активно специалистов
Эээх.. А я еще помню времена, когда в Москве на мероприятиях Intel раздавали футболки с надписями типа "Процессоры RISC - это риск для вашего бизнеса!" :)
Стратегия Intel по нейтрализации ARM