Hacker News Digest

• Использование Datalog-подобных систем в разных контекстах: от CozoDB до CodeQL и от Rust до GPU-фреймворков.
• Обсуждение того, какие именно технологии используются в продакшене: от Datomic до CozoDB и от Soufflé до CodeQL.
• Разговор о том, какие технологии используются для запросов к данным: от SQL-подобных до Datalog-подобных.
• Обсуждение того, какие технологии используются для запросов к данным в контексте GPU: CUDA, HIP и SPIR-V.

Helion — это высокоуровневый язык для создания производительных и переносимых ML-ядер, разработанный командой PyTorch в Meta. Он разрешает конфликт между производительностью и удобством, компилируя Python-встроенный DSL в автоматически настраиваемый код Triton. Helion создает новый уровень абстракции, сочетающий простоту PyTorch с производительностью низкоуровневых языков, автоматизируя рутинные задачи вроде индексации тензоров и управления памятью. Это позволяет разработчикам сосредоточиться на алгоритмической логике, а не на аппаратно-специфичных деталях.

Текущие языки вынуждают выбирать между контролем и производительностью: CUDA дает максимум контроля, но требует значительных усилий; Triton — шаг вперед, но все еще требует ручной настройки; PyTorch прост, но ограничен в детальном контроле. Программная модель Helion, описываемая как "PyTorch с тайлами", минимизирует шаблонный код и использует знания разработчиков в PyTorch. Типичное ядро Helion состоит из двух взаимодополняющих частей, что упрощает создание правильных и эффективных ядер.

• Helion позиционируется как более высокоуровневая альтернатива Triton, упрощая написание кода за счет автоматического автотюнинга, в отличие от других DSL (Gluon, CuTe), которые предлагают больше контроля на низком уровне.
• Основные проблемы включают длительный автотюнинг (до 10+ минут), отсутствие полноценной поддержки Python-отладки (автодополнение, точки останова) и сложность выбора между множеством технологий (Triton, Gluon, JAX Pallas и др.).
• Несмотря на рост высокоуровневых фреймворков, низкоуровневые оптимизации остаются критичными для новых архитектур моделей (например, FlashAttention, MXFP4) и аппаратных платформ (NVIDIA, AMD).
• Споры о релевантности CUDA: мнения расходятся от его "устаревания" до сохранения доминирующей роли в экосистеме на годы вперед из-за зрелости инструментов и сообщества.
• Пользователи отмечают, что Helion может расширить круг разработчиков, способных писать эффективные ядра, но сомневаются в его преимуществах перед Triton/Gluon без явного выигрыша в производительности или простоте.

NextSilicon представила новый процессорный чип, бросающий прямой вызов доминированию Intel и AMD на рынке процессоров. Компания, ранее не известная как крупный игрок в этом сегменте, теперь позиционирует себя как серьезного конкурента технологических гигантов. Хотя конкретные технические детали чипа в статье не раскрываются, это событие знаменует собой важный сдвиг в конкурентной ландшафте процессорной индустрии.

Появление NextSilicon на рынке может привести к усилению конкуренции и потенциальному снижению цен для потребителей. Компания, судя по всему, стремится занять нишу в сегменте, где до сих пор доминировали два основных игрока. Это развитие может стимулировать инновации как со стороны NextSilicon, так и со стороны Intel и AMD в ответ на новую угрозу.

• СервисеHome подчеркнул, что Maverick-2 — это не векторный, а data-flow процессор, что важно для понимания его позиционирования.
• Дискуссия показала, что сравнение с Anton, A64FX и другими архитектурами неуместно, так как они решают разные задачи.
• Участники отметили, что для Maverick-2 нужен JIT-подход к софту, а не переписывание существующего кода.
• Было отмечено, что в отличии от GPGPU, Maverick-2 не требует переписывания кода под CUDA/OpenCL модель, но вместо этого требует компиляции под его нативную модель.
• В конце обсуждение сошлось на то, что если рынок действительно нуждается в таком процессоре, то NEC или другой вендор мог бы его сделать, но это не делаеться, потому что это не их фокус.

Cuq — это фреймворк, преобразующий MIR (промежуточное представление Rust) в Coq для формальной семантики и верифицированного перевода Rust-ядер GPU. Проект нацелен на PTX (язык ассемблера NVIDIA) и обеспечивает математически строгую основу для GPU-программирования на Rust.

Фреймворк позволяет формально доказывать свойства GPU-кода и обеспечивает верифицированный перевод из Rust в PTX. Это критически важно для безопасности и надежности вычислений на GPU, где ошибки могут иметь серьезные последствия. Cuq заполняет пробел между высокоуровневым Rust-кодом и низкоуровневым GPU-исполнением, предоставляя формальные гарантии корректности преобразований.

• Проект, который переводит MIR Rust в Coq для формальной верификации ядра CUDA, вызвал бурную дискуссию из-за имени «cuq».
• Участники спорят, звучит ли название как «кук» или «кью-кью»; критика имени превратилась в обсуждение культурных различий.
• Некоторые предлагают переименовать проект в «rocuda», «rocq» или «rocq», чтобы избежать нежелательных коннотаций.
• Автор отвечает, что имя строится на словах CUDA и Coq, и что он не осознавал двусмысленность; вопрос о переименовании остаётся открытым.
• Несмотря на спор, техническая ценность проекта в том, что он может формально верифицировать параллельные вычисления и уменьшить гонки за счёт формального доказательства корректности.

