Комментарии 7
Вспоминается пресловутое десятое правило - логика выглядит похоже на обобщённые функции в CLOS.
Или не понял задачу или что.
#if defined(CPU_MATH) #include "cpumath.h"
#elif defined(GPU_MATH) #include "gpumath.h"
...
#endif
И собирай приложение под нужную конфигурацию.
Чем абстракция из статьи лучше?
Ты правильно понял задачу, но кажется не понял то, что у нее более одного решения. Со своими плюсами и минусами.
На вскидку: плюс в том, что есть динамический выбор где будем исполняться.
Минус в том, что в памяти будет код из 100500 функций, которые сейчас не используются (платформа вычислительная не подходит).
Верю, что решение можно куда-то прикрутить и применение будет оправдано. Тут, к задаче этой, абсолютно бессмысленная абстракция.
Но ок.
В примере который я привел, обычно собирается библиотека с двумя бэкендами например CPU и CUDA. Это позволяет часть вычислений производить на CPU, например при загрузке и предобработке данных, а потом передать их на GPU для вычислений, потом вернуть пользователю на хост. Если вы сталкивались с установкой PyTorch то могли заметить, что существуют отдельные бинарные пакеты для CUDA или ROCm и т.д. И подход на который вы сослались тоже применяется но уже при сборке такого пакета.
А в llama.cpp как сделано? Я не знаю, просто спрашиваю.
Если я правильно понял то там реализовано через динамическую загрузку разделяемых библиотек с одинаковым интерфейсом. Вот ссылки на код: регистрация и загрузка.
Динамический полиморфизм для свободных функций: еще одна практика из С++ для машинного обучения