Pull to refresh

Comments 32

Я все таки больше серверный человек. А серверный мир все же очень консервативен. Harmony — безусловно хорошее начинание. Но думаю, что оно скорее увидит свет в мире ПК. Серверные люди вряд ли скоро уйдут с Linux…
значимость производительности одного ядра снижается
Почему тогда дорогой проприетарный ARM, а не RISC-V?
Потому, что деньги на лицензии уже потрачены — надо отбивать :-)

Наверно потому что "но до определенного предела" + дальше еще про коммуникации между ядрами написано.

Это хорошее соображение. Я бы хотел знать где место RISC-V на этой картинке. Но пока не видел никаких внятных перформанс данных (SPEC, Linpack) или хотя бы оценок.
А до определенного предела написал вот почему — все же производительность софта зачастую определяется самым узким местом, сериальной частью кода. Поэтому не особо верю, что RISC-V заработает «из коробки»…
Есть Power9 от рапторов. Вроде нормальный перформанс. Правда стоимость поднебесная.
Риски вроде Алибаба хотел делать
Я кстати, за проектом RISC-V c интересом посматриваю. Концепция выглядит на мой взгляд неплохо. Но если для ARM все же существует определенная экосистема, то для RISC-V весь софт надо будет перелопачивать с нуля. Это немного пугает :) Но вообще я тут думал написать пост про сравнение instruction sets cточки зрения эффективности и простоты реализации СPU front-end (a может быть и компилятора тоже). Мы на эту тему с Борисом Арташесовичем Бабаяном много дискутировали :)
Было бы очень интересно послушать ваши соображения на счёт ISA.
Хорошая статья, но Я пока не вижу применений для ARM.
В специфику своей работы, мне нам всегда требовались либо мощные процессоры (для серверов) и видеокарты с большим количеством CUDA ядер (машинное зрение и машинное обучение), а вот проекты, где нужно что то среднее, пока не встречались.
Ну я собственно полагаю что такая гомогенная конфигурация сможет эффективно конкурировать и с большими ядрами для серверных приложений и с маленьким для AI. Просто пока еще не создан чип с таким количеством ядер(~150 по моим оценкам), который смог бы это делать.
А какие у вас ворклоады, если не секрет?:)

Чего-то попытался почитать про это, но так и не понял. Что за технология у них используется? ARM/MIPS/какая-то собственная? Их сайт больше похож на рекламную компанию хрен пойти чего.

А ISA то какая? Какая нить очередная compiler -driven architecture?
Своя, они пишут что таки смогли во VLIW (в отличии от интела с их Itanium). Но, насколько я понял, пока даже исполнения в FPGA варианте нет, так что непонятно насколько это все реалистично. Авторы www.eejournal.com/article/creating-the-universal-processor едко подмечают что «Tachyum must have a very efficient simulator.» Больше деталей есть вот тут www.nextplatform.com/2020/04/02/tachyum-starts-from-scratch-to-etch-a-universal-processor
Вы про какую нагрузку спрашиваете?
Производства которое мы автоматизируем, на роботов которых мы делаем или лично на меня? )
Или на сервера от Huawei которые мы используем)))
Да я все пытаюсь думаю про машинное зрение или обучение. Сколько нужно ядер, сколько исполнительных элементов и какую ширину SIMD, чтобы это стало сравнимо с NVidia. Это ведь для роботов?
Ага, Я не разработчик, а сис админ, поэтому могу сказать только про железо.
Для понимания приведу пример обработки видеопотока, точнее время выполнения цикла процессов для полного выполнения задачи:
1. При обработке на процессоре на Сервере с выделенными для софта 32 ядрами цикл выполняется за 3минуты.
2. При обработке на видеокарте на ПК с GTX1070, полный цикл проходит за 30 секунд.
3. При обработке на видеокарте на Сервере с RTX2080 Super, завершается за 10 секунд.
Софт использует многопоточность, соответственно чем больше CUDA ядер, тем лучше. Может и на Асиках считать. И высоко производительные ядра тут не требуются.

