Не квантовый компьютер, но уже полезно: обзор AGIQ Solver Enterprise как GPU‑решателя для тяжёлых задач оптимизации

На рынке софта для оптимизации есть две крайности. С одной стороны — академические и промышленные решатели, которые невероятно мощны, но часто требуют либо очень аккуратной постановки, либо серьёзной экспертизы, либо терпения. С другой — бесконечный поток «революционных» продуктов, которые обещают всё, а в реальности оказываются очередной метаэвристикой с красивым лендингом. На этом фоне AGIQ Solver Enterprise оказывается любопытным кейсом. Не потому, что это «магия на видеокарте» или «квантовый компьютер для бедных», а потому что продукт пытается занять вполне конкретную нишу: быстрый поиск хороших решений в сложных булевых и оптимизационных задачах за счёт GPU и квантово-вдохновлённой логики поиска . Ниже — разбор, что это вообще такое, где оно действительно может пригодиться, почему здесь вообще всплывает слово «квантовый», и как с этим работать на практике.

https://habr.com/ru/articles/1045440/

#AGIQ_Solver_Enterprise #GPUвычисления #квантововдохновлённые_алгоритмы #оптимизация #MaxSAT #SAT_solver #GPGPU #параллельные_вычисления #булева_оптимизация #комбинаторные_задачи

GPU Compute Engine для 1С: как перестать ждать часами и начать считать на видеокарте

Массовые расчёты в 1С — авансы, себестоимость, MRP — традиционно узкое место при больших объёмах данных. Последовательная обработка на CPU занимает минуты и часы, и ни индексы, ни мощный сервер проблему не решают. В этой статье я показываю, как перенести такие вычисления на видеокарту через Vulkan Compute Shaders. Разбираю три реальных кейса — от простого расчёта авансов до MRP с Монте-Карло симуляциями — с цифрами, фрагментами шейдеров и архитектурными схемами. Ускорение: от 300 до 2500 раз. Движок с открытым исходным кодом, тестовые базы и полный инструментарий прилагаются.

https://habr.com/ru/articles/1034018/

#GPU_Compute_Engine #1С #Vulkan #параллельные_вычисления #вычислительные_шейдеры #MRP #себестоимость #авансы #МонтеКарло #GPGPU

Obviously when I teach #GPGPU I point out that the main point is performance, and “how to measure” is a topic we address. Obviously, the primary metric is kernel runtime. I then introduce the effective bandwidth metric (bytes read + bytes written, divided by time taken by the kernel) which is a good way to compare some similar kernels AND to discuss hardware limits and how close we are to them (I don't always discuss the roofline model though, maybe I should).

When we start to look into more advanced things, we hit the “snag” that sometimes a kernel using a more efficient technique may be _less_ effective at using a particular resource, e.g. by having having a _lower_ effective bandwidth —I do this on purpose to show how kernel runtime remains the ultimate “tell” on how good a kernel is compared to another (regardless of the additional information the effective bandwidth may tell us).

At this point I introduce a metric for which I don't actually know if there is a name: number of elements processed per seconds, which is just the number of elements, divided by the kernel runtime.

I call this effective throughput, but sometimes I get the nagging feeling that this may not be the correct term?

Стена данных: почему ИИ упирается не в GPU, а в реальность

В новой статье наш эксперт Антон Пчелинцев размышляет о причинах дефицита качественных данных, следующем прорыве в области развития ИИ и о том, что делать для получения преимущества.

https://habr.com/ru/articles/1016998/

#искусственный_интеллект #машинное+обучение #bigdata #стена_данных #gpu #gpgpu #данные #качество_данных #synthetic_data #синтетические_данные

Sooo, I want to sample mipmaps in a compute shader via "sampleGrad".

Does anyone know what the state-of-the-art is for deriving ddx and ddy for uv-coords in a compute shader?

I don't want to store the UV's derivatives in a G-buffer if possible.

#rendering #glsl #slang #hlsl #shader #gpgpu #vulkan #opengl

От MNIST к Transformer. Часть 2. Основы работы с памятью

Мы живем в эпоху, когда ИИ стал доступен каждому. Но за магией PyTorch скрывается колоссальная инженерная работа и сложные вычислительные процессы, которые для большинства остаются черным ящиком. Это вторая статья из цикла От MNIST к Transformer , цель которого пошагово пройти путь от простого CUDA ядра до создания архитектуры Transformer - фундамента современных LLM моделей. Мы не будем использовать готовые высокоуровневые библиотеки. Мы будем разбирать, как все устроено под капотом, и пересобирать их ключевые механизмы своими руками на самом низком уровне. Только так можно по настоящему понять как работают LLM и что за этим стоит. В этой статье разберем основы работы с памятью и две простые математические операции с точки зрения математики, но не такие простые с точки зрения CUDA ядер. Приготовьтесь, будет много кода на C++ и CUDA, работы с памятью и погружения в архитектуру GPU. И конечно же математика что за этим стоит. Поехали!

https://habr.com/ru/articles/1001886/

#ml #cuda #c++ #gpgpu

От MNIST к Transformer. Hello CUDA. Основы, Setup и наше первое ядро

Мы живем в эпоху, когда ИИ стал доступен каждому. Но за магией PyTorch скрывается колоссальная инженерная работа и сложные вычислительные процессы, которые для большинства остаются черным ящиком. Я хочу запустить большой цикл статей От MNIST к Transformer , цель которого пошагаво пройти путь от простого CUDA ядра до создания архитектуры Transformer - фундамента современных LLM моделей. Мы не будем использовать готовые высокоуровневые библиотеки. Мы будем разбирать, как все устроено под капотом, и пересобирать их ключевые механизмы своими руками на самом низком уровне. Только так можно по настоящему понять как работают LLM и что за этим стоит. Приготовьтесь, будет много кода на C++ и CUDA, работы с памятью и погружения в архитектуру GPU. И конечно же математика что за этим стоит. Поехали!

https://habr.com/ru/articles/996610/

#cuda #c++ #gpgpu #ml #lowlevel_programming