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

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

Интересно было бы сравнить процессоры по их цене и энергопортеблению, ведь теоретически можно сделать многопроцессорную сборку, которая будет схожа по цене и энергопортеблению. Хотя при этом не совсем понятна цена процессора от Эппл, потому что его отдельно не продают.
Я правильно понимаю, что ЦП и ГП M1 сравниваются с ЦП i7-1165G7? Почему забыли, что у i7-1165G7 тоже есть ГП?
С ГП сравнивается только RTX. Все, что с Embree — это ЦП. Материал переводной, автор объясняет отсутствие сравнений с ГП i7-1165G7 тем, что у него нет поддержки DirectX или Vulkan для трассировки лучей.
Ок, спасибо
НЛО прилетело и опубликовало эту надпись здесь
а там где и х86 код был оптимизирован там и кратное отставание может быть, в 4е раза например.

Это где, например?

Ладно, сам отвечу. x86 в 4 раза (на самом деле в 3.4 раза) быстрее на процессоре i9-9920X с 12 ядрами и 24 потоками. В то время как у m1 — 4 производительных ядра. Так что в пересчете на ядро тут практически паритет.


Ядра m1 чуть медленнее десктопных ядер с неограниченным энергопотреблением, частотой и в два раза более широким SIMD (на самом деле в 4 и это приходится искусственно отключать!). Вот так маркетологи нас дурят.

Большинству пользователей абсолютно все равно, что вы считаете "маркетинговым пшиком", если в их задачах (а это обычно Web\Office\PS-Lightroom\реже Premiere\кодинг) все работает быстрее, чем у конкурентов.


Я не любитель маков, кстати, просто нужно быть корректнее в высказываниях и оценках.

Да вроде и не было секретом что вполне есть процессоры которые по числомолоченению — обгоняют M1.
Но:
— первое поколение
— в машинах низшего (для Apple) ценового сегмента
— потребление энергии

Вот очень интересно характеристики Mac Pro на M2/M3/Mна_чем_он_там_будет. С парой десятков ядер и потреблением не в 20 Вт а в 200.

Насчет оптимизаций — а ничего что на макос — часто подразумевается все же использование системных библиотек, которые и так уже оптимизированные либо оптимизация руками.
Может тогда и рейтрейсинг тестить везде без аппаратного ускорения?
ну какой-то тест несправедливый, взяли i7-1165G7 из другого ценового сегмента. У M1 и ядер в 2 раза больше и кэша.
У M1 и ядер в 2 раза больше и кэша.

У m1 — 4 производительных ядра, 4 энергоэффективных. У i7-1165G7 — 4 производительных ядра и гипертрединг. Примерно то на то и получается.


из другого ценового сегмента

Recommended Customer Price одного процессора $426
Цена всего mac mini целиком $700

Всё жду, когда человек, не согласный с моим комментарием и согласный с darkAlert выше, укажет, где я ошибся.

Я не "несогласный", но в России вроде макмини от 1+ К$

Ну, все же 4 ядра и 8 потоков хорошо если 25-33% дадут прибавку на один поток. То есть интел 4/8 это а-ля интел 6 ядер будет (смотреть intel 7700 vs 8600)
То есть честных 4 полуядра вполне себе могут выдавать лучше результат, чем дополнительных 4 потока, особенно с проблемами интела из-за уязвимостей, и зависит это больше от типа нагрузки.
С другой стороны, а что поделать, если интел лучше ничего не выдал)
Энергоффективное ядро имеет производительность 1/4 от большого.
и тем не менее, ядер 8, а не 4.
Цена за весь mac mini не показатель. Intel продает железо, а Apple — среду и услуги. Те же приставки так то тоже дешевле стоят чем могли бы.
и тем не менее, ядер 8, а не 4.

И тем не менее потоков одинаковое количество )


Вы изначально что хотели сказать? Что нужно сравнивать с одинаковым количеством ядер? Так их как раз одинаковое. Ну можно ради интереса ограничить там и там количество потоков четырьмя и получить значения на 20% меньше там и там.

Логических ядер одинаковое количество, физических — разное! Логическое ядро != физическому. Для меня это громадное различие между двумя CPU.
Потому сравнивать нужно CPU с идентичными характеристиками
Логическое ядро != физическому.

