Комментарии 49
а кто управлять будет RISC ядрами?
По вашему определению и PDP11 получается CISC. Это так?
По-моему, вы с прямым углом перепутали.
PDP-11 это где возможны операции типа ADD @6(R2), @-(R3).
Не может быть «похожим на RISC» процессор, у которого есть косвенный автодекрементный режим адресации (номер 5), косвенный индексный (номер 7) и т.п. — каждая такая особенность добавляет дополнительные сложности в декодер и такты в исполнение. И даже операции чтения-модификации-записи ячейки в памяти без прочих косвенных эффектов это уже уход от RISC.
«Похожий на RISC» это, например, базовые арифметические операции S/360, где второй источник ещё может быть в памяти, но первый источник и приёмник — только в регистре.
Ортогональность системы команд это как раз аргумент больше против RISC, чем за. RISC это простота одной команды, а не набора в целом.
Но с большей частью остального вы перегибаете.
В современном мире с его требованием 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)
Рынок сильно сдвигается в сторону IoT сейчас, в системах безопасности, умных домах, IP камерах, итд — везде будут энергоэффективные и шустрые RISC (скорее всего ARM) процессоры, так что до пика рынка еще имхо далеко. Требования к CPU только растут из-за новых возможностей и обязательности шифрования для каждого девайса. Количество АРМов на квадратный метр дома только растёт, и рядом пара одиноких x86 в ноуте и компе.
IoT тоже разные бывают и на месте не стоят, о том и речь была, что например в продвинутых IP камерах уже достаточно мощные процессоры, сжимают несколько потоков h265 на лету в разном разрешении, следят сами за зонами движения, сами отслеживают движущиеся объекты, скоро еще научат их распознавать образы и тд. Там для дополнительной мощности при малом потреблении применений море.
Интересно, почему xeon phi стал мертвой веткой эволюции? Идея вставить 8 pcie карт в один сервер, и получить 480 полноценных x86 ядер (пусть и частично ограниченных в скорости операций с RAM и IO) и под 2000 потоков в 2011 году на первый взгляд кажется весьма заманчивой. Сразу возникает много идей, как это использовать, начиная от гипервизора, который тащит на себе 2000 сайтов-визиток и захудалых интернет магазинов на 100 покопателей в день в одной коробке, и заканчивая аналитическими СУБД, делающими в 2000 потоков аггрегации (что актуально для колоночных баз).
Прочитайте как общая шина памяти убивает производительность уже при 32х ядрах и сразу всё встанет на свои места. Потом смотреть в сторону NUMA архитектур и тд. Память и так очень часто уже узкое место, а для 480 ядер это убийство самой идеи. Имхо, гораздо более интересной была идея от SeaMicro, но тоже не взлетело.
ARM — это в первую очередь экономичность, а уже потом — производительность. А серверам чаще всего нужно ровно наоборот. Плюс для совсем тяжелых вычислений у x86 в рукаве есть козырь в виде GPGPU, с которым у альтернативных платформ все пока довольно грустно.
Ой, этой новости уже лет 15, если не 20. Все наступает, да не наступит никак.
Врядли 15 лет назад можно было ARM брать в аренду и разворачивать там сервера.
ARM — это в первую очередь экономичность, а уже потом — производительность.
Это определяется исключительно дизайном конкретной модели, у интела есть процессоры также соответствующие этому определению.
Врядли 15 лет назад можно было ARM брать в аренду и разворачивать там сервера.
Их и сейчас на первом попавшемся хостинге не взять. Некоторые, ориентированные на специфическую аудиторию, за неадекватные производительности деньги.
Это определяется исключительно дизайном конкретной модели, у интела есть процессоры также соответствующие этому определению.
У арма вся цель существования заключена в этом, в отличие от интела.
У арма вся цель существования заключена в этом, в отличие от интела.
Конкретно эти процессоры — нет.
x86 в рукаве есть козырь в виде GPGPU
50/50. Потому что есть ARM со специализированными блоками, ARM с FPGA, ARM с CUDA ядрами.
Какая же эта экзотика, когда Huawei, Qualcomm, Apple представила процессоры с NPU блоками. А в Switch ARM с CUDA от NVidia.
Успешных устройств кроме switch — 0. Неттопы--слив, планшеты слив и проч.
NVidia Shield
Данных по продажам чисто android tv версий shield я не нашел, когда будут можно будет обсудить
Она всегда была android tv продающая сервисы nvidia.В этом году линейка получила обновление. А еще так же пытается зайти на рынок серверов Arm Servers ThunderX2
для совсем тяжелых вычислений у x86 в рукаве есть козырь в виде GPGPU, с которым у альтернативных платформ все пока довольно грустно
Да щас.
CUDA, TensorFlow, и NGC прекрасно работают на NVidia Jetson, кои суть есть ARM. И если мне не изменяет — там есть PCI-E, куда можно воткнуть видеокарту. Вот вам и GPGPU.
В пределе от ARM-ядра требуется только просасывать сеть и координировать выполнение полезной нагрузки на GPU, т.е. по сути нужна компактная плата с двумя разъемами — GbE и PCI-E для сетевизации и скейлинга видеокарт.
А старшие 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#
Фирменные блобы, насколько я знаю, только под x86[-64], альтернативные архитектуры сосут лапу.
Не знаете, а nVidia говорит что всё есть
nvidianews.nvidia.com/news/nvidia-and-tech-leaders-team-to-build-gpu-accelerated-arm-servers-for-new-era-of-diverse-hpc-architectures
Заявление от компании есть, но где именно скачать драйвера и наборы библиотек, чтобы я на своей 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)
Есть tech preview toolkit для arm но только на условиях NVIDIA developer program — developer.nvidia.com/cuda-toolkit/arm
Это оно и есть :)
The preview is not feature complete and may have issues.
Если вы попробуете запустить тот же TF на ARMе — вашему разочарованию не будет предела
YOLOv3 на базе TF с удивлением смотрит на этот комментарий.
А так — в общем, TF на видюхах и гоняют.
Речь идет о производительности — ведь даже Jetson Nano может принимать видео одновременно с 4х камер CSI-2. Но если вы попытаетесь это видео прогнать через YOLO или другую сравнимую сеть на ARM — c FPS будет совсем печально. Именно поэтому Nvidia рекомендует конвертировать сети в TensorRT и встраивать их в конвейер DeepStream так чтобы данные не покидали GPU.
В моей практике нейровычисления — это как правило batch operation над картинками.
Так что если у вас «картинок» больше чем несколько сотен — обычный x86 десктоп с 1060/1070/1080 будет гораздо дешевле и производительнее.
RAM <-> GPU? (hint не на x86)
Наступает эпоха ARM-серверов?