Комментарии 74
Интересно было бы сравнить процессоры по их цене и энергопортеблению, ведь теоретически можно сделать многопроцессорную сборку, которая будет схожа по цене и энергопортеблению. Хотя при этом не совсем понятна цена процессора от Эппл, потому что его отдельно не продают.
Я правильно понимаю, что ЦП и ГП M1 сравниваются с ЦП i7-1165G7? Почему забыли, что у i7-1165G7 тоже есть ГП?
НЛО прилетело и опубликовало эту надпись здесь
а там где и х86 код был оптимизирован там и кратное отставание может быть, в 4е раза например.
Это где, например?
Ладно, сам отвечу. x86 в 4 раза (на самом деле в 3.4 раза) быстрее на процессоре i9-9920X с 12 ядрами и 24 потоками. В то время как у m1 — 4 производительных ядра. Так что в пересчете на ядро тут практически паритет.
Ядра m1 чуть медленнее десктопных ядер с неограниченным энергопотреблением, частотой и в два раза более широким SIMD (на самом деле в 4 и это приходится искусственно отключать!). Вот так маркетологи нас дурят.
НЛО прилетело и опубликовало эту надпись здесь
Да вроде и не было секретом что вполне есть процессоры которые по числомолоченению — обгоняют M1.
Но:
— первое поколение
— в машинах низшего (для Apple) ценового сегмента
— потребление энергии
Вот очень интересно характеристики Mac Pro на M2/M3/Mна_чем_он_там_будет. С парой десятков ядер и потреблением не в 20 Вт а в 200.
Насчет оптимизаций — а ничего что на макос — часто подразумевается все же использование системных библиотек, которые и так уже оптимизированные либо оптимизация руками.
Может тогда и рейтрейсинг тестить везде без аппаратного ускорения?
Но:
— первое поколение
— в машинах низшего (для 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 выше, укажет, где я ошибся.
и тем не менее, ядер 8, а не 4.
Цена за весь mac mini не показатель. Intel продает железо, а Apple — среду и услуги. Те же приставки так то тоже дешевле стоят чем могли бы.
Цена за весь mac mini не показатель. Intel продает железо, а Apple — среду и услуги. Те же приставки так то тоже дешевле стоят чем могли бы.
и тем не менее, ядер 8, а не 4.
И тем не менее потоков одинаковое количество )
Вы изначально что хотели сказать? Что нужно сравнивать с одинаковым количеством ядер? Так их как раз одинаковое. Ну можно ради интереса ограничить там и там количество потоков четырьмя и получить значения на 20% меньше там и там.
Логических ядер одинаковое количество, физических — разное! Логическое ядро != физическому. Для меня это громадное различие между двумя CPU.
Потому сравнивать нужно CPU с идентичными характеристиками
Потому сравнивать нужно CPU с идентичными характеристиками
вам бы так зарплату платили, как вы 4+4 железных ядра приравниваете к симуляции дополнительных ядер в виде 8 потоков на 4х ядерном процессоре.
И про приставки выше отлично дополнили :)
И про приставки выше отлично дополнили :)
Нужно не потоки ограничивать, а ядра отключать. И не брать с потолка проценты, а тестировать. HT не эквивалентен ядрам, даже самым медленным. Он не добавляет дополнительных ALU и кэшей. 4 медленных ядра M1 это полноценные ядра со своими кэшами, ALU и регистрами. Поэтому сравнение неэквивалентно и только совсем далекий от железа человек может утверждать, что «потоков одинаковое количество».
Нужно не потоки ограничивать, а ядра отключать.
То есть это даст разный результат? ))
только совсем далекий от железа человек может утверждать, что «потоков одинаковое количество».
То есть их разное количество? ))
То есть это даст разный результат? ))
Это даст корректный результат, когда будет сравниваться четыре ядра с одной стороны и 4 ядра с отключенным HT с другой.
То есть их разное количество? ))
Т.е. это не оправдание некорректной методологии тестирования.
только совсем далекий от железа человек может утверждать, что «потоков одинаковое количество».
То есть их разное количество?
Могу еще раз повторить — Т.е. это не оправдание некорректной методологии тестирования.
Могу даже раскрыть — вы пытаетесь оправдать некорректную методологию тестирования с такими же некорректными результатами своей невежественностью, а именно «потоков одинаковое количество». Это не оправдание, это показатель, что вы не понимаете разницу между HT и big.LITTLE архитектурами. Равное количество потоков не делает эти архитектуры эквивалентными и достойными прямого сравнения.
Может быть даже более справедливым было бы сравнение 4 больших ядер М1 с 4 интел ядрами с включенным HT. Никто ж не виноват, что у M1 нет 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 в многопоточных приложениях неплохо себя показывает, это факт какб. Но надо ли оно нам? — другой вопрос
Ну может и можно, если ОС будет чередовать потоки, типо у нас на физ. ядре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, чтобы и юзер не думал об этих проблемах, и производительность была максимальной. Все эти обертки удел скрипткидди, которым лень разбираться с другой платформой.
С учетом, что большинство людей напрямую с метал не работают, а пользуются движками и фреймворками, толку от этих оберток мало. У нас же помимо эпл есть еще консоли, где API тоже свои и никакими вулкан обертками там не пользуются. Адекватные движки умеют работать с разными API, чтобы и юзер не думал об этих проблемах, и производительность была максимальной. Все эти обертки удел скрипткидди, которым лень разбираться с другой платформой.
FireWire — это стандарт IEEE, он к поделкам типа Metal/Glide не имеет отношения.
Ну какой смысл Metal, если игры его не поддерживаютНу и какой же API используют игры? Учитывая что на iOS другого нет? =)
Metal самый удобный API из претендующих на низкоуровневость.
В частности акселерацию вычислений для неигровых приложений делать легко,
в отличии от того же вулкана.
Да, но судьба этой проприетарщины — быть прослойкой между вулканом и железом.
Проще написать бэкенд для Metal чем разгребать глюки и тормоза в слоёном пироге Vulkan+MoltenVK.
А в чем выражается удобство Metal'а?
Статья о том, как после OpenGL ES все что угодно будет облегчением. Написано даже:
На Вулкане писал, и большинство его сложностей вызваны кроссплатформенностью. То есть тем, чего в Apple никогда даже не пытались достичь.
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.
На Вулкане писал, и большинство его сложностей вызваны кроссплатформенностью.
Ага, и 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, то конечно.
НЛО прилетело и опубликовало эту надпись здесь
частота у них одна
Это не так, даже m1 в корпусе без охлаждения тротлит.
Кстати, моя ставка что будет 12+4. Это:
1) Согласуется с утекшими бенчмарками
2) Легко объяснить покупателю (был 8-ядерный, стал 16-ядерный)
3) Согласуется с высказываниями инсайдеров, которые говорят «вы просто охренеете от следующего проца»
В плюс к ядрам эпла идёт то
Это как раз таки минус. Одноядерный буст это возможность существенно повысить скорость однопоточной задачи за счет запаса по TDP. Постоянно работать на одной частоты это значит неэффективность использовать энергетический пакет. Вполне реально, что выше 3ГГц эпл физически не может разогнаться. Чисто по архитектурным причинам, а может и техпроцесс под это не оптимизирован.
Это как раз таки минус. Одноядерный буст это возможность существенно повысить скорость однопоточной задачи за счет запаса по TDP. Постоянно работать на одной частоты это значит неэффективность использовать энергетический пакет.
Когда это оптимальная точка на графике производительность за ватт, то очень даже плюс. Например, если увеличение потребления с 5 до 10 Вт на ядро даст прирост скорости всего 10%, то это просто нерационально для портативных устройств, работающих от батареи.
Вполне реально, что выше 3ГГц эпл физически не может разогнаться.
И так же вполне возможно, что это было осознанное решение, оставить максимум у 3.2 ГГц.
После выхода более мощных чипов можно будет уже делать какие-то выводы.
НЛО прилетело и опубликовало эту надпись здесь
Энергетический пакет эффективнее они стараются использвать через смалл ядра
Я о другой эффективности — достижение максимальной производительности в рамках термопакета. Если задача однопоточная, а одно ядро сидит на своей базовой частоте и потребляет 20% термопакета, то фиговый это какой-то процессор. Намного лучше было бы включить буст, быстренько перемолоть эту задачу и усыпить ядра. У эпл банально наверное нет еще подобной системы. И можно не сомневаться, что будет.
Меня больше интересует вопрос успешности наращивания ядер ими.
Нарастить то наверное смогут. Вопрос какой ценой. Эпл не играет по привычным правилам, она не продает процессоры, что делает сложным сравнение с экономической точки зрения. Они вполне могут сделать огромный по размерам монолитный кристалл с mesh-интерконнектом как у интела, который будет опережать конкурентов, но при этом его себестоимость будет космической в сравнении. А так как продают они целиком устройства, да еще в премиум сегменте, то узнать мы это не сможем.
Интересный вопрос, что они будут делать с подсистемой памяти и GPU. Их подход текущий не потянет полноценный GPU. Ему нужна в разы более быстрая память, если они собираются свое ядро использовать.
НЛО прилетело и опубликовало эту надпись здесь
Так а смысл рассуждать, что есть сейчас? Вот сейчас они пойдут на настольный рынок. Там буст это все. И если эпл опять будет сидеть на базовый частотах, то получится фигня. Буст был придуман для повышения скорости в условиях ограничений TDP и неравномерных нагрузок. У амд вон еще есть smartshift, который призван балансировать потребление GPU и CPU в целом, чтобы максимально утилизировать энергетический пакет. Это все необходимые функции для любого полноценного процессора. Эпл пока везет, что у нее есть форма в техпроцессе и закрытая экосистема. Она может пока сидеть и разрабатывать свою подобную систему.
Их подход текущий не потянет полноценный GPU. Ему нужна в разы более быстрая память.
Или нет.
Современным GPU нужна в разы более быстрая память потому что они развивались определенным образом: у них всегда была более быстрая память и были API, которые её утилизировали.
Но что если бы мы могли начать всё с начала, сделать API, который бы заставлял разработчиков как можно больше переиспользовать локальные кеши вычислительных блоков, да ещё и развивался сначала на маломощных устройствах с медленной памятью? Ну вы поняли.
который бы заставлял разработчиков как можно больше переиспользовать локальные кеши вычислительных блоковМожет я ошибаюсь, но будто бы единственный рабочий вариант заставить разработчиков не ходить лишний раз в общую память — это добавить больше задержек на общую память, что не выглядит хоть сколь-нибудь хорошо.
Современным GPU нужна быстрая память, потому что это единственное, что они делают. Читают память, молотят ее параллельно тысячами своих «ядер» и сохраняют обратно в память. Это устройства потоковой обработки в первую очередь. Им нечего переиспользовать, грубо говоря. Когда у тебя в памяти гигабайты вершин, индексов, текстур и рендер таргетов, то куда ты не сунься, но нужна широка шина у памяти.
Эпл ничего не добьется с текущей памятью. Ей либо придется выносить всю память наружу как на консолях и ставить GDDR. Либо ставить HBM на туже подложку. Других вариантов получить широкую шину вроде не придумано.
Эпл ничего не добьется с текущей памятью. Ей либо придется выносить всю память наружу как на консолях и ставить GDDR. Либо ставить HBM на туже подложку. Других вариантов получить широкую шину вроде не придумано.
Сами ядра прокачают. Такое уже было неоднократно у Apple.
Тесты есть? Intel ушел в уг. А если и есть паритет с AMD, то важны именно специализированные задачи. В оптимизированных для M1 приложениях этот чип просто рвет и мечет
Эпл сейчас по IPC находится на уровне конкурентов и это с учетом более совершенного техпроцесса.
Тесты есть? Intel ушел в уг. А если и есть паритет с AMD, то важны именно специализированные задачи. В оптимизированных для M1 приложениях этот чип просто рвет и мечет
НЛО прилетело и опубликовало эту надпись здесь
del
Судя по ответам, автор той демки сам намутил какой-то свой raymarching на Metal и на OpenGL поверх Windows. Сейчас бы рендерить лучи самому, когда есть аппаратная поддержка, а потом говорить, что Mac на M1 лучше Ryzen + GeForce RTX.
Я не утверждаю, что M1 однозначно плох, но эй, зачем умные люди вам придумывают аппаратные ускорители? Чтоб вы всё равно сами писали?
Я не утверждаю, что M1 однозначно плох, но эй, зачем умные люди вам придумывают аппаратные ускорители? Чтоб вы всё равно сами писали?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Apple M1 хорош, но насколько он хорош в трассировке лучей?