А высокопроизводительное ядро ≠ энергоэффективному. Их не 8, их 4+4.

вам бы так зарплату платили, как вы 4+4 железных ядра приравниваете к симуляции дополнительных ядер в виде 8 потоков на 4х ядерном процессоре.
И про приставки выше отлично дополнили :)
Нужно не потоки ограничивать, а ядра отключать. И не брать с потолка проценты, а тестировать. HT не эквивалентен ядрам, даже самым медленным. Он не добавляет дополнительных ALU и кэшей. 4 медленных ядра M1 это полноценные ядра со своими кэшами, ALU и регистрами. Поэтому сравнение неэквивалентно и только совсем далекий от железа человек может утверждать, что «потоков одинаковое количество».
Нужно не потоки ограничивать, а ядра отключать.

То есть это даст разный результат? ))


только совсем далекий от железа человек может утверждать, что «потоков одинаковое количество».

То есть их разное количество? ))

То есть это даст разный результат? ))

Это даст корректный результат, когда будет сравниваться четыре ядра с одной стороны и 4 ядра с отключенным HT с другой.

То есть их разное количество? ))

Т.е. это не оправдание некорректной методологии тестирования.
только совсем далекий от железа человек может утверждать, что «потоков одинаковое количество».

То есть их разное количество?

Могу еще раз повторить — Т.е. это не оправдание некорректной методологии тестирования.
Могу даже раскрыть — вы пытаетесь оправдать некорректную методологию тестирования с такими же некорректными результатами своей невежественностью, а именно «потоков одинаковое количество». Это не оправдание, это показатель, что вы не понимаете разницу между HT и big.LITTLE архитектурами. Равное количество потоков не делает эти архитектуры эквивалентными и достойными прямого сравнения.

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

Господи, пока я пытаюсь оправдать некорректную методологию невежественностью, вы не можете ответить на простой вопрос: количество потоков у них одинаковое или нет?


Никто ж не виноват, что у M1 нет HT, а это всего лишь функция для более эффективной утилизации одного физического ядра.

Как никто и не виноват, что у Интела нет энергоэффективных ядер.

Вот ты троль кнш. Гипертрудинг это фигня когда одно сильное ядро становится 2 слабыми. Был один поток который занимал 100% времени проца, стало 2 потока которые занимают по 60-70% от его мощей. Потому то сравнивать 4х ядерный проц с М1 ваще некорректно, даже если потоков и там и там одинаково.
Ахахх, это как сравнить фуфыкс с процом у которого есть реальные 8 ядер, а не 4х2 сечёшь?

Кста потому то интеловцы и начали воду мутить вокруг биглитл компоновки. Можно напихать 4х ядерных атомов и 4 ядерный ай7 и всё это будет работать как у тех вот армов без гипертрудинг и с тдп около 40Вт. И не надо будет делить одно сильное ядро на 2 слабых

одно сильное ядро становится 2 слабыми

Вообще не так. HT это когда у одного ядра продублированы все блоки, которые хранят состояние потока выполнения. Регистры, буферы, вот это все. Если один поток висит на кэш промахе и ждет ответа от медленной памяти, второй поток может вклиниться и в это время использовать простаивающие ALU. HT это про повышение КПД одного ядра. А нормальные ОС будут пытаться шедулить на физические ядра и только потом забивать остальные потоки.
Чувааак, там чисто технически нельзя это сделать вот прям 1 в 1. Для конвейерных алу, ок. А если другой поток в память попросится? Займёт инструкцию что порт залочит? А таблицу TLB тоже для каждых потоков свою делать? +Реордер от 2 потоков больше не станет. Потому эти лозунги фигня, я не знаю, может быть есть какие-то нюансы в программной части когда ты задаёшь потоки на уровне ОС. Но как сделать это аппаратно как ты и описываешь, я вариантов не вижу.
Ну может и можно, если ОС будет чередовать потоки, типо у нас на физ. ядре0 лог поток(лп)0 обрабатывается текущая задача, а на лп1 висит следующая, и когда квант времени лп0 подойдёт к концу лп1 поменяется на лп0 и продолжит работать почти без зависаний на полную мощность. А так оно типо висело в воздухе и ждало очереди понемногу выполняясь. Но разве HT так работает? Гуру в комментах есть?
Но то что HT в многопоточных приложениях неплохо себя показывает, это факт какб. Но надо ли оно нам? — другой вопрос
А если другой поток в память попросится?

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

