Как стать автором
Обновить

Комментарии 4

Много "белых пятен".
Если это некий "кроссплатформенный ассемблер" (что вряд ли) — зачем здесь С++, язык с огромным числом сложностей?
Если это очередное "всеобъемлющее API" — опять же, каким боком С++ (другие языки за бортом)? И как это будет сочетаться с OS-specific API? Чем это лучше LLVM-like бэкендов? Как это будет совместимо с существующими решениями?

*картинка про новый универсальный стандарт, который заменит все предыдущие стандарты
P.S. Вы уже определитесь — либо все аббревиатуры на английском, либо на русском.
Ребята, сначала посмотрите, что предлагают Intel Software сейчас, а потом будем критиковать. Написано да, немного невнятно.

Основная идея — они дают среду разработки (C, Pyton) с минимальным дополнительным API, а среда исполнения вас интересовать не должна — исполняющая система (набор библиотек), которую компилятор добавит к итоговому исполняемому модулю, сама выберет, какие части исполняемого кода грузить для данной архитектуры, как исполнять и прочее.
Сейчас они так делают для процессоров Intel — в зависимости от версии процессора исполняется разный код. В итоге одна и та же СКОМПИЛИРОВАННАЯ программа на разных процессорах исполняет разные куски кода (машинных команд), выбирая те, которые «удачнее» ложатся на архитектуру текущего процессора.

One API просто расширяет список этих процессоров, не только архитектуры x86/x86_64, но и другие.
В принципе всё что описано должен был сделать 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 под капотом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий