Comments 49
Сейчас внутри почти всех CISC находятся ядра RISC, по сути борьба идет за то чтобы выкинуть прослойку преобразования x86 CISC в RISC, что должно дать выигрыш.
Не из-за этой прослойки x86 потребляет в разы больше электричества. Там много чего другого есть. Один предсказатель ветвлений чего стоит.
Можно подумать арму предсказатель ветвлений не нужен. Да и потребление декодера в легендах сильно преувеличено, термокарты процессоров есть в открытом доступе.
Классический RISC сейчас только в MIPS да в RISC-V. ARM сейчас это больше CISC с элементами RISC, не более. В RISC нет инструкций переменной длины, инструкций, которые читают/записывают несколько регистров (push/pop), загрузка/сохранение с автоматическим приращением, арифметика/логика со сдвигами. Зато это всё есть в ARM.
То что у PDP-11 ортогональная система команд, инструкции фиксированной длины, только регистровые операции и минимальный набор инструкций — делает его похожим на RISC. Но в то время ещё не было определения RISC, когда PDP-11 только вышел в продажу.
> только регистровые операции

По-моему, вы с прямым углом перепутали.
PDP-11 это где возможны операции типа ADD @6(R2), @-(R3).
Не может быть «похожим на RISC» процессор, у которого есть косвенный автодекрементный режим адресации (номер 5), косвенный индексный (номер 7) и т.п. — каждая такая особенность добавляет дополнительные сложности в декодер и такты в исполнение. И даже операции чтения-модификации-записи ячейки в памяти без прочих косвенных эффектов это уже уход от RISC.
«Похожий на RISC» это, например, базовые арифметические операции S/360, где второй источник ещё может быть в памяти, но первый источник и приёмник — только в регистре.
Ортогональность системы команд это как раз аргумент больше против RISC, чем за. RISC это простота одной команды, а не набора в целом.
Если вы про соответствие логике классической линии RISC, где все команды исполняются за фиксированное количество тактов, то да, современные RISC все вылазят за неё. И дело не только в перечисленных вами вещах: классический RISC даже не мог содержать операций с плавающей точкой или целочисленного деления — они все выносились в сопроцессоры или строились циклами с поддержкой этих действий. (Не рассматриваем, конечно, вариант занизить тактовую частоту так, чтобы АЛУ мог выполнять такое за 1 такт — это невыгодно для всего остального.)
Но с большей частью остального вы перегибаете.
В современном мире с его требованием out-of-order нет смысла требовать соответствия пятитактной схеме Berkeley/MIPS или её аналогу, зато появляется возможность делать более длинные и сложные действия, где они нужны (как с плавучкой).
Со сдвигами — нет никакой проблемы в операции типа a=b+(c shl d), если d — константа; это всего лишь несколько дополнительных вентилей на barrel shifterʼе. Но даже если это не константа, то это всего лишь участие 4 регистров вместо 3 в списках зависимостей.
То же и с каким-нибудь LDP, STP, с автоинкрементом/автодекрементом.
Зато нет команд типа MOVES (x86), EDMK (S/360)…
ARM — RISC с элементами CISC, да. Но не наоборот, он продолжает сохранять простоту для управляющего устройства.
В RISC нет инструкций переменной длины, инструкций, которые читают/записывают несколько регистров (push/pop)

Только вот в AArch64 ничего этого нет =)
Разве что ldp для загрузки регистровых пар.

загрузка/сохранение с автоматическим приращением

POWER

арифметика/логика со сдвигами

Itanium (shladd)
RISC растёт большей частью за счет мобильных устройств. Точно такой же бурный рост CISC был в 2000-х. Сейчас такой рост не нужен, т.к. ОС неплохо работает на компах 5-8 летней давности. Мобилы восьмилетней давности были унылым говном, по сравнению с современными. Через несколько лет рынок насытится, и рост RISC тоже замедлится.

Рынок сильно сдвигается в сторону IoT сейчас, в системах безопасности, умных домах, IP камерах, итд — везде будут энергоэффективные и шустрые RISC (скорее всего ARM) процессоры, так что до пика рынка еще имхо далеко. Требования к CPU только растут из-за новых возможностей и обязательности шифрования для каждого девайса. Количество АРМов на квадратный метр дома только растёт, и рядом пара одиноких x86 в ноуте и компе.

IoT это все малопотребляющее и маломощное. Абсолютно другая ниша. В статье речь про сервера…

IoT тоже разные бывают и на месте не стоят, о том и речь была, что например в продвинутых IP камерах уже достаточно мощные процессоры, сжимают несколько потоков h265 на лету в разном разрешении, следят сами за зонами движения, сами отслеживают движущиеся объекты, скоро еще научат их распознавать образы и тд. Там для дополнительной мощности при малом потреблении применений море.

Уже научились и распознавать образы, и траекторию движения, и давать оценку — что делал объект и стоит ли давать аларм по данному поводу. Умные камеры Bosch например, и питаются по PoE. Правда стоят как самолет.

Интересно, почему xeon phi стал мертвой веткой эволюции? Идея вставить 8 pcie карт в один сервер, и получить 480 полноценных x86 ядер (пусть и частично ограниченных в скорости операций с RAM и IO) и под 2000 потоков в 2011 году на первый взгляд кажется весьма заманчивой. Сразу возникает много идей, как это использовать, начиная от гипервизора, который тащит на себе 2000 сайтов-визиток и захудалых интернет магазинов на 100 покопателей в день в одной коробке, и заканчивая аналитическими СУБД, делающими в 2000 потоков аггрегации (что актуально для колоночных баз).

Для того, чтобы потянуть 2000 сайтов-визиток на 200 тысяч юзеров суммарно, в общем-то, и не надо 480 полноценных х86 ядер. С этим и четыре полноценных ядра вполне себе справятся. Это надо для дата-майнинга, но рынок пока что невелик.
Xeon Phi в первую очередь предназначен для параллельных вычислений (собственно, изначально он и разрабатывался как видеокарта). Для серверов от него толку мало.

Прочитайте как общая шина памяти убивает производительность уже при 32х ядрах и сразу всё встанет на свои места. Потом смотреть в сторону NUMA архитектур и тд. Память и так очень часто уже узкое место, а для 480 ядер это убийство самой идеи. Имхо, гораздо более интересной была идея от SeaMicro, но тоже не взлетело.

Ой, этой новости уже лет 15, если не 20. Все наступает, да не наступит никак.

ARM — это в первую очередь экономичность, а уже потом — производительность. А серверам чаще всего нужно ровно наоборот. Плюс для совсем тяжелых вычислений у x86 в рукаве есть козырь в виде GPGPU, с которым у альтернативных платформ все пока довольно грустно.
Ой, этой новости уже лет 15, если не 20. Все наступает, да не наступит никак.

Врядли 15 лет назад можно было ARM брать в аренду и разворачивать там сервера.

ARM — это в первую очередь экономичность, а уже потом — производительность.

Это определяется исключительно дизайном конкретной модели, у интела есть процессоры также соответствующие этому определению.
Врядли 15 лет назад можно было ARM брать в аренду и разворачивать там сервера.

Их и сейчас на первом попавшемся хостинге не взять. Некоторые, ориентированные на специфическую аудиторию, за неадекватные производительности деньги.

Это определяется исключительно дизайном конкретной модели, у интела есть процессоры также соответствующие этому определению.

У арма вся цель существования заключена в этом, в отличие от интела.
У арма вся цель существования заключена в этом, в отличие от интела.

Конкретно эти процессоры — нет.
x86 в рукаве есть козырь в виде GPGPU

50/50. Потому что есть ARM со специализированными блоками, ARM с FPGA, ARM с CUDA ядрами.

Все, перечисленное вами, — экзотика, а x86 с видеокартой — повседневная обыденность.

Какая же эта экзотика, когда Huawei, Qualcomm, Apple представила процессоры с NPU блоками. А в Switch ARM с CUDA от NVidia.

Массовому выпоску платформы Nvidia Tegra (начиная с Tegra 2) уже больше 10 лет.
Успешных устройств кроме switch — 0. Неттопы--слив, планшеты слив и проч.
это которая из консоли переродилась в android tv то, от большого winа на области консолей?
Данных по продажам чисто android tv версий shield я не нашел, когда будут можно будет обсудить