А таблицу TLB тоже для каждых потоков свою делать?

Зачем?

В моем понимании HT это повышение КПД за счет переиспользования все той же OoO логики. Без HT эта логика может работать только в рамках одного потока. За счет дублирования фронтэнда мы можем пихать в нее еще один логический поток. Да, где-то может профита не получим, где-то станет хуже, а где-то получим прирост серьезный. Ну и ОС тут тоже не бессильны. Все современные версии знают об HT и понимают, что два логических потока все равно живут в одном ядре, а значит шедулить надо соответствующим образом.
А какое тут отличие от OoO выполнения?
Та вообще никакого для ядра, а для подсистемы памяти тот ещё геморой, это частично решает приколы с ассоциативностью. Но если грубо у тебя всёравно один 64КБ кэш становится 2 — 32КБ, что не есть хорошо.

Ну и в моём понимании HT(SMT) это ущербная хрень, я вижу профит только в одной её реализации — «как набор ждущих потоков», которых можно хоть по 8 штук на ядро пихать, главное чтоб у них был общие записи в TLB. В ином случае мы получаем невесь что, где-то быстрее где-то медленнее, но это всё «случаи» и 8 HT потока будут уступать реальным 8 потокам ибо SMT тупо делит ядро попалам если мы активно нагружаем ядро вычислениями. А так да, если не надо что-то срочно-обморочно считать, то SMT это мега дешёвый способ поднять производительность, тут какб притензий нет, всё шикарно.
**Если важна задержка в вычислениях, то тот HT что я видел даёт лишь геморой и настрой лезть в биос и отключачть его каждый раз когда ты запускаешь приложение что жрёт IPC а не паралелится на потоки.
Все эти новые тесты М1 напоминают мне один старый анекдот:

«Купили как-то суровым сибирским лесорубам японскую бензопилу.
Собрались в кружок лесорубы, решили ее испытать.
Завели ее, подсунули ей деревце.
«Вжик» — сказала японская пила.
«У, *ля...» — сказали лесорубы.
Подсунули ей деревце потолще. «Вж-ж-жик!» — сказала пила.
«Ух, *ля!» — сказали лесорубы.
Подсунули ей толстенный кедр. «ВЖ-Ж-Ж-Ж-Ж-Ж-Ж-ЖИК!!!» — сказала пила.
«Ух ты, *ля!!» — сказали лесорубы.
Подсунули ей железный лом. «КРЯК!» — сказала пила.
«Ага, *ля!!!» — укоризненно сказали суровые сибирские лесорубы! И ушли рубить лес топорами»

И мне почему-то он вспомнился))


Ну какой смысл Metal, если игры его не поддерживают, а скорость паритетна исполнению на ЦПУ?
А уж тем более когда на специализированной видеокарте все работает в тридцать раз быстрее?


Сколько Apple платит за эти статьи?

какой смысл Metal
Закрыть экосистему ещё сильнее?
Если это не так — они бы не стали выпиливать OpenGL/Vulkan, а добавили Metal как альтернативу (аналогично DirectX на Windows).

Уверен, что Metal будет выкинут на ту же помойку убогой проприетарщины и займет свое место рядом с FireWire и Sony Memory Stick

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

Да, но судьба этой проприетарщины — быть прослойкой между вулканом и железом.


MoltenVK is a layered implementation of Vulkan 1.1 graphics and compute functionality, that is built on Apple's Metal graphics and compute framework on macOS, iOS, and tvOS. MoltenVK allows you to use Vulkan graphics and compute functionality to develop modern, cross-platform, high-performance graphical games and applications, and to run them across many platforms, including macOS, iOS, tvOS, Simulators, and Mac Catalyst on macOS 11.0+, and all Apple architectures, including Apple Silicon.
От этого кому-то должно стать легче? Судьба этой проприетарщины быть единственным нативным и самым быстрым API для доступа к GPU. Все это остальное это обертки, которые призваны облегчить портирование с других платформ.
С учетом, что большинство людей напрямую с метал не работают, а пользуются движками и фреймворками, толку от этих оберток мало. У нас же помимо эпл есть еще консоли, где API тоже свои и никакими вулкан обертками там не пользуются. Адекватные движки умеют работать с разными API, чтобы и юзер не думал об этих проблемах, и производительность была максимальной. Все эти обертки удел скрипткидди, которым лень разбираться с другой платформой.
FireWire — это стандарт IEEE, он к поделкам типа Metal/Glide не имеет отношения.
Ну какой смысл Metal, если игры его не поддерживают
Ну и какой же API используют игры? Учитывая что на iOS другого нет? =)
Metal самый удобный API из претендующих на низкоуровневость.
В частности акселерацию вычислений для неигровых приложений делать легко,
в отличии от того же вулкана.