AMD Strix Halo — флагманский мобильный чип AMD из серии Ryzen AI MAX, сочетающий 16 ядер Zen 5 с мощной iGPU на 20 RDNA 3.5 Workgroup Processors. Особенностью чипа является 32 МБ Infinity Cache (MALL), который работает с 256-битным интерфейсом LPDDR5X-8000. Эта технология, представленная ещё в RDNA2, ранее была сложно оценить из-за ограниченных инструментов мониторинга производительности AMD, которые не предоставляли данных выше L2 кэша.

Strix Halo уникален тем, что предоставляет доступный программный счётчик производительности DATA_BW, позволяющий отслеживать трафик на различных уровнях. Автору, благодаря предоставленному ASUS ROG Flow Z13, удалось определить идентификаторы экземпляров Infinity Fabric, которые AMD не документировала. Сравнение трафика на уровнях Coherent Stations (CS) и Unified Memory Controllers (UMC) позволил создать методику оценки эффективности Infinity Cache — разница между этими показателями служит индикатором хитов в кэш-памяти.

• AMD представляет Strix Halo как игровой чип, но в дискуссии подчеркивается, что у него нет поддержки CUDA и ROCm, что делает его непригодным для локального ИИ.
• Пользователи жалуются на отсутствие документации, отсутствие поддержки и отсутствие программного обеспечения, что делает его непригодным для разработки ИИ.
• В то же время, AMD продолжает позиционировать его как "первый процессор для ИИ ПК", хотя в реальности он не может запускать большинство моделей из-за отсутствия CUDA и ROCm.
• Обсуждение также поднимает вопрос о том, что AMD не предоставляет никаких инструментов для разработки ИИ, в отличие от Nvidia, которая предоставляет CUDA и cuDNN.

• Обсуждение в основном вращается вокруг проблемы установки и совместимости PyTorch/CUDA, причем участники отмечают, что «просто поставить pip install torch» редко работает из-за несовпадающих бинарников и отсутствия удобного менеджера зависимостей.
• Несколько участников подчеркивают, что NVIDIA, будучи вендором и железа и драйверов, предоставляет довольно устаревшие сборки PyTorch, что вызывает трудности даже при попытке запустить тестовый «hello world» на свежей ОС.
• Участники также обсуждают, что вместо того, чтобы тратить время на «собирание» PyTorch, можно было бы просто взять готовый wheel-файл, который бы с большей вероятностью был бы совместим с готовой CUDA-версией.
• Некоторые комментаторы также упоминают, что вместо того, чтобы тратить время на «сборку» PyTorch, можно было бы просто взять готовый wheel-файл, который бы с большей вероятностью был бы совместим с готовой CUDA-версией.

The the the the the the the the the the the the the the the the the my my my pan pan is the the the my pan the the last one I am g t g t g t g t g t The 3 7 15 3 7 15 3 7 5 6 2 8 you 12 2 12 2 10 10 10 11 10 10 11 10 10 11 9 9 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10

• Обсуждение касается сравнения локального RTX 3090 и облачных A100 по стоимости и скрытым расходам, включая передачу данных и отладку CUDA.
• Участники обсуждают, насколько книга «Build a Large Language Model from Scratch» полезна и насколько она дополняет или дублирует онлайн-материалы.
• Участники упоминают, что проект «с нуля» в стиле Karpathy и nanochat может быть переосмыслен как «рецепт для зла».
• Сообщество обсуждает, насколько полезен опыт работы с Keras и другими фреймворками для понимания механизмов внимания и трансформеров.

NVIDIA представила DGX Spark - настольный "суперкомпьютер" для ИИ размером с Mac mini, стоимостью около $4,000. Внутри скрывается ARM64-система с 20-ядерным процессором, 128 ГБ ОЗУ и 3.7 ТБ SSD, а также мощный GPU NVIDIA GB10 на архитектуре Blackwell с 119.68 ГБ памяти. Устройство нацелено на исследователей ИИ, предназначено как для обучения, так и для запуска моделей.

Основная проблема - совместимость CUDA с ARM64. Большинство библиотек и туториалов предполагают x86-архитектуру, что создает множество сложностей при настройке. Автору удалось найти PyTorch 2.7 для CUDA на ARM, но не для версии 2.8. NVIDIA пытается упростить задачу через официальные Docker-контейнеры, а за последний недобю опубликовала обширную документацию, которой не хватало изначально.

• Обсуждение в основном вращается вокруг сравнения DGX Spark с другими решениями: пользователи отмечают, что при цене в $70 000 он уступает RTX 5090 в производительности и даже RTX 4090, а единственное преимущество — 128 ГБ видеопамяти — ограничено пропускной способностью, что делает его неэффективным для инференса больших моделей.
• Участники также поднимают вопросы о цене, отсутствии DisplayPort и возможности подключения к обычному монитору, а также о том, что DGX Spark не может использоваться для обучения из-за ограниченной памяти и отсутствия NVLink.
• Некоторые комментаторы сравнивают его с MacBook Pro на Apple Silicon, отмечая, что ноутбук дешевле и при этом предлагающий 128 ГБ единой памяти может быть более практичен для инференса.
• Также обсуждается, что NVIDIA в целом не предоставляет нужного ПО для ARM64, что делает его менее привлекательным, и что в целом экосистема CUDA вокруг ARM64 остается сырой.