Она всегда была android tv продающая сервисы nvidia.В этом году линейка получила обновление. А еще так же пытается зайти на рынок серверов Arm Servers ThunderX2

Сорян перепутал с ShieldPad и Shield Portable т.к. именно их рекламу видел в 2013
«Я не скажу за всю Одессу», но в Raspberry Pi (ведущих родословную от ТВ/видео декодеров) или NVIDIA Jetson/Xavier — это скорее мощные DSP к которым сбоку приделан ARM исключительно для задач управления/UI. Скорость обмена между ARM и DSP там практически никакая, как и производительность самого ARM. У NVIDIA, правда, можно выбирать профиль мощности — но тогда нужно забыть о мобильности и пассивном охлаждении.
для совсем тяжелых вычислений у x86 в рукаве есть козырь в виде GPGPU, с которым у альтернативных платформ все пока довольно грустно

Да щас.
CUDA, TensorFlow, и NGC прекрасно работают на NVidia Jetson, кои суть есть ARM. И если мне не изменяет — там есть PCI-E, куда можно воткнуть видеокарту. Вот вам и GPGPU.
В пределе от ARM-ядра требуется только просасывать сеть и координировать выполнение полезной нагрузки на GPU, т.е. по сути нужна компактная плата с двумя разъемами — GbE и PCI-E для сетевизации и скейлинга видеокарт.
А старшие NVidia афаик умеют подобный цирк без участия центральных процессоров.
Наличие PCI-E — это еще не залог доступности в GPGPU. Без нормальных открытых драйверов ловить нечего, а их (нормальных открытых драйверов) банально нет. Фирменные блобы, насколько я знаю, только под x86[-64], альтернативные архитектуры сосут лапу.
Еще раз: стек NGC/CUDA/Jetson — полностью от Nvidia. Вы что, думаете, они драйвера к своим видеокартам не сделали?

Есть какие-то закрытые драйвера для arm32 (armv7l-gnueabihf; host — NVIDIA Tegra K1 / 2 / 3), карты до 10хх поколения включительно:
https://www.nvidia.com/en-us/drivers/unix/linux-arm-display-archive/
Linux 32-bit ARM Display Driver Version: 390.132
https://www.nvidia.com/Download/driverResults.aspx/153829/en-us


В https://www.nvidia.com/Download/index.aspx?lang=en-us еще можно найти Tesla P100 / T4 / V100 для Power LE 64


