Упорный разработчик, конечно. Успехов ему в этом нелёгком деле

Выпуск ZLUDA 5, универсальной открытой реализации технологии CUDA
https://www.opennet.ru/opennews/art.shtml?num=63997

Анджей Яник (Andrzej Janik) представил выпуск ZLUDA 5, открытой реализации технологии CUDA. Целью проекта является предоставление возможности запуска немодифицированных приложений CUDA на системах с GPU, отличными от GPU NVIDIA, с производительностью, близкой к производительности приложений, выполняемых без прослоек. Код проекта написан на языке Rust и распространяется под лицензиями MIT и Apache 2.0.

ZLUDA 5 стал вторым значительным выпуском проекта, сформированным после чистки кодовой базы от кода, разработанного во время работы Анджея в компании AMD. С 2022 года Анджей работал в AMD над созданием слоя для совместимости GPU AMD с CUDA, но в 2024 году проект был свернут. В соответствии с условиями контракта и после получения разрешения на публикацию от представителя AMD, Анджей открыл код наработок, созданных во время работы в AMD и позволяющих выполнять CUDA-приложения поверх стека ROCm и runtime HIP (Heterogeneous-computing Interface for Portability).

В прошлом году Анджей был вынужден убрать код из открытого доступа после письма от юристов, давших понять, что разрешение, данное в ходе переписки по email, не имеет юридической силы. После этого Анджей начал работу над новой редакцией ZLUDA, сформированной на основе кодовой базы, существовавшей до начала работы Анджея в AMD. В текущем виде разработка сосредоточена на выполнении приложений, использующих CUDA для ускорения задач, связанных с машинным обучением. Проект пока ограничивается работой на GPU AMD, но в дальнейшем будет адаптирован для GPU Intel.

Оригинал
ZLUDA update Q3 2025 – ZLUDA 5 is here
https://vosen.github.io/ZLUDA/blog/zluda-update-q3-2025/

круговорот ветеранов сво в природе

>Короче в нас рофл: інтегрую в систему один індійський ейрлайн. В них є апі сендбокс в якому немає фейк карти для оплати. Кажуть: а ви своєю поки користуйтесь, а ми вам гроші потім повернемо.

Недавно я ехал в такси и видел на экране автомобиля какое-то музыкальное видео с YouTube, у которого в качестве иллюстрации было статичное изображение с надписью "2016 nostalgia". Первой моей мыслью было "какая ещё нафиг ностальгия, это ж всего 2016 год". А потом подсчитал, что 2016 год вообще-то был девять лет назад.

#prog #cpp #meme

Сегодня в баре цепанул парочку, которые поблагодарили меня за мой банан

Бубубу бебебе

#video

Рекурсивный Bad apple

(крайне не советую смотреть, если вы страдаете эпилепсией)

#prog #go #article

How we found a bug in Go's arm64 compiler

TL;DR: для горутин с большим стеком (больше, чем может быть закодировано в литерале в одной инструкции на ARM) в эпилоге функций изменение sp, регистра, указывающего на верхушку стека, происходило через две операции ADD, обе из которых оперировали на sp непосредственно. Если переключение (preemption) между горутинами происходило между этими двумя операциями, любые операции, которые разворачивали стек — в частности, сборщик мусора — следовали вверх по стеку вызовов по частично обновлённому и потому невалидному значению из sp, и в результате предсказуемо крашились.

Может, ввести отдельный хештег для историй дебага? 🤔

#prog #article

Cloudflare just got faster and more secure, powered by Rust

Про то, как в Cloudflare заменяют (пока что не довели до конца, но закончат к началу 2026 года) так называемый FL, центральный компонент своих сервисов. Заголовок несколько вводит в заблуждение: Rust определённо помогает, но большая часть хороших вещей из новой версии связана с архитектурой.

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

Отдельно хочу отметить, что часть про отсутствие IO язык с системой эффектов (даже такой примитивной, как в Haskell) мог бы предовтращать надёжно на уровне компилятора, а не соглашений, так что конкретно тут Rust не помогает.

+1

#prog #article

Know your SCM_RIGHTS

TIL что в Linux (на самом деле UNIX) есть способ передавать файловые дескрипторы между процессами. И эти файловые дескрипторы могут быть в том числе TCP- и UDP-сокетами.

#prog #cpp #rust #article

Why we didn't rewrite our feed handler in Rust

Отдельно отмечается, что Rust в технологическом стеке в этой компании уже есть и успешно используется. Проблемы возникли с переписыванием конкретного компонента, который уже есть и написан на C++. Конкретно в тексте приведены три паттерна, которые валидны в C++ и не выразимы или выразимы неудобно на Rust.

Первое касается ограничений borrow checker-а. Вот какой пример приводят:

fn process_source(sources: Vec<Source>) {
    for source in sources {
        let mut buffer: Vec<&[u8]> = Vec::new();
        let data: Vec<u8> = source.fetch_data();
        buffer.extend(data.split(splitter));
        process_data(&buffer);
    }
}

Простой и понятный код — но, к сожалению, выделяющий память в цикле. Логично было бы вынести аллокацию за цикл и очищать буфер в конце — но тогда компилятор не даёт скомпилировать код:

error[E0597]: `data` does not live long enough
  --> src/lib.rs:32:23
   |
31 |         let data: Vec<u8> = source.fetch_data();
   |             ---- binding `data` declared here
32 |         buffer.extend(data.split(splitter));
   |         ------        ^^^^ borrowed value does not live long enough
   |         |
   |         borrow later used here
33 |         process_data(&buffer);
34 |     }
   |     - `data` dropped here while still borrowed

Второй паттерн — самоссылающиеся структуры, известная больная тема в Rust.

Третий паттерн — множество определений разных версий и унифицированный код для работы с ними (из-за необходимости поддержки разных версий схем обмена данных, насколько я понял). Пример из статьи на C++:

struct RecV1 {
    uint32_t x;
    uint32_t y;
}

struct RecV2 {
    uint32_t x;
    uint32_t y;
    uint32_t z;
}

Унифицированный код для работы с обоими этими типами можно написать при помощи шаблонов:

template <typename T>
T InitRec() {
    T res;
    res.x = 1;
    res.y = 2;
    if constexpr(std::is_same_v<T, RecV2>()) {
        res.z = 3;
    }
    return res;
}

Нетрудно видеть, как это обобщается на случай большего количества полей и различных версий. В Rust можно попробовать сделать нечто подобное, но это вырождается в бойлерплейт, облегчать который приходится макросами — иными словами, попытка повторить шаблоны из C++.

Надо отметить, что первый пример с оптимизацией действительно не компилируется в лоб, но это не значит, что от аллокации в цикле нельзя избавиться. Именно, вот такой код с использованием bumpalo компилируется:

fn process_source(sources: Vec<Source>) {
    let b = bumpalo::Bump::new();
    for source in sources {
        let data = source.fetch_data();
        let mut buffer = bumpalo::collections::Vec::new_in(&b);
        buffer.extend(data.split(splitter);
        process_data(&buffer);
    }
}

В этом коде арена, которая в реализации и выделяет память, конструируется один раз за пределами цикла и позволяет переиспользовать память, но версия вектора из bumpalo создаётся заново на каждой итерации и потому может позволить себе иметь время жизни, сравнимое с временами жизни переменной итерации. Вызывать при этом явно .clear() за счёт RAII не требуется.

Папищек подсказывает, что в std Rust предлагают добавить метод для работы с подобными случаями, и, более того, предложение ссылается на ту же статью