AMD заключила сделку с OpenAI о поставках чипов для искусственного интеллекта, предоставив также опцион на приобретение 10% доли в компании. Это стратегическое партнёрство усиливает позиции AMD на рынке AI-чипов, где доминирует NVIDIA, и обеспечивает OpenAI доступ к передовым аппаратным решениям для разработки и масштабирования своих моделей.

Опцион на долю демонстрирует глубокую интеграцию интересов: AMD получает ключевого клиента и потенциального инвестора, а OpenAI — влияние на поставщика и приоритетный доступ к технологиям. Это может ускорить инновации в области аппаратного обеспечения для ИИ и снизить зависимость от единственного поставщика.

• AMD предоставила OpenAI опцион на покупку 10% своих акций по цене $0.01 за акцию при выполнении определенных условий
• Сделка призвана стимулировать OpenAI к закупкам GPU AMD на сумму до $100 млрд и совместной разработке ПО для AI-чипов
• Рыночная капитализация AMD выросла примерно на $100 млрд после анонса, что частично компенсирует стоимость опциона
• Многие участники обсуждения расценивают сделку как признак финансового пузыря и циркулярных денежных потоков в AI-индустрии
• Партнерство рассматривается как стратегический ход для создания альтернативы доминированию NVIDIA и CUDA

Newton — это открытый движок для физического моделирования с ускорением на GPU, построенный на основе NVIDIA Warp. Он предназначен для робототехников и исследователей в области симуляций, предлагая высокопроизводительные вычисления для задач, требующих точного и быстрого физического эмулирования.

Проект фокусируется на эффективности и доступности, используя современные графические процессоры для ускорения расчётов. Это позволяет исследователям быстрее тестировать алгоритмы и моделировать сложные среды, что особенно ценно в разработке робототехнических систем и научных экспериментах.

• Критика выбора Python как основного языка для библиотеки из-за проблем с производительностью, ошибками и сложностью работы с типами.
• Негативная реакция на название "Newton Physics" из-за возможной путаницы с существующим движком Newton Dynamics и воспринимаемой arrogance авторов.
• Обсуждение технических деталей: использование MuJoCo как бэкенда, запись в CUDA graph для производительности, параллелизация множества сред для reinforcement learning.
• Сравнение с PhysX и мнение, что Newton Physics со временем его заменит, будучи более настраиваемым и расширяемым.
• Замечания о недостатках примеров кода, которые слишком высокоуровневы и не демонстрируют реальные преимущества и сложности использования API.

Выпущена StringZilla v4 — первая версия библиотеки для обработки строк с поддержкой CUDA, которая ускоряет вычисления на GPU. Она обеспечивает до 500 гигаопераций в секунду для расчёта расстояний Левенштейна и других метрик схожести строк, что в 109 раз быстрее решений на NVIDIA H100. Библиотека оптимизирована для больших объёмов данных в базах данных, биоинформатике и информационном поиске, включая алгоритмы с аффинными штрафами за разрывы и мини-хэширование.

Новые функции включают хэш-функции на основе AES, генераторы псевдослучайных строк и алгоритмы сортировки для работы с коллекциями строк. StringZilla использует SIMD-инструкции на CPU и GPU, поддерживает несколько архитектур и языков программирования. Библиотека распространяется под лицензией Apache 2.0 и доступна через pip, предлагая надёжный и быстрый базис для масштабируемых workloads.

After publishing this a few days ago, 2 things have happened.First, it tuned out that StringZilla scales further to over 900 GigaCUPS around 1000-byte long inputs on Nvidia H100. Moreover, the same performance is obviously accessible on lower-end hardware as the algorithm is not

Упрощённые версии GRU и LSTM (minGRU и minLSTM) позволяют заменить последовательные вычисления на параллельные, устраняя зависимость скрытого состояния от предыдущего шага. Это достигается за счёт переопределения гейтов так, чтобы они зависели только от текущего входа, что превращает рекуррентное обновление в линейную форму, разрешимую алгоритмом параллельного сканирования (scan). Такой подход сокращает сложность с O(T) до O(log T), что критично для ускорения на GPU.

Реализация на CUDA демонстрирует значительное ускорение: для последовательностей длиной 65 536 шагов время выполнения сокращается с ~13 секунд на CPU до ~5,3 секунд на GPU для GRU и с ~13 до ~6,7 секунд для LSTM. На коротких последовательностях (T < 2048) преимущество менее выражено из-за накладных расходов на распараллеливание, но с ростом длины масштабирование становится явным. Это подтверждает, что даже минимальные изменения в архитектуре RNN могут радикально улучшить их производительность на параллельных вычислениях.

• Обсуждаются архитектурные ограничения классических RNN/LSTM, в частности их последовательная природа, препятствующая эффективному распараллеливанию на GPU.
• Представлены упрощённые модели (minGRU, minLSTM) и альтернативные архитектуры (например, RWKV), которые пытаются устранить эти ограничения и конкурировать с трансформерами.
• Поднимается вопрос о возможности параллельного обучения RNN на разных независимых текстах (книгах) и обсуждаются сложности синхронизации градиентов.
• Уточняется, что мозг человека вряд ли является RNN, и выдвигаются альтернативные гипотезы о его работе, например, как модели поиска устойчивого состояния (equilibrium model).
• Обсуждается исторический контекст: почему трансформеры, несмотря на потенциальную эффективность RNN, стали доминировать благодаря лучшей параллелизации обучения.

Навигационное меню GitHub с разделами:

- Платформа: Copilot, Spark, Models, Advanced Security, Actions, Codespaces, Issues, Code Review, Discussions, Code Search
- Решения: для предприятий, малых команд, стартапов, некоммерческих организаций
- Ресурсы: статьи по AI, DevOps, безопасности, разработке ПО
- Open Source: спонсоры, проекты, репозитории
- Enterprise: платформа, дополнения
- Цены

Поиск кода, репозиториев, пользователей, issues и pull requests. Возможность сохранения поисковых запросов.

• NVIDIA Tilus представляет собой низкоуровневый инструмент для контроля над регистрами, возможно, как ответ на Triton, который поддерживает AMD и другие ускорители, угрожая экосистеме CUDA.
• Название Gluon уже используется несколькими проектами, включая язык для ML от Amazon/Microsoft, UI-тулкит для Java и встраиваемый язык для Rust, что создает путаницу.
• Gluon от NVIDIA рассматривается как сходный с их же CUTE DSL, что указывает на convergence к оптимальному дизайну Python-based DSL для программирования ядер.
• Мнения разделились: одних смущает, что «язык» остается кодом на Python, требующим трассировки, другие считают такой подход на основе AST-walker эффективным.
• Появление Gluon связано со сложностями Triton в достижении высокой эффективности на новых архитектурах NVIDIA, таких как Blackwell.
• NVIDIA разрабатывает множество DSL, что свидетельствует о их беспокойстве из-за открытых и портируемых альтернатив CUDA.
• На экосистему CUDA оказывают давление крупные компании, разрабатывающие собственные чипы для AI, чтобы избежать зависимости от NVIDIA.

Алибаба представила новый ИИ-чип с характеристиками, сопоставимыми с H20.

• Китай запретил закупки чипов NVIDIA и стимулирует развитие собственных AI-чипов, чтобы сократить технологический разрыв
• Китайские чипы (например, от Alibaba) пока уступают флагманским GPU NVIDIA (Blackwell, H100) и сравнимы с более старыми моделями (A100, H20)
• Ключевым барьером NVIDIA считается не столько hardware, сколько программная экосистема (CUDA), создающая сильную привязку клиентов
• Экспортные ограничения США вынуждают Китай развивать собственное производство, но возникают проблемы с качеством, совместимостью и производительностью
• Вопросы вызывают возможности Китая в передовой литографии (EUV) без доступа к оборудованию ASML
• Часть комментаторов расценивает новости как пропаганду или считает, что успехи Китая основаны на краже IP и господдержке без оглядки на прибыль
• Сокращение доступа к NVIDIA может замедлить развитие AI в Китае, но также стимулирует глобальную конкуренцию и снижение цен на GPU

Почему LLM неповторяемы и как это исправить

Проблема
Даже при temperature=0 и одном железе выводы моделей различаются от запуска к запуску. Популярное объяснение: «параллельные GPU-ядра + погрешности float = недетерминизм». Это не вся правда.

Что на самом деле происходит

1. Все «математические» ядра (matmul, softmax и т.д.) внутри одного forward-прохода детерминированы — бит-в-бит.
2. Недетерминизм появляется между forward-проходами:
   • динамическое разбиение работы на потоки (different thread blocks);
   • неупорядоченные редукции при вычислении softmax/layernorm;
   • разные стратегии cudnn/cublas в зависимости от загрузки GPU;
   • кэш-промахи и atomicAdd в attention.

Как убедиться

A = torch.randn(2048, 2048, device='cuda', dtype=torch.bfloat16)
B = torch.randn(2048, 2048, device='cuda', dtype=torch.bfloat16)
ref = A @ B
for _ in range(1000):
    assert (A @ B == ref).all()   # всегда True

Матричное умножение повторяется, а вот softmax(A @ B) — уже нет.

Побеждаем за 3 шага

1. Фиксируем редукции

   • torch.use_deterministic_algorithms(True)
   • CUBLAS_WORKSPACE_CONFIG=:4096:8 (для CUDA ≥10.2)
   • export CUDA_LAUNCH_BLOCKING=1 (медленно, но зато стабильно).

2. Отключаем динамические алгоритмы

   • torch.backends.cudnn.deterministic = True
   • torch.backends.cudnn.benchmark = False
   • в vLLM: --disable-custom-all-reduce, --enforce-eager.

3. Контролируем параллелизм

   • фиксированный батч и длина последовательности;
   • один GPU-поток (tensor_parallel_size=1);
   • один и тот же порядок запросов (queuing seed).

Результат
На Llama-3-8B с vLLM + указанными флагами 1000 прогонов дают идентичные токены вплоть до последнего бита. Стоимость: ≈8 % к throughput.

TL;DR
Недетерминизм — не «float плавает», а race-conditions вне математического ядра. Убери их, и LLM станет строго воспроизводимым.

• Корень проблемы: «один и тот же» запуск LLM выдаёт разные токены из-за race-конкуренции ядер, неассоциативности float и недетерминированных GPU-ядёр; авторы показали, как зафиксировать порядок операций и получить бит-в-бит повтор.
• Практика: temperature=0 ≠ гарантия: во-первых, библиотеки всё равно подкладывают ε>0, во-вторых, MoE-модели выбирают экспертов в зависимости от состава батча, поэтому даже «одинаковый» запуск в API почти никогда не повторяется.
• Зачем нужна детерминированность: CI-тесты, отладка багов, шеринг промптов между разработчиками, валидация через LLM, агентские цепочки и RL-обучение требуют, чтобы «один и тот же вход = один и тот же выход».
• Ограничения: статья решает только замкнутую задачу inference-ядер; контекст, семантически эквивалентные формулировки и много-нодовые коллективы остаются источником разброса; при temperature>0 нужен фиксированный PRNG-сид.

• Япония продолжает финансировать Pezy Computing, создающую энергоэффективные математические ускорители SC4S/SC5, способные заменить GPU в HPC и ИИ.
• SC4S: 2 048 ядер, 8 TFLOPS FP64, 200 Вт, 40 нм; SC5: 16 384 ядер, 64 TFLOPS FP64, 400 Вт, 7 нм; оба используют SIMD и обходятся без HBM, охлаждаясь жидкостью.
• Ускорители уже стоят в 6-8 системах ТОП500; пиковая энергоэффективность 32 GFLOPS/Вт.
• Драйверы OpenCL/CUDA-аналог ZCL, компиляторы Fortran/C++ готовы; в 2026-2027 ждут SC6 (128 TFLOPS FP64, 7 нм) и SC7 (E级, 3 нм).
• Цель: 10× экономия энергии и долгая независимость от NVIDIA/Intel.

• Япония развивает собственные HPC-акселераторы (Pezy и др.), ориентированные на FP64 и традиционные суперкомпьютерные задачи, а не на ИИ-низкоточность.
• Эти чипы создаются под кластеры с жидкостным охлаждением и продаются не поштучно, а целыми стойками.
• Производительность FP64 у Pezy конкурентна с NVIDIA, но энергоэффективность и программное окружение NVIDIA пока непревзойдены.
• Японские компании и государство инвестируют в HPC-экосистему, чтобы сохранить технологический суверенитет и не зависеть от американских GPU.
• Участники обсуждают, насколько целесообразно переключение на альтернативные форматы чисел (posits) и почему правительства продолжают финансировать «собственных лошадей» несмотря на риск провала.

• Крис Латтнер (LLVM, Swift) делает новый язык Mojo, чтобы ML-код был быстрым и удобным.
• Проблема: GPU-ядра пишутся на CUDA/OpenCL вручную, медленно и зависят от одного вендора.
• Решение: язык с метапрограммированием и типами, который «знает» об аппаратуре и генерирует оптимальный код под любую платформу.
• Цель: один код → любой GPU/CPU, открытая экосистема, no lock-in.

• Mojo обещает «Python++, но быстрый», но до сих пор нет полноценных классов, а «полный суперсет» превратился в мягкое «всё ещё не Python».
• Лицензия проприетарная — для многих это стоп-фактор: «сделайте GPL или идите лесом».
• Экосистема Python неподвластна: все уже завязаны на PyTorch/CUDA, а Mojo пока не даёт причин мигрировать.
• Julia, Elixir/Nx, CuPy, Triton, Numba — всё уже умеют «быстро + GPU», без нового языка.
• Итог: Mojo выглядит технически интересным, но «ещё один закрытый язык» в 2025 году воспринимается как ненужный риск.

Плюсы Nim 2

• Память: по умолчанию ORC/ARC (RAII, деструкторы, move/copy), а не трассирующий GC. Можно --mm:none или --mm:atomicArc.
• Компилируется в C/C++/Obj-C/JS; выбираем компилятор (gcc, nvcc, …).
• Лёгкая интеграция: {.importc.}, {.importcpp.}, {.importjs.}, {.compile.} для сторонних файлов.
• Метапрограммирование: макросы, static исполнение кода на этапе компиляции, генерация CUDA.
• Краткость: мало шаблонного кода (чат на 70 строк).
• Производительность ≈ C/C++/Rust; поддержка SIMD, CUDA.

Минусы и подводные камни

• Генерируемый C/C++ код нечитаем — не цель проекта.
• Нет атомарных счётчиков в ORC по умолчанию (требуется флаг).
• Некоторые старые статьи/комментарии описывают Nim 1.x (GC по умолчанию).
• Синтаксис чувствителен к отступам и регистру (но это субъективно).

Мини-пример: простой key/value формат

import std/[tables, strutils]

type Config = object
  host*: string
  port*: int

proc loadConfig(path: string, T: typedesc): T =
  let data = readFile(path).splitLines()
  var kv = initTable[string, string]()
  for line in data:
    let parts = line.split('=')
    if parts.len == 2:
      kv[parts[0].strip()] = parts[1].strip()

  result.host = kv.getOrDefault("host", "localhost")
  result.port = parseInt(kv.getOrDefault("port", "8080"))

let cfg = loadConfig("app.conf", Config)
echo cfg.host, ":", cfg.port

Файл app.conf:

host = 0.0.0.0
port = 9000

Всё компилируется в один бинарник без GC-задержек.

• Пользователи отмечают редкую, но полезную возможность Nim — определять собственные операторы.
• Хвалят макросы, интегрированные в систему типов и перегрузку, сравнивая язык с «статически типизированным Lisp».
• Критика: сложности с Windows (Nimble-зависимости тянут GCC, Defender блокирует бинарники) и неоднозначная «фантастическая» интеграция с C++.
• Обсуждают объём JS-артефактов: для мелких примеров — десятки килобайт, но без оптимизации могут быть мегабайты.
• Для WASM рекомендуют компилировать в C и прогонять через Emscripten, но стандартные JS-биндинги не работают.
• Вопросы IDE: есть nimsuggest и быстрая настройка для Neovim, но плагинов для JetBrains почти нет.

fluid-sims — коллекция симуляций жидкости от seanwevans.
Репозиторий публичный, доступен без авторизации.

• Пользователи восторженно отреагировали на стиль Jos Stem и 3D-демо.
• @clbrmbr попросил сделать GPU-анимацию всего одной строки.
• @petermcneeley поделился примером realtime-флюида на WebGPU.
• @glouwbug задался вопросом, хватит ли CPU для уравнения Бюргерса.
• @dahart считает, что при низком разрешении и Navier–Stokes спокойно укладывается в CPU.

• DGX Spark — компактный «суперкомпьютер» на базе процессора Grace Blackwell, помещающийся на столе.
• Поддерживает обучение и инференс ИИ-моделей любого размера благодаря архитектуре Grace Blackwell и 128 ГБ унифицированной памяти.
• Подключается к DGX Cloud для масштабирования задач и работает в экосистеме NVIDIA AI Enterprise.
• Поставляется с полным стеком ПО: CUDA, cuDNN, TensorRT, NeMo, RAPIDS и другими фреймворками.
• Подходит исследователям, стартапам и инженерам, которым нужна локальная мощность без серверной.

• Jetson Thor и DGX Spark работают на зафиксированном ядре Linux от NVIDIA на Ubuntu 20.04, обновления ограничены, как на китайских SBC.
• Spark: 1000 FP4-TOPS, 128 ГБ LPDDR5x, 273 ГБ/с пропускная способность, цена $3999; по $/производительность проигрывает 5090 и Thor.
• Узкое место — низкая пропускная способность памяти: в 4 раза меньше RTX 4090 и в 8 раз меньше M4 Max, что ограничивает обучение и крупные LLM.
• Устройство позиционируется как devkit для прототипирования и дообучения, а не как универсальный ПК; потребление и дата выхода не раскрыты.
• Многие считают цену завышенной и ждут сравнения с будущими Mac Studio M4/M5 Ultra и AMD Strix Halo.

Flash Attention на 5090 в CUDA C++

Цель — научиться писать attention-ядро на CUDA C++, чтобы использовать MXFP8/NVFP4 MMA для sm120, чего нет в Triton.
Код: learn-cuda/07_attention.

Бенчмарк (bs=1, heads=8, q=4096, kv=8192, BF16, 5090@400 W, CUDA 12.9, SOL 209.5 TFLOPS):

ядро	TFLOPS	%SOL
F.sdpa (Flash)	186.73	89.13
F.sdpa (CuDNN)	203.61	97.19
flash-attn	190.58	90.97
v1 (basic)	142.87	68.20
v2 (swizzle)	181.11	86.45
v3 (2-stage)	189.84	90.62
v4 (ldmatrix.x4)	194.33	92.76
v5 (pipe)	197.74	94.39

---

Алгоритм Flash Attention 2

Псевдокод:

scale = DIM**-0.5
for b, tile_Q:
    tile_O = 0
    tile_Q = load(Q[b, tile_Q])
    for tile_KV:
        tile_K = load(K[b, tile_KV])
        tile_S = tile_Q @ tile_K.T * scale
        online_softmax(tile_S)  # in-place
        tile_V = load(V[b, tile_KV])
        tile_O += tile_S @ tile_V
    store(O[b, tile_Q])

head_dim=128 помещается в регистры.

---

v1 — базовая версия

1. G2S: cp.async.ca.shared.global 128-битными транзакциями.
2. S2R: ldmatrix для Q, K, V → 8×8 фрагменты.
3. Softmax online:
   • m = max(m_prev, m_curr)
   • d = d_prev * exp(m_prev - m) + Σ exp(S - m)
   • O = O_prev * (d_prev/d) * exp(m_prev - m) + (exp(S - m)/d) @ V

---

v2 — swizzled shared memory

• 128-битные банки → конфликты при 8×8 tile.
• Swizzle K и V по 32-битным строкам; Q оставляем линейно.
• +40 % пропускной способности.