По поводу машинного обучения. У нас для этого используется три RTX 2070.
Как бы изначально на них строили, так что сравнений с другим железом нет.
спасибо. Вопрос тут как всегда в балансе числа исполняющих элементов, обьема загружаемых из памяти данных и сложности scheduleroв. На GPU они уже приближаются по сложности к космическим кораблям :) По сути скедюлер на GPU — это уже чип в чипе. Есть даже идеи использовать СPU для решения этой задачи :)
Что-то среднее нужно для HPC.
Fujitsu A64FX это сейчас самое топовое HPC решение по производительности среди CPU, обладающее эффективностью выше чем GPU.

www.nextplatform.com/2020/05/18/with-fugaku-supercomputer-installed-riken-takes-on-coronavirus

A64FX и ThunderX3 — 2 ARM процессора с производительностью > 3TFLOPS в DP.
Идея интересная, но не выстрелит.

Потому что критерием скорости 99% серверных приложений является время обработки одного запроса, а это в 99% случаев не параллелится (пока). Поэтому нужна большая single-thread производительность.

А при возникновении выбора — купить более дешевое, но слабое в single-thread производительсноти железо или использовать более простую, но CPU-затратную технологию (напр., Python вместо C++) — обычно выбирают второе, потому что труд программиста супердорог (по сравнению с другими профессиями в большинстве стран мира), и технологии надо упрощать, пусть и засчет увеличения потребления CPU.
Потому что критерием скорости 99% серверных приложений является время обработки одного запроса, а это в 99% случаев не параллелится (пока). Поэтому нужна большая single-thread производительность.

Это серверы. А для них в первую очередь имеет значение кол-во кол-во обработанных запросов в единицу времени (точнее, кол-во удовлетворенных юзеров), которое зависит и от кол-ва ядер и от их производительности.

Ну с количество запросов в секунду уже научились увеличивать настолько, насколько нужно — балансировать нагрзуку, шардировать можно хоть до бесконечности, если, конечно, архитектура позволяет.

Шардирование до бесконечности -> трата всей энергии земли.

Хотел написать по какому алгоритму желательно бы работали процы, но уже в с самом начале остановился на том, что это должен/ны решать какие-то отдельные ядра. А не будет ли при этом трата энергии на эти ядра больше, чем задача, которую они решают?
В текущих процах это скорее всего делает "кто-то" (не поднялась рука на "что-то") типа гипервизора. Судя по времени жизни от аккумов на разных смартах эти алгоритмы для этих гипервизорах отличаются сильно.

Я полагаю что важно и то и другое на самом деле. Throughput (количество обработанных запросов) наверно важнее. Но и латентность тоже играет рояль иногда. Впрочем она даже сильнее от сетки зависит и еще от чертовой тучи факторов…
Потому что критерием скорости 99% серверных приложений является время обработки одного запроса, а это в 99% случаев не параллелится (пока). Поэтому нужна большая single-thread производительность.

так вроде бы у армов прогресс в этом направлении

Offtop on
Неожиданная встреча на Хабре. Привет-привет. Заодно узнал чем ты сейчас занимаешься)
Offtop off
Прогнозы дело не благородное. Я бы склонился к подходу ниши всякие нужны, ниши всякие важны. Пусть расцветают множество архитектур и решений, а уж мы потом выберем)
Валера, привет! А как же компании которые на ARM сделали упор на производительность отдельного ядра? Какие задачи по твоему именно лидерство в «коммуникациях» поможет в HPC?
Привет, Игорь. Ну я имел в виду то, что что uncore oн весь состоит из шин, коммутаторов и буферов.
Очень интересуют нейроускорители Huawey.
Это то на чем могут выстрелить сервера с ARM. Если нужен только inference, а не training, то Nvidia не нужна.
Когда нибудь напишу о них. Когда дойдет ход. Но пока про CPU :)
Sign up to leave a comment.