Да, но судьба этой проприетарщины — быть прослойкой между вулканом и железом.

Проще написать бэкенд для Metal чем разгребать глюки и тормоза в слоёном пироге Vulkan+MoltenVK.
А в чем выражается удобство Metal'а?
Статья о том, как после OpenGL ES все что угодно будет облегчением. Написано даже:
If you come from Direct3D or console world, you may take every single one of these for granted
Кстати, Vulkan в статье тоже упоминается — как технология, способствовавшая появлению полезных тулзов, которые Apple создать не удосужилась, так как это не способствует продвижению их вендорлокнутой проприетарщины.
На Вулкане писал, и большинство его сложностей вызваны кроссплатформенностью. То есть тем, чего в Apple никогда даже не пытались достичь.
«как технология, способствовавшая появлению полезных тулзов, которые Apple создать не удосужилась»
В каком месте такое утверждается?
Говорилось в контексте кроссплатформенных шейдеров. Но давайте обсуждать мух отдельно, а котлеты отдельно.

MSL основан на C++, что уже само по себе ставит его на уровень выше HLSL/GLSL.

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

Ага, и hello triangle в 1000 строк =)
Если для вас компактный код Metal является менее удобным чем полотнища Vulkan-кода, то могу только посетовать что у каждого свои тараканы в голове.

большинство его сложностей вызваны кроссплатформенностью

Metal работает на macOs и iOS, на IMR и TBDR GPU. Очевидно кроссплатформенность присутствует.

MSL основан на C++, что уже само по себе ставит его на уровень выше HLSL/GLSL.
Мне на GPU только этого «уровня выше» не хватало. Сейчас побегу выделять регистры на хранение таблиц виртуальных функций классов. Из C++ в языках шейдеров разве что шаблоны нужны.
Ага, и hello triangle в 1000 строк =)
И в каждой из 1000 строк содержится полезная для драйвера и GPU информация. Ну и да, вы профессионально разрабатываете hello world'ы, или мы о серьезных приложениях говорим?
Если для вас компактный код Metal является менее удобным чем полотнища Vulkan-кода, то могу только посетовать что у каждого свои тараканы в голове.
Во-первых, если Вы пишете простыни explicit Vulkan-кода вместо реализации и использования врапперов под Ваш конкретный случай — то на счет тараканов я с Вами согласен.
Во-вторых, Vulkan разрабатывался как API, минимизирующее неявные операции в драйвере. И кроме многословности, это также означает, что программист имеет значительно больше контроля над происходящим и может оптимизировать под свой случай те вещи, который в Metal'е реализованы втупую в драйвере. Вот например цитата из статьи:
still uses a traditional resource model where each resource has certain “usage flags” it has been created with but does not require pipeline barriers or layout transitions, and a traditional binding model where each shader stage has several slots you can freely assign resources to.
То есть, если я правильно понял, нормальных барьеров и таблиц дескрипторов в наличии нет.
А если все эти возможности не нужны, и заморачиваться не хочется — берите публичные врапперы, их полно, или вообще что-то вроде DX11onVk/GLonVk используйте, получите точно такой же компактный код. Возможно даже найдется враппер, мимикрирующий под Metal.
Очевидно кроссплатформенность присутствует.
Она присутствует настолько, насколько позволяет Apple, ведь набор железа и ОС, на которых Metal будет запускаться, полностью ими контролируется. Область применения Vulkan'а, очевидно, намного шире.
Из C++ в языках шейдеров разве что шаблоны нужны.

Иметь общий код между cpu и gpu очень полезно для акселерации.