---

v3 — 2-stage pipeline

• Двойной буфер: пока вычисляем S/P@V, асинхронно грузим следующий KV.
• cp.async.commit_group() + cp.async.wait_group(1).
• +5 % к SOL.

---

v4 — ldmatrix.x4

• Одна инструкция ldmatrix.x4 загружает 4×8×8 фрагмента K/V за раз.
• Снижает инструкций на 25 %.
• +2 % к SOL.

---

v5 — улучшенный pipeline

• 3-4 стадии:
  1. prefetch KV
  2. compute S
  3. compute P@V
  4. write-back O
• __pipeline_wait_prior(N) + __pipeline_commit().
• +2 % к SOL.

---

Что дальше

• Использовать TMA (cp.async.bulk) и NVFP4/MXFP8 MMA.
• Поддержка head_dim > 128 (FlashMLA).

• Пользователи удивлены, что RTX 5090 даёт всего 209 TFLOPS BF16 — менее 10 % от серверного Blackwell B200 (2250 TFLOPS), но при цене ~$30-40 k за B200 соотношение цена/производительность почти сравнялось.
• Обсуждают, что NVIDIA с 4090 и далее искусственно ограничивает тензорные ядра игровых карт для ML-операций FP8/FP16.
• У 5090 выше TDP, чем у 4090, и можно ограничить мощность лишь до 70 % (4090 — до 50 %), что мешает апгрейду для ML-станций.
• Появились вопросы о поддержке Flash Attention на 5090/5080 и о нативной компиляции под Blackwell в PyTorch 2.7.
• Участники спорят, стоит ли вкладываться в Triton, если нужны фирменные типы NVFP4/MXFP8, которых там пока нет.

Краткий гайд по «vibe-coding» для экспертов

Даже 20-летний ветеран или создатель алгоритмов не «слишком крут» для vibe-coding. Автор — мейнтейнер 200+ пакетов, сооснователь стартапа и лаборатуры MIT — тоже сначала презирал LLM-генерированный код. Месяц назад изменил мнение: 32 агента Claude крутятся в tmux, к ним можно зайти с телефона и «продолжать вибро-кодить».

Почему экспертам это нужно

• LLM не заменяют, а ускоряют мышление.
• Рутинные куски (бойлерплейт, тесты, доки) отдаются за секунды.
• Мозг занят архитектурой и отладкой, а не синтаксисом.

Ключевые правила

1. Точный промпт
   «Напиши CUDA-ядро, которое…» лучше «сделай быстро».
2. Маленькие итерации
   Генерируй, проверяй, коммить, повторяй.
3. Ревью как обычно
   Эксперт всё равно решает, правильно ли.
4. Автоматизация
   tmux + ssh + скрипты = код 24/7.

Итог
Vibe-coding — это не про «глупый код», а про умное распределение внимания.

• Критика статьи: название «для программистов, ненавидящих свою работу», советы слишком общие, нет практики по контексту, RAG и MCP.
• Vibe-coding воспринимается как «ведение скрамов» или «управление офшором»: нравится не всем, особенно тем, кто любит сам процесс программирования.
• Сторонники считают LLM просто новым уровнем абстракции и способом быстрее строить продукты; скептики боятся атрофии навыков и невозможности ревью «тысяч строк кода».
• Практический совет: дробить задачи на мелкие шаги, давать примеры, проверять каждый модуль, играться с инструментами, чтобы выработать интуицию.
• Итог: для личных/малых проектов — работает, для больших коммерческих систем — спорно; эффективность зависит не от звания, а от умения чётко задавать контекст и перепроверять результат.

luminal — библиотека для глубокого обучения, работающая «со скоростью света».

Основное

• Язык: Rust
• Цель: максимально быстрое вычисление градиентов и обучение нейросетей.
• Подход: компиляция вычислительного графа в высокооптимизированный нативный код (LLVM).

Возможности

• Автоматическое дифференцирование.
• JIT-компиляция графов.
• Поддержка CPU и GPU (CUDA).
• Минимальные накладные расходы: нет Python-интерпретатора и лишних библиотек.

Примеры

let x = Cpu::tensor([1.0, 2.0, 3.0]);
let y = x.relu().sum();
let g = y.backward(); // градиент за наносекунды

Установка

cargo add luminal

Статус

Проект в активной разработке; API может меняться.

• Luminal — это ML-фреймворк, который вместо ручных правил формулирует оптимизацию как поиск по огромному пространству возможных ядер (tiling, потоки, инструкции и т.д.) с помощью e-graphs.
• Сейчас на M-серии MacBook Llama-3 8B Q8 выдаёт 15-25 ток/с; это ниже llama.cpp, но команда строит трекер производительности и продолжает улучшать поиск.
• Поиск ограничен 12 базовыми линейно-алгебраическими операциями, что делает задачу похожей на «superoptimisation» и позволяет добавлять аппаратно-специфичные инструкции (tensor cores, PTX/ASM) без роста frontend.
• Для оценки качества ядра используется реальное время выполнения на целевом железе; масштабировать планируют распараллеленным профилированием на кластерах GPU.
• Отличие от TVM/tinygrad — единое пространство поиска, включающее как параметры тайлинга, так и алгебраические преобразования (например, softmax → flash-attention).