Решение Jetpack (l4t) для Jetson миникомпьютеров кажется обычно содержит nvidia драйвер только для тех вариантов карт, которые встроены в чип — TX1, TX2, AGX, Nano. Зато оно поставляется с настоящими исходниками:
https://developer.nvidia.com/embedded/linux-tegra — L4T Driver Package (BSP) Sources
https://developer.nvidia.com/embedded/r32-2-3_Release_v1.0/Sources/T210/public_sources.tbz2
https://developer.nvidia.com/embedded/r32-2-3_Release_v1.0/Sources/T186/public_sources.tbz2
public_sources/kernel_src.tbz2 — kernel/nvgpu/drivers/gpu/nvgpu/include/nvgpu/hw/{gv11b,gp106,gk20a,gp10b,gv100,gm20b};
kernel/nvgpu/drivers/gpu/nvgpu/{gv11b,gp106,gk20a,gp10b,gv100,gm20b}
(на гитхабе есть более старые версии https://github.com/kfractal/nvgpu = https://github.com/NVIDIA/nvgpu и https://github.com/InES-HPMM/linux-l4t-4.4-kernel-nvgpu)
https://nv-tegra.nvidia.com/gitweb/?p=linux-nvgpu.git;a=summary
https://nv-tegra.nvidia.com/gitweb/?p=linux-nvgpu.git;a=commit;h=f8689bf2280ac9b2edd234f2a43d13494906f7f1 "Open source GPL/LGPL release" Oct 2019
"2017: NVIDIA has been working more on open-source "NVGPU" as their own open-source driver for Android. NVGPU will never be accepted upstream in the kernel. "


Кстати nvgpu/drivers/gpu/nvgpu/os/linux/module.c:MODULE_LICENSE("GPL v2") и встречаются заголовки MIT и GPL в файлах; есть также бинарная поставка "lib/modules/4.9.140-tegra/kernel/drivers/gpu/nvgpu/nvgpu.ko" от самой nvidia — т.е. gpl в части ядра должен сработать a стандартный анти-GPL финт "вы сами скачали сорцы и проприетарный блоб и слинковали их в драйвер" не работает (Без факта распространения бинарника GPL не начинает требовать раскрытия исходников)


Можно сравнить названия gv11b,gp106,gk20a,gp10b,gv100,gm20b с колонкой GPU Micro-architecture в
https://en.wikipedia.org/wiki/Tegra#Tegra_K1 и ниже и с https://envytools.readthedocs.io/en/latest/hw/gpu.html#

Заявление от компании есть, но где именно скачать драйвера и наборы библиотек, чтобы я на своей linux arm64 плате смог работать с nvidia gpu, подключенной по pciexpress? Какие поколения и карты поддерживаются — только датацентровые Tesla P, V, T или любые?
Судя по картинке справа в этом пресс-релизе, NVIDIA Arm Server Reference Design Platform предполагает использование восьми SXM* V100 (или P100) по 10 тыс.д. за штуку.


Свежего стандартного cuda toolkit под арм не нашел — https://developer.nvidia.com/cuda-downloads?target_os=Linux (хотя есть кросс-компилятор — https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html#cross-compile-to-arm-architectures).
Есть tech preview toolkit для arm но только на условиях NVIDIA developer program — https://developer.nvidia.com/cuda-toolkit/arm CUDA Toolkit 10.2 for Arm (RHEL 8.0 and Ubuntu 18.04.3 LTS) + cuDNN 7.6 + NCCL 2.4


В свободном доступе нашелся единственный старый cuda toolkit для arm64 — https://developer.nvidia.com/cuda-toolkit-65#linux-arm (2014-08) и он содержит проприетарный ядерный драйвер "nv-kernel.o" (для карт до Kepler включительно и возможно для отдельных maxwell)

Все перечисленное вами действительно работает на Jetson/Xavier — только ARM там используется только для загрузки кода в отдельный проприетарный видеопроцессор. Если вы попробуете запустить тот же TF на ARMе — вашему разочарованию не будет предела, даже при настройках 100% мощности. А если вставить в конвейер DeepStream не-GPU компонент (чтобы данные гонялись туда-сюда) — все станет совсем печально…
Если вы попробуете запустить тот же TF на ARMе — вашему разочарованию не будет предела

YOLOv3 на базе TF с удивлением смотрит на этот комментарий.
А так — в общем, TF на видюхах и гоняют.
Я нигде не писал что TF не работает на ARM, встроенном в Jetson. Разумеется, работает — его разве что на тостеры еще не портировали…
Речь идет о производительности — ведь даже Jetson Nano может принимать видео одновременно с 4х камер CSI-2. Но если вы попытаетесь это видео прогнать через YOLO или другую сравнимую сеть на ARM — c FPS будет совсем печально. Именно поэтому Nvidia рекомендует конвертировать сети в TensorRT и встраивать их в конвейер DeepStream так чтобы данные не покидали GPU.
Ну, это в случае, если вы работаете с реалтайм захватом видео.
В моей практике нейровычисления — это как правило batch operation над картинками.
Я почитал тред выше — такое впечатление, что вы путаете Jetson с чем-то другим от Nvidia. Потому что Jetson — это семейство решений для встраиваемых систем, с довольно медленными внешними коммуникациями. Даже у старших моделей, скорость обмена сеть-ARM-GPU — десяток-другой мегабайт в секунду со всеми ухищрениями.
Так что если у вас «картинок» больше чем несколько сотен — обычный x86 десктоп с 1060/1070/1080 будет гораздо дешевле и производительнее.
Глупо упоминать GPGPU и забывать о Power9. Не подскажете на какой платформе есть NVLink
RAM <-> GPU? (hint не на x86)
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

7 May 1999

Location

Россия

Website

miran.ru

Employees

51–100 employees

Registered

5 July 2017