Комментарии 51
а кто управлять будет 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, но тоже не взлетело.
Ой, этой новости уже лет 15, если не 20. Все наступает, да не наступит никак.
Врядли 15 лет назад можно было ARM брать в аренду и разворачивать там сервера.
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)
У амазона соотношение было 1 к 5 =-80%. Решается это перепроектированием SOC, что там и демонстрирует амазон: прирост скорости стал +20% больше, 60 ГБ.
Вот только ордена сервера меньше строить не будет так как основная цена это инфраструктурные затраты:
— прокладка кабеля до соседней страны для обхода блокировок;
— охлаждение датацентра.
Наступает эпоха ARM-серверов?