Что такое 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 не раскрывает полную архитектуру, поэтому полезные модели приходится собирать из сторонних источников.

Проблема: модель gpt-oss-20b.gguf не запускается в Ollama.
Симптом: при попытке ollama run процесс зависает на 0 % и через минуту падает без явной ошибки.

Окружение:

• Ubuntu 22.04, 64 ГБ ОЗУ, RTX 4090
• Ollama 0.3.6 (AppImage и Docker)
• Файл gpt-oss-20b.q4_0.gguf взят из официального репозитория TheBloke, 11 ГБ

Лог:

ggml_cuda_init: found 1 CUDA device
llama_model_load: error loading model: missing tensor 'token_embd.weight'
llama_load_model_from_file: failed to load model

Причина: в GGUF-файле отсутствует обязательный тензор token_embd.weight.

Решение:

1. Перекачать модель (curl -L -o gpt-oss-20b.q4_0.gguf …) и проверить хэш.
2. Если проблема сохраняется — использовать другой квант (q4_K_M или q5_0).
3. Либо конвертировать оригинальные веса самостоятельно через llama.cpp/convert.py.

• Ollama отказалась от llama.cpp в пользу собственной обвязки над ggml, что ломает совместимость с GGUF-моделями и вынуждает «переизобретать велосипед».
• Пользователи жалуются на проприетарные квантизации, отсутствие поддержки шардированных GGUF > 48 ГБ и игнорирование upstream.
• Альтернативы: запуск llama-server напрямую или готовые контейнеры Ramalama / Docker Model Runner.
• Сторонники Ollama отмечают удобство установки и готовые модели, но критики считают это «эншитификацией» и подготовкой к монетизации.

Переписал Ghuloum-туториал на Python (~300 строк). Убрал читалку S-выражений и бинарный код — теперь текстовая ассемблерная печать.

Lambda-lifting требует:

• знать связанные переменные;
• собирать свободные переменные лямбд;
• накапливать создаваемые code-объекты.

Связывают let и lambda; для них обновляем окружение.

Lifter

class LambdaConverter:
    def __init__(self):
        self.labels = {}

    def convert(self, expr, bound, free):
        match expr:
            case int() | Char() | bool():
                return expr
            case str() if expr in bound or expr in BUILTINS:
                return expr
            case str():
                free.add(expr)
                return expr
            case ["if", t, c, a]:
                return ["if",
                        self.convert(t, bound, free),
                        self.convert(c, bound, free),
                        self.convert(a, bound, free)]

lift_lambdas запускает обход и возвращает (labels …).

Lambda

Лямбда:

• связывает параметры;
• выделяет код;
• захватывает внешнее окружение.

Пример:

(lambda () x)  ; x свободна

превращается в

(labels ((f0 (code () (x) x)))
  (closure f0 x))

Даже если x связан снаружи, внутри лямбды он считается свободным.

• Участники рекомендуют три современные книги по компиляторам, вдохновлённые статьёй Ghuloum: «Writing a C Compiler» (Sandler), «Essentials of Compilation» на Racket и Python (Siek).
• Обсуждали «lambda lifting»: преобразование, выносящее замыкания наверх, уменьшая их размер вплоть до полного исчезновения.
• Уточнили, что «lambda lifting» в статье связан с разделом 3.11 о сложных константах в Scheme.
• Разбирали, почему современный ИИ использует Python, а не Lisp: удобство как «клея» для C++/CUDA, упадок доли рынка Lisp и смена парадигмы ИИ.

Framework Desktop — компактный 4,5-литровый ПК, который почти не шумит даже под полной нагрузкой. Внутри — мобильный AMD Ryzen AI Max 395+ (16 ядер Zen5, 5,1 ГГц), и он оказывается быстрее старого Ryzen 9 7950X в большом корпусе.

Корпус разукрашивается 21 сменной плиткой, можно печатать свои. Внешне — свежий минимализм вместо алюминия и RGB.

По производительности:

• Docker-тест HEY: почти вдвое быстрее Beelink SER8 и на 40 % опережает M4 Max.
• Geekbench 6 multi-core: на уровне M4 Max, заметно выше M4 Pro и Core i9-14900K.
• Одноядерка уступает Apple ≈20 %, но для многопоточных задач это лидер.

Цена выше, чем у Beelink, но пока это единственный безвентиляторный 395+ на рынке.

• Framework Desktop с Ryzen AI Max+ 395 даёт 64–128 ГБ единой памяти, позволяя запускать крупные LLM без дискретной видеокарты и дешевле, чем Mac Studio, но дороже Mini.
• Производительность ниже CUDA-карт Nvidia и M4 Max, зато выше, чем у iGPU Intel и старых решений.
• Многие сомневаются в цене и форм-факторе: за те же деньги можно взять Minisforum, Beelink, HP Z2 Mini или собрать полноценный десктоп.
• Пока CUDA-стека нет, AMD-совместимость с популярными AI-фреймворками ограничена.
• Ремонтопригодность и модульность Framework оценили, но в десктоп-сегменте это не уникально.