если Вы пишете простыни explicit Vulkan-кода вместо реализации и использования врапперов под Ваш конкретный случай
Я понял, удобство — зло.
Ведь можно врапперов наделать на все случаи жизни =)

Я работаю с API гораздо более низкоуровневыми чем VK. И кода там бывает ещё больше, но с другой стороны API более лаконичный и приятный.

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

В теории имеет, ага. Учитывая зоопарк железа — под какой GPU оптимизируете?
Под TBDR железо ваш код нормально работает?

То есть, если я правильно понял, нормальных барьеров

Вопрос в том, а нужна ли конечному приложению морока с барьерами?
Если вы её делаете в своём слое абстракции, будет ли это быстрее?

и таблиц дескрипторов в наличии нет.

Есть argument buffers.
Не всё поддерживаемое мобильное железо Apple позволяет реализовать полноценный bindless подобно PC — там классический биндинг ресурсов.
developer.apple.com/metal/Metal-Feature-Set-Tables.pdf
Как можно убедиться, чипы до A13 имеют Tier1. Они не умеют индексировать argument buffers.
Тем не менее, несмотря на отличие железок, синтаксис идентичен и это удобно.

Иметь общий код между cpu и gpu очень полезно для акселерации.
Общий код можно худо-бедно, но иметь и на GLSL/HLSL. Непонятно, что именно из {C++ \ C} нужно (кроме шаблонов).
Я понял, удобство — зло.
Ведь можно врапперов наделать на все случаи жизни =)
Или взять уже готовые, интересно, почему Вы эту часть комментария проигнорировали. Суть в том, что с Vulkan'ом у меня выбор больше, чем с Metal'ом.
Под TBDR железо ваш код нормально работает?
Надо будет — будет нормально работать. Кстати, у Apple тут действительно все хорошо — мне нравится идея Tile Shader'ов, хотя кажется, что можно было бы и по-гибче; вангую их скорое появление в Vulkan'е. Только вот этот дизайн не очень согласуется с Вашей логикой — зачем пользователю морока с рендерпассами?
Общий код можно худо-бедно, но иметь и на GLSL/HLSL.

Зачем что-то делать лучше, когда «худо-бедно» уже есть?

Или взять уже готовые, интересно, почему Вы эту часть комментария проигнорировали.

А что тут комментировать?

Только вот этот дизайн не очень согласуется с Вашей логикой — зачем пользователю морока с рендерпассами?

Этот дизайн отражает принципы работы GPU от Apple.
Ждем чипов M1X и M2. Их производительность будет еще выше. Возможно в несколько раз. M1 это пионер. Ждать от него слишком многого не стоит. Как и покупать на его основе продукты, ИМХО. Опыт показывает, что Apple очень грамотно проводит работу над ошибками
Возможно в несколько раз.

Очевидно, что нет. Увеличится число ядер, добавятся новые сопроцессоры, что даст больше попугаев в специализированных задачах, но IPC существенно не вырастит. Эпл сейчас по IPC находится на уровне конкурентов и это с учетом более совершенного техпроцесса.
Эпл сейчас по IPC находится на уровне конкурентов

Не, ну если у вас своя математика, в которой 4.6 GHz у 5600X равно 3.2 GHz у m1, то конечно.

Ну, тут есть нюанс, что если реально 16 и 32 ядерные камни на подходе, как мне кинули ссылку в другой теме то:
В плюс к ядрам эпла идёт то, что частота у них одна и они на ней по-сути всегда работают с полученным максимумом на ядро и значит в многопотоке прибавят тоже сильно.
В то время как максимальная производительность на ядро у интела и амд != максимальной производительности каждого ядра при полной загрузке, а примерно равно производительности ядра при базовой частоте (ну чуть больше, если хорошее охлаждение). Пока M1 4б+4м — то он обыгрывает 4 ядерники конкурентов, но относительно 8 ядерников разговор идёт либо на поток, либо про энергию. 8+4 уже будет явно не сильно хуже (может и лучше) в многопотоке 8/16 амдшных. а 16 и 32 больших ядра, в случае их реальности… Ну, интелу точно ловить будет нечего на текущем этапе. АМД ещё явно есть чего отвечать и куда двигаться (5нм и увеличить количество ядер на чиплете в два раза, как уже было ранее).
частота у них одна

