Comments 32
Вроде как, да.
Я бы изменил заголовок, это Linux (Android и серверные применения) надо готовиться
www.ixbt.com/news/2020/05/02/windows-huawei-harmonyos-2-0.html
Можете пролить свет на эту ОС?
Я бы изменил заголовок, это Linux (Android и серверные применения) надо готовиться
www.ixbt.com/news/2020/05/02/windows-huawei-harmonyos-2-0.html
Можете пролить свет на эту ОС?
значимость производительности одного ядра снижаетсяПочему тогда дорогой проприетарный ARM, а не RISC-V?
Потому, что деньги на лицензии уже потрачены — надо отбивать :-)
Наверно потому что "но до определенного предела" + дальше еще про коммуникации между ядрами написано.
Это хорошее соображение. Я бы хотел знать где место RISC-V на этой картинке. Но пока не видел никаких внятных перформанс данных (SPEC, Linpack) или хотя бы оценок.
А до определенного предела написал вот почему — все же производительность софта зачастую определяется самым узким местом, сериальной частью кода. Поэтому не особо верю, что RISC-V заработает «из коробки»…
А до определенного предела написал вот почему — все же производительность софта зачастую определяется самым узким местом, сериальной частью кода. Поэтому не особо верю, что RISC-V заработает «из коробки»…
Я кстати, за проектом RISC-V c интересом посматриваю. Концепция выглядит на мой взгляд неплохо. Но если для ARM все же существует определенная экосистема, то для RISC-V весь софт надо будет перелопачивать с нуля. Это немного пугает :) Но вообще я тут думал написать пост про сравнение instruction sets cточки зрения эффективности и простоты реализации СPU front-end (a может быть и компилятора тоже). Мы на эту тему с Борисом Арташесовичем Бабаяном много дискутировали :)
Хорошая статья, но Я пока не вижу применений для ARM.
В специфику своей работы, мне нам всегда требовались либо мощные процессоры (для серверов) и видеокарты с большим количеством CUDA ядер (машинное зрение и машинное обучение), а вот проекты, где нужно что то среднее, пока не встречались.
В специфику своей работы, мне нам всегда требовались либо мощные процессоры (для серверов) и видеокарты с большим количеством CUDA ядер (машинное зрение и машинное обучение), а вот проекты, где нужно что то среднее, пока не встречались.
Ну я собственно полагаю что такая гомогенная конфигурация сможет эффективно конкурировать и с большими ядрами для серверных приложений и с маленьким для AI. Просто пока еще не создан чип с таким количеством ядер(~150 по моим оценкам), который смог бы это делать.
А какие у вас ворклоады, если не секрет?:)
А какие у вас ворклоады, если не секрет?:)
Просто пока еще не создан чип с таким количеством ядер(~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 которые мы используем)))
Производства которое мы автоматизируем, на роботов которых мы делаем или лично на меня? )
Или на сервера от Huawei которые мы используем)))
Да я все пытаюсь думаю про машинное зрение или обучение. Сколько нужно ядер, сколько исполнительных элементов и какую ширину SIMD, чтобы это стало сравнимо с NVidia. Это ведь для роботов?
Ага, Я не разработчик, а сис админ, поэтому могу сказать только про железо.
Для понимания приведу пример обработки видеопотока, точнее время выполнения цикла процессов для полного выполнения задачи:
1. При обработке на процессоре на Сервере с выделенными для софта 32 ядрами цикл выполняется за 3минуты.
2. При обработке на видеокарте на ПК с GTX1070, полный цикл проходит за 30 секунд.
3. При обработке на видеокарте на Сервере с RTX2080 Super, завершается за 10 секунд.
Софт использует многопоточность, соответственно чем больше CUDA ядер, тем лучше. Может и на Асиках считать. И высоко производительные ядра тут не требуются.
По поводу машинного обучения. У нас для этого используется три RTX 2070.
Как бы изначально на них строили, так что сравнений с другим железом нет.
Для понимания приведу пример обработки видеопотока, точнее время выполнения цикла процессов для полного выполнения задачи:
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.
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 производительность.
А при возникновении выбора — купить более дешевое, но слабое в single-thread производительсноти железо или использовать более простую, но CPU-затратную технологию (напр., Python вместо C++) — обычно выбирают второе, потому что труд программиста супердорог (по сравнению с другими профессиями в большинстве стран мира), и технологии надо упрощать, пусть и засчет увеличения потребления CPU.
Потому что критерием скорости 99% серверных приложений является время обработки одного запроса, а это в 99% случаев не параллелится (пока). Поэтому нужна большая single-thread производительность.
Это серверы. А для них в первую очередь имеет значение кол-во кол-во обработанных запросов в единицу времени (точнее, кол-во удовлетворенных юзеров), которое зависит и от кол-ва ядер и от их производительности.
Ну с количество запросов в секунду уже научились увеличивать настолько, насколько нужно — балансировать нагрзуку, шардировать можно хоть до бесконечности, если, конечно, архитектура позволяет.
Шардирование до бесконечности -> трата всей энергии земли.
…
Хотел написать по какому алгоритму желательно бы работали процы, но уже в с самом начале остановился на том, что это должен/ны решать какие-то отдельные ядра. А не будет ли при этом трата энергии на эти ядра больше, чем задача, которую они решают?
В текущих процах это скорее всего делает "кто-то" (не поднялась рука на "что-то") типа гипервизора. Судя по времени жизни от аккумов на разных смартах эти алгоритмы для этих гипервизорах отличаются сильно.
Я полагаю что важно и то и другое на самом деле. Throughput (количество обработанных запросов) наверно важнее. Но и латентность тоже играет рояль иногда. Впрочем она даже сильнее от сетки зависит и еще от чертовой тучи факторов…
Потому что критерием скорости 99% серверных приложений является время обработки одного запроса, а это в 99% случаев не параллелится (пока). Поэтому нужна большая single-thread производительность.
так вроде бы у армов прогресс в этом направлении
Offtop on
Неожиданная встреча на Хабре. Привет-привет. Заодно узнал чем ты сейчас занимаешься)
Offtop off
Прогнозы дело не благородное. Я бы склонился к подходу ниши всякие нужны, ниши всякие важны. Пусть расцветают множество архитектур и решений, а уж мы потом выберем)
Неожиданная встреча на Хабре. Привет-привет. Заодно узнал чем ты сейчас занимаешься)
Offtop off
Прогнозы дело не благородное. Я бы склонился к подходу ниши всякие нужны, ниши всякие важны. Пусть расцветают множество архитектур и решений, а уж мы потом выберем)
Валера, привет! А как же компании которые на ARM сделали упор на производительность отдельного ядра? Какие задачи по твоему именно лидерство в «коммуникациях» поможет в HPC?
Очень интересуют нейроускорители Huawey.
Это то на чем могут выстрелить сервера с ARM. Если нужен только inference, а не training, то Nvidia не нужна.
Это то на чем могут выстрелить сервера с ARM. Если нужен только inference, а не training, то Nvidia не нужна.
Sign up to leave a comment.
О тенденциях развития архитектуры процессоров, или почему я верю в успех Huawei на серверном рынке