Комментарии 15
То-есть в текущей реализации нельзя больше двух кластеров? Как-же медиатек справился со своими 2+4+4?
В статье есть ответы на оба вопроса
Еще раз перечитал. Вижу, что в текущей реализации три кластера быть не может, а заглянув на сайт ARM видно, что "In each of the combinations above, the big and LITTLE clusters can each have a maximum of four cores". То-есть больше восьмиядерника не получить. А в новой архитектуре предлагают то, что есть у mtk уже пару лет как.
Больше двух выходит что можно (хотя название big.LITTLE и статьи от ARM намекают, что речь обычно идет как раз про 2 кластера). Впрочем, Медиатек как раз со своими тремя кластерами и не справился: батарею они едят с большим аппетитом, а плавностью и скоростью работы не отличаются (сужу по отзывам в сети и обзорам, сам я трехкластерник не щупал).
Британская ли?
Многие современные SoC на архитектуре big.LITTLE страдают из-за не эффективного диспетчера задач (task sheduler) операционной системы, который должен решать на каком кластере и на каком ядре должен выполняться тот или иной поток. Так, либо что-то тяжелое случайно попадет на маломощный кластер, или ерундовая нагрузка застрянет на мощном.
Новая архитектура еще сложнее предполагается. Так что требования к качеству диспетчера задач будут еще выше. И зная, что производители устройств не первой категории часто ленятся оптимизировать прошивку под конкретное железо, с большой долей вероятности новая архитектура как минимум по первости будет работать весьма неэффективно. Даже более того, первые поколения, вполне вероятно, тоже могут работать не гладко, хуже уже вполне отточенному big.LITTLE…
К примеру, у Самсунга его первый двухкластерник (Эксинос 5420, если не ошибаюсь) в момент выхода по энергоэффективности проигрывал традиционной (на тот момент) архитектуре (Qualcomm Krait x4), не поражая при этом выдающейся производительностью.
Так что, новая архитектура в конечном итоге вполне может стать чем-то офигенным — идея-то хорошая.
Новая архитектура еще сложнее предполагается. Так что требования к качеству диспетчера задач будут еще выше. И зная, что производители устройств не первой категории часто ленятся оптимизировать прошивку под конкретное железо, с большой долей вероятности новая архитектура как минимум по первости будет работать весьма неэффективно. Даже более того, первые поколения, вполне вероятно, тоже могут работать не гладко, хуже уже вполне отточенному big.LITTLE…
К примеру, у Самсунга его первый двухкластерник (Эксинос 5420, если не ошибаюсь) в момент выхода по энергоэффективности проигрывал традиционной (на тот момент) архитектуре (Qualcomm Krait x4), не поражая при этом выдающейся производительностью.
Так что, новая архитектура в конечном итоге вполне может стать чем-то офигенным — идея-то хорошая.
На аккумуляторах 2500 ма? Спс. Но нет.
А архитектура VLIW (Эльбрус8/16C например) насколько лучше/хуже про сравнению с RISC для приложений машинного обучения? (при одинаковых тактовых частотах / разрядности)
Должно быть неплохо. Машинное обучение вообще на GPU хорошо ложится. Так что разные SIMD и VLIW подходы тоже должны хорошо себя показывать.
Но у современных х86 помимо классического RISC на этот случай есть «широкие» SIMD наборы инструкций, например AVX и FMA. Который одной инструкцией позволяют провести до 16 операций с данными одинарной точности, а в какой-то из реализаций до 32 операций с половинной точностью (которой обычно тоже хватает для машинного обучения).
В результате Эльбрус все-равно будет существенно отставать и на таких задачах тоже, хоть и не так сильно как на задачах общего применения.
Но у современных х86 помимо классического RISC на этот случай есть «широкие» SIMD наборы инструкций, например AVX и FMA. Который одной инструкцией позволяют провести до 16 операций с данными одинарной точности, а в какой-то из реализаций до 32 операций с половинной точностью (которой обычно тоже хватает для машинного обучения).
В результате Эльбрус все-равно будет существенно отставать и на таких задачах тоже, хоть и не так сильно как на задачах общего применения.
Я немного не понимаю, зачем этот огород из разных ядер (а то и из одинаковых ядер с разной частотой)
Неужели не проще и эфективнее сделать динамическое значение частоты процессора, динамическое число работающих ядер и отключаемые блоки этих ядер?
Неужели не проще и эфективнее сделать динамическое значение частоты процессора, динамическое число работающих ядер и отключаемые блоки этих ядер?
Мне кажется что как ни закручивай гайки многоконвейерной системе типа графического ускорителя, его все равно не заставишь работать с таким же потреблением как у одного простого конвейера.
Тут я думаю суть в том, что на большом можно работать с аппаратной поддержкой векторных операций, а на маленьком векторные операции будут эмулироваться циклами. Это конечно очень грубое описание сути, но что-то типа того там и реализовано (как я смог понять).
Тут я думаю суть в том, что на большом можно работать с аппаратной поддержкой векторных операций, а на маленьком векторные операции будут эмулироваться циклами. Это конечно очень грубое описание сути, но что-то типа того там и реализовано (как я смог понять).
Не все исполняющиеся программные потоки используют SIMD. И ОС, об этом знает, т.к. контекст по-разному переключается, плюс, «ленивое» переключение контекста — когда контекст SIMD переключается при первой встретившейся операции SIMD. при переключении контекста задачи ОС знает, использовались ли в вытесненной задаче SIMD.
Поэтому ОС может смело пускать потоки без SIMD (благо, есть статистика) на урезанных ядрах, а при первой команде SIMD (если не угадали) просто перебрасывать их на полноценные (благо, что сама операция ничем не отличается от «обычного» переключения контекста задачи). Подозреваю, что именно так оно и работает сейчас — как раз позволяет сэкономить 25% потребления «в лоб». И именно настройкой алгоритмов определения/предсказания потоков, использующих SIMD, можно объяснить все эти массовые неудачи в самом начале внедрения big.LITTLE. Но сейчас все алгоритмы более-менее отработаны (да, и разработчики поняли, как правильно запускать потоки, чтобы оно неожиданно не начало тормозить на флагманах). Плюс, в ядре Линукс планировщики активно допилили и обкатали под эти цели. Тут правильно стали звузды, наступил «исторический момент», и совпали интересы x86 и ARM, т.к. статистика и динамическое управление на x86 давно и активно используется для управления потреблением ядер, и Линукс (к которому так или иначе близки все мобильные платформы) тут сильно отставал. Так что, вложили дружно денег, поделились технологиями, патентами и наработки, навалились, и вроде как, довели до ума.
Так что сейчас самое время внедрять разнородные ядра — алгоритмы обкатаны, софт написан, разработчики привыкли, и осталось только расширить поддержку в железе.
Поэтому ОС может смело пускать потоки без SIMD (благо, есть статистика) на урезанных ядрах, а при первой команде SIMD (если не угадали) просто перебрасывать их на полноценные (благо, что сама операция ничем не отличается от «обычного» переключения контекста задачи). Подозреваю, что именно так оно и работает сейчас — как раз позволяет сэкономить 25% потребления «в лоб». И именно настройкой алгоритмов определения/предсказания потоков, использующих SIMD, можно объяснить все эти массовые неудачи в самом начале внедрения big.LITTLE. Но сейчас все алгоритмы более-менее отработаны (да, и разработчики поняли, как правильно запускать потоки, чтобы оно неожиданно не начало тормозить на флагманах). Плюс, в ядре Линукс планировщики активно допилили и обкатали под эти цели. Тут правильно стали звузды, наступил «исторический момент», и совпали интересы x86 и ARM, т.к. статистика и динамическое управление на x86 давно и активно используется для управления потреблением ядер, и Линукс (к которому так или иначе близки все мобильные платформы) тут сильно отставал. Так что, вложили дружно денег, поделились технологиями, патентами и наработки, навалились, и вроде как, довели до ума.
Так что сейчас самое время внедрять разнородные ядра — алгоритмы обкатаны, софт написан, разработчики привыкли, и осталось только расширить поддержку в железе.
Машинное обучение в кармане. Скайнет все ближе?
Что имелось в виду под «порт имеет десятикратную производительность». Поправьте пожалуйста.
А вообще правильный ход, именно что эволюционный.
А вообще правильный ход, именно что эволюционный.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новые процессоры ARM готовы к приложениям ИИ