Это не так, даже m1 в корпусе без охлаждения тротлит.


Кстати, моя ставка что будет 12+4. Это:


1) Согласуется с утекшими бенчмарками
2) Легко объяснить покупателю (был 8-ядерный, стал 16-ядерный)
3) Согласуется с высказываниями инсайдеров, которые говорят «вы просто охренеете от следующего проца»

Если что-то тротлит, то это проблема охлаждения.
Так-то я возьму амд, выставлю ему тдп 150 ватт, поставлю суперкуллер и получу не базовую, а немного меньше бустовой на ядро. Просто это не заявленно стандартным режимом работы)
Кстати, моя ставка что будет 12+4
будут 12 ядерные (8+4 скорей всего) и 16 ядерные. Но:
For higher-end desktop computers, planned for later in 2021 and a new half-sized Mac Pro planned to launch by 2022, Apple is testing a chip design with as many as 32 high-performance cores.
В плюс к ядрам эпла идёт то

Это как раз таки минус. Одноядерный буст это возможность существенно повысить скорость однопоточной задачи за счет запаса по TDP. Постоянно работать на одной частоты это значит неэффективность использовать энергетический пакет. Вполне реально, что выше 3ГГц эпл физически не может разогнаться. Чисто по архитектурным причинам, а может и техпроцесс под это не оптимизирован.
Это как раз таки минус. Одноядерный буст это возможность существенно повысить скорость однопоточной задачи за счет запаса по TDP. Постоянно работать на одной частоты это значит неэффективность использовать энергетический пакет.

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


Вполне реально, что выше 3ГГц эпл физически не может разогнаться.

И так же вполне возможно, что это было осознанное решение, оставить максимум у 3.2 ГГц.
После выхода более мощных чипов можно будет уже делать какие-то выводы.

Например, если увеличение потребления с 5 до 10 Вт на ядро даст прирост скорости всего 10%, то это просто нерационально для портативных устройств, работающих от батареи.

Для этого буст настраивается каждым вендором индивидуально. Собственно, как это эпл делала с процессорами интел.
Это как раз таки минус.
Ну так, если они на стабильной частоте выдают ту же производительность, что у амд/интела в бусте, то это как раз — плюс. При равном количестве ядер, при загрузке их на 100% эпл будет работать на базовой=максимальной частоте, а амд/интел на базовой, которая заметно меньше бустовой.
А так можно вспомнить, что АМД ещё на zen2 догнали по количеству операций на такт Интел, но проигрывали в одноядреной производительности из-за несколько меньших частот. У эпл сейчас на такт явно лучше, просто частота меньше и да, соглашусь, что больших частот может и не быть. Ну так, на текущий момент им и этого хватит. Меня больше интересует вопрос успешности наращивания ядер ими.
это значит неэффективность использовать энергетический пакет.
Энергетический пакет эффективнее они стараются использвать через смалл ядра.
Энергетический пакет эффективнее они стараются использвать через смалл ядра

Я о другой эффективности — достижение максимальной производительности в рамках термопакета. Если задача однопоточная, а одно ядро сидит на своей базовой частоте и потребляет 20% термопакета, то фиговый это какой-то процессор. Намного лучше было бы включить буст, быстренько перемолоть эту задачу и усыпить ядра. У эпл банально наверное нет еще подобной системы. И можно не сомневаться, что будет.

Меня больше интересует вопрос успешности наращивания ядер ими.

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

Интересный вопрос, что они будут делать с подсистемой памяти и GPU. Их подход текущий не потянет полноценный GPU. Ему нужна в разы более быстрая память, если они собираются свое ядро использовать.
Намного лучше было бы включить буст, быстренько перемолоть эту задачу и усыпить ядра.
Что лучше — буст одного ядра с 4,4 до 5,1 ГГц у АМД или работа в базе на аналогичной производительности 4,9 ГГц амдшной на все, но без буста? Я чисто про это. У эпл ситуация, что при 3,2 ГГц сейчас производительность ядра выше базовых АМД, и если даже нет буста сейчас, то это не проблема — в одно ядро они сравнимы, а многопоточность при равном количестве ядер у эпл получится выше.
АМД останется только опять нарастить срочно ядер (реализуемо только на 5 нм)
Интересный вопрос, что они будут делать с подсистемой памяти и GPU. Их подход текущий не потянет полноценный GPU. Ему нужна в разы более быстрая память, если они собираются свое ядро использовать.
Думаю, что они уйдут от монолитного кристалла, чтоб не греть друг друга напрямую.

Но вообще, интел сам выкопал яму эту (в том числе ценниками), теперь пусть наслаждается.
Так а смысл рассуждать, что есть сейчас? Вот сейчас они пойдут на настольный рынок. Там буст это все. И если эпл опять будет сидеть на базовый частотах, то получится фигня. Буст был придуман для повышения скорости в условиях ограничений TDP и неравномерных нагрузок. У амд вон еще есть smartshift, который призван балансировать потребление GPU и CPU в целом, чтобы максимально утилизировать энергетический пакет. Это все необходимые функции для любого полноценного процессора. Эпл пока везет, что у нее есть форма в техпроцессе и закрытая экосистема. Она может пока сидеть и разрабатывать свою подобную систему.
Буст — это хорошо в маленьких задачах по времени. А вот сборка тяжелого проекта или рендеринг большой сцены — это задачи довольно продолжительные и буст тут не помощник. Лучше поддерживать производительность постоянную на среднем уровне или выше среднего, чем делать это «рывками» через буст
Не обязательно, у АМД и интелов буст может быть долгий, но в случае неполной загрузке по ядрам (если половина ядер загружена, например) и пока охлаждение справляется (отключаем лимиты на 3950x и наслаждаемся, как говорится).

Я лишь указываю, что у амд бустится выше эпла может только при ограниченном количестве потоков, а при полной нагрузке падают до базовой, на которой они будут слабее ядер эпла. Поэтому если эпл выкатит намного больше ядер на схожей частоте с текущими, но без буста отдельных ядер, то это вполне себе будет нормальное решение на уровне или выше конкурентов (при сходном с ними количестве ядер) — если в многопотоке каждое ядро не будет снижать свою производительность.
Их подход текущий не потянет полноценный GPU. Ему нужна в разы более быстрая память.

Или нет.


Современным GPU нужна в разы более быстрая память потому что они развивались определенным образом: у них всегда была более быстрая память и были API, которые её утилизировали.


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

который бы заставлял разработчиков как можно больше переиспользовать локальные кеши вычислительных блоков
Может я ошибаюсь, но будто бы единственный рабочий вариант заставить разработчиков не ходить лишний раз в общую память — это добавить больше задержек на общую память, что не выглядит хоть сколь-нибудь хорошо.
Современным GPU нужна быстрая память, потому что это единственное, что они делают. Читают память, молотят ее параллельно тысячами своих «ядер» и сохраняют обратно в память. Это устройства потоковой обработки в первую очередь. Им нечего переиспользовать, грубо говоря. Когда у тебя в памяти гигабайты вершин, индексов, текстур и рендер таргетов, то куда ты не сунься, но нужна широка шина у памяти.

Эпл ничего не добьется с текущей памятью. Ей либо придется выносить всю память наружу как на консолях и ставить GDDR. Либо ставить HBM на туже подложку. Других вариантов получить широкую шину вроде не придумано.
Сами ядра прокачают. Такое уже было неоднократно у Apple.

Эпл сейчас по IPC находится на уровне конкурентов и это с учетом более совершенного техпроцесса.


Тесты есть? Intel ушел в уг. А если и есть паритет с AMD, то важны именно специализированные задачи. В оптимизированных для M1 приложениях этот чип просто рвет и мечет

В оптимизированных для M1 приложениях этот чип просто рвет и мечет
Если бы он ещё и в оптимизированных под себя не рвал и не метал, был бы совсем позор
НЛО прилетело и опубликовало эту надпись здесь
Судя по ответам, автор той демки сам намутил какой-то свой raymarching на Metal и на OpenGL поверх Windows. Сейчас бы рендерить лучи самому, когда есть аппаратная поддержка, а потом говорить, что Mac на M1 лучше Ryzen + GeForce RTX.
Я не утверждаю, что M1 однозначно плох, но эй, зачем умные люди вам придумывают аппаратные ускорители? Чтоб вы всё равно сами писали?
Вы не понимаете, аппаратные ускорители можно использовать только процессорам Apple. /s
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.