Hacker News Digest

Главная идея: автогенерация кода для QR‑разложения через блоковый алгоритм Хоусакера ускоряет вычисления в 232 раз по сравнению с базовым решением.

Ключевой факт: использование «кода‑максимизации» (Codex‑maxxing) позволило сгенерировать ядро, которое работает в FP16, но сохраняет FP32‑точность проверок.

Для ускорения важно разбивать матрицу на блоки, применять параллельный Householder‑алгоритм и постоянно генерировать новые варианты кода, отсекая те, что не дают прироста.

Оптимальная стратегия включает:

• небольшие предварительные ядра, которые быстро тестируются;
• итеративное улучшение через мутацию и отбор;
• внедрение идеи разнообразия (idea diversity) для выхода из локальных максимумов.

Эти приёмы сделали возможным достижение рекордного ускорения в конкурсе GPU‑режима.

LLM-агенты эффективно оптимизируют код (в 2–8 раз быстрее), генерируя SIMD/AVX/CUDA ядра, при наличии строгих верификаторов и профайлеров (VTune, NSIGHT) в цикле benchmark → profile → verify. Без автоматической проверки pass/fail агенты не могут корректно оценить ошибки и завершают задачу ложно успешно. GPU-ядра хорошо поддаются автоматизации благодаря легко проверяемой корректности и «hill-climbable» структуре. Однако генерируемый код часто чрезмерно узкоспециализирован: 8 из 10 топ-решений в соревнованиях ломались на OOD-данных, требуя ручной доработки экспертов. Гипероптимизация ошибочно сужает задачу, тогда как истинная оптимизация требует понимания памяти или параллелизма. LLM превосходят большинство людей, но редко достигают абсолютного пика, достигаемого экспертами после глубокой ручной доработки. Советуют: сначала генерировать unit-тесты с 100% path coverage и golden values, затем оптимизировать с анализом flamegraphs. Использовать итеративный подход (back and forth) через SKILL.md, а не one-shot. LLM склонны к излишней сложности при недостатке данных — например, Opus 5 сгенерировал сложную размотку цикла, пропустив простое решение. «Loop engineering» с LLM может быть сложнее ручной оптимизации из-за галлюцинаций. Технический контекст: Cholesky быстрее, но применим только к положительно определённым матрицам; QR универсален и необходим для собственных значений — это объясняет выбор в статье.

Исследователи из Hazy Research разработали высокопроизводительный мегаядро для тензорно-параллельного вывода Llama-70B на H100, которое агрессивно перекрывает вычисления, работу с памятью и коммуникацию между GPU. Это позволяет одновременно задействовать различные аппаратные ресурсы: тензорные ядра, модули для нетензорных операций, пропускную способность HBM и NVLink. В интеграции с движком Tokasaurus их решение превосходит SGLang на >22% по общей пропускной способности при обработке 65 536 промптов из ShareGPT.

Ключевая идея — использование интерпретатора инструкций, работающего на каждом SM, который позволяет гибко планировать выполнение разнородных операций. Это обеспечивает перекрытие на нескольких уровнях: внутри SM (память и вычисления), между SM (матричные умножения и нормирование) и между GPU (скрытие задержек связи за счёт специальных потоков). Особенно отмечается простота реализации сложных трансформаций данных между GPU прямо после attention-слоя, что трудно выразить стандартными средствами коммуникации.

• Обсуждение эффективности использования GPU: использование всех блоков (NVDEC, NVJPG, RT и тензорные ядра) для декомпрессии весов и вычислений, аналогии с оптимизацией под консоли.
• Проблемы инструментов и драйверов: отставание языков, библиотек и драйверов от возможностей современного железа, сложности компиляторов для гетерогенных систем.
• Виртуализация и разделение ресурсов GPU: обсуждение MIG, MPS для многопользовательского использования, риски утечки данных и ограничения этих технологий.
• Сравнение с другими платформами: упоминание Apple Metal и открытости драйверов, потенциал использования GPU для аудиообработки и сигналов.
• Критика и ирония: сравнение стиля статьи с "Трансгрессия границ", комментарии о "коде, который не предназначен для поддержки" и неожиданно доступных оптимизациях в крупных лабораториях.

Fil-C — это C/C++-совместимый язык с безопасной памятью и современным инструментарием. Его сердце — FUGC, параллельный, конкурентный, точный, неперемещающий сборщик мусора.

Ключевые черты FUGC

• Параллельность: маркировка и очистка выполняются на всех ядрах.
• Конкурентность: потоки-мутаторы не останавливаются; блокировки только на медленных путях аллокации.
• On-the-fly: нет глобальной паузы; «мягкие рукопожатия» просят потоки асинхронно сканировать стек.
• Grey-stack: повторное сканирование стеков до фикс-поинта; барьер только при записи, быстрая сходимость.
• Dijkstra-barrier: при записи указателя объект помечается CAS-relaxed.
• Точность: LLVM-плагин FilPizlonator точно знает, где все указатели.
• Неперемещаемость: объекты не двигаются; освобождённые блоки «перенаправляются» через InvisiCap.

Safepoint-механизм

• Компилятор вставляет pollcheck: быстрая проверка или колбэк для GC.
• «Мягкое рукопожатие» запускает колбэк на всех потоках.
• Состояния enter/exit позволяют блокироваться в syscall без pollcheck’ов; GC сам выполняет колбэк для «exited» потоков.
• Safepoint защищает от гонок: загруженный указатель будет жив до следующего safepoint’а.

По желанию можно включить полный stop-the-world (FUGC_STW=1) для fork(2) или отладки.

• Fil-C — это С-компилятор с точным параллельным GC (FUGC) и capability-указателями, позволяющий запускать «как есть» CPython, SQLite, OpenSSH и др., теряя в худшем случае 4× производительности.
• Вместо ручного free и UB-оптимизаций LLVM код живёт под барьером Дейкстры и soft-handshake safepoint’ами; указатели превращаются в «InvisiCap» (base+offset), теряющие силу при приведении к integer.
• Проект исследовательский, но уже промышленно полезен: нет сборок под 32-бит, Windows и embedded без MMU, нет пока поколенческого GC и ARM/RISC-V.
• Споры: «lock-and-key» предсказуемее RAM, но требует атомиков; GC = «мусор потом» vs compile-time проверки; можно ли дождаться AI-стат-анализа вместо Rust-переписей.

Что такое GPU
Современная ML-GPU (H100/B200) — это ~100–150 независимых вычислительных блоков (SM), каждый из которых содержит матричное ядро Tensor Core, векторные ALU (CUDA-ядра) и 256 КБ кэш SMEM. Все SM делят общий L2 и HBM3-память. SM разбит на 4 подблока; каждый подблок выполняет 32 SIMD-операции за такт. GPU-ядро менее мощное, чем TPU TensorCore, но их много, поэтому общая гибкость выше.

Память
H100: 80 ГБ HBM3, 3 ТБ/с. B200: 192 ГБ, 8 ТБ/с. L2 кэш 50 МБ (H100) / 128 МБ (B200). SMEM даёт 256 КБ на SM.

GPU vs TPU на уровне чипа
TPU: 1–2 больших MXU, жёсткая синхронизация, векторная часть слабее. GPU: 100+ мелких ядер, независимые SM, но общий L2 ограничивает масштаб. GPU лучше для разнородных задач, TPU — для чистых матмул.

Сеть внутри узла
Узел = 8 GPU + 2 CPU. GPU соединены NVLink/NVSwitch (900 ГБ/с между любыми двумя). CPU-GPU идут через PCIe 5.0 (64 ГБ/с). NVSwitch-кроссбар внутри узла = полносвязная сеть.

Сеть за пределами узла
InfiniBand HDR/NDR (до 400 Гб/с) или Ethernet RoCE. GPUDirect RDMA позволяет GPU читать/писать память соседнего узла без участия CPU.

Коллективные операции
Intra-node: NCCL использует NVLink; all-reduce 8×H100 за ~3 мкс.
Cross-node: кольцо IB + NVLink; latency ~10 мкс, bandwidth лимит IB.

Roofline-модель для LLM

• Data Parallelism: ограничен IB; эффективен при малых моделях.
• Tensor Parallelism: ограничен NVLink; лучше внутри узла.
• Expert/ Pipeline Parallelism: комбинируем; pipeline глубже → меньше bubble, но больше весов на каждом GPU.
• TLDR: держи параллелизм так, чтобы IB не стал bottleneck; используй NVLink для tensor-parallel, IB для data-parallel.

Итого
GPU — это масса мелких, независимых SM, связанных быстрым NVLink внутри узла и медленным IB между узлами. Для LLM выбирай параллелизм, который минимизирует IB-трафик и максимально использует NVLink.

• Критика точности: документация местами неточна, особенно в определении «CUDA-core».
• Открытость и вендор-лок: ряд участников считают инвестиции в проприетарную экосистему NVIDIA рискованной ставкой.
• Ошибка в расчётах: Quiz 2 преувеличивает пропускную способность; реальные 3,2 ТБ/с ограничены портами NIC.
• Похвала и польза: серия всё же хорошо объясняет принципы параллелизма, применимые и к другим устройствам.
• Сравнение TPU и GPU: TPU проще масштабировать, но закрыт для продажи; GPU NVIDIA гибче, но сложнее в программировании.
• Дефицит официальных данных: NVIDIA не раскрывает полную архитектуру, поэтому полезные модели приходится собирать из сторонних источников.