Вот так через десятилетия работы с CUDA люди приходят к выводам: - хорошо бы иметь полный контроль над загрузкой и запуском ядра; - хорошо бы разделить код для GPU от кода для CPU и собирать разными компиляторами; и идут использовать CUDA Driver API.
В принципе всё что описано должен был сделать OpenCL. Но видимо Intel'у порог вхождения в него показался высоким и они хотят сделать что-то более простое типа CUDA под все устройства. Каждый год появляются новые API для вычислений, но если оглянуться вокруг в поисках чего-то для своего проекта — опять кроме OpenCL и CUDA ничего нет. У AMD была попытка чего-то подобного (а на самом деле — поддержать CUDA на AMD) под названием HIP — и она как-то не популярна у профессионалов в силу некоторых своих принципиальных ограничений. Ещё одна, более ранняя, попытка от AMD называлась HSAIL. Пиши на чём угодно, исполняется на чём угодно. Даже хотели java-код на GPU почти автоматом запускать в 2013. Сейчас как анекдот, смешно, а когда GCN только появился думали всерьёз сейчас java будет на GPU ускоряться за просто так, без участия программиста. Я даже расстраивался, столько мучались с этими оптимизациями на VLIW, клаузами, условными операторами — и тут раз, можно было на жаве писать а оно на GPU потом заработает. Чуда не произошло. HSAIL тоже не стал таким вот oneAPI, даже не знаю поддерживает ли его сейчас хоть кто-нибудь.
Надеюсь у Intel выйдет лучше. Надеюсь, но не верю. Разработчиков под такие высокопроизводительные штуки ну может несколько тысяч в мире. И больше их всё равно не будет, нет таких разных задач на всех. Линейная алгебра, БПФ, кодеки, майнеры, библиотеки машинного обучения, обработка изображений. Несколько разработчиков написали это всё на любом API — и обычные программисты могут лихо использовать готовые библиотеки, концентрируясь на предметной области а не что там за API под капотом.
Не всё, что умеет железо GPU, можно написать на OpenCL C. Например, cross-lane инструкции. Второе ядро может отличаться от исходного ifdef'ом и скомпилируется на любой платформе. Я знаю и люблю стандартный OpenCL C больше чем авторы компиляторов, но проблема в том что когда нужно дотянуться до труднодоступных непереносимых мест AMD-шного железа из OpenCL единственное рабочее решение — вообще ассемблер. Причём автор ассемблера/дизассемблера пилит его в одиночку, где-то сбоку от AMD. А рядом всегда для сравнения есть CUDA. Там всё есть, аж обидно.
Ну и кому нужны тогда в железе новые команды, если извне до них не достучаться. Притом что в CUDA все железные наработки оперативно появляются. Для платформо-независимого кода можно писать отдельное запасное универсальное ядро.
Сейчас 2018-й год, ничего не поменялось. Единственная когда-то рабочая тулза — профайлер CodeXL выложен в opensource и разработка его на этом кончилась. Есть хороший компилятор (читай clang) на котором можно писать код, оптимизированный для GCN, но бинари которые он выдаёт не работают на обычных AMD-шных драйверах (другой ABI). А OpenCL компилятор из обычных AMD-шных драйверов не поддерживает ассемблерных вставок и даже интринсиков для новых команд. Даже Nvidia'вский компилятор OpenCL C поддерживал ассемблерные вставки! Извините, накипело.
Есть по крайней мере для OpenCL C и OpenCL C++. Вообще на SPIR-V большие надежды, с ним можно будет наконец разделить сами вычислительные ядра и API. В качестве языка для ядер использовать OpenCL C, OpenCL C++, GLSL, писать на чистом SPIR-V как на ассемблере. А отдельно — API для запуска ядер: OpenCL, Vulkan, что-нибудь ещё типа CUDA (технически они могли бы поддержать запуск SPIR-V ядер в своём API). Это развяжет руки экспериментаторам и энтузиастам по компиляции других языков в SPIR-V. Могут появиться новые языки, компилирующиеся в SPIR-V, как Scala и Kotlin в JVM.
Прогресс, к сожалению, тут идёт медленнее чем хотелось бы. Но ИМХО профильным специалистам уже стоит начать осваивать SPIR-V и Vulkan.
Судя по 100% загрузке процессора, не установлен модуль kqemu. При этом используется программная эмуляция и производительность qemu естественно ни в какое сравнение не идет с vmware, но если поставить пакет kqemu-source, скомпилировать этот модуль и установить, то производительность станет на порядок лучше (чем без kqemu).
Если взять всё рабочее время за последние пять лет и потратить его полностью на "отсмотр" резюме, то это меньше 33 секунд на каждое.
В принципе миллион это примерное количество IT-специалистов России. Поздравляю, Вы посмотрели все резюме, это впечатляет.
Вот так через десятилетия работы с CUDA люди приходят к выводам:
- хорошо бы иметь полный контроль над загрузкой и запуском ядра;
- хорошо бы разделить код для GPU от кода для CPU и собирать разными компиляторами;
и идут использовать CUDA Driver API.
А ведь всё это было в OpenCL!
* на GPU.
Надеюсь у Intel выйдет лучше. Надеюсь, но не верю. Разработчиков под такие высокопроизводительные штуки ну может несколько тысяч в мире. И больше их всё равно не будет, нет таких разных задач на всех. Линейная алгебра, БПФ, кодеки, майнеры, библиотеки машинного обучения, обработка изображений. Несколько разработчиков написали это всё на любом API — и обычные программисты могут лихо использовать готовые библиотеки, концентрируясь на предметной области а не что там за API под капотом.
Прогресс, к сожалению, тут идёт медленнее чем хотелось бы. Но ИМХО профильным специалистам уже стоит начать осваивать SPIR-V и Vulkan.
Но её гораздо проще запустить. Используйте инсталятор.
Не проще ли было использовать её же для установки Windows XP?