🦀 Rust против C в embedded - не на словах, а в реальном тесте.
Исследователи взяли промышленное IoT-железо и запустили на нём две реализации одной и той же функциональности.
Одна команда писала на C.
Другая - на Rust.
Системы работали параллельно несколько месяцев в реальных условиях, а не в синтетическом бенчмарке.
Итог оказался неприятным для старого аргумента «для embedded нужен только C».
Rust не проиграл C ни по памяти, ни по скорости выполнения. Более того, runtime на Ariel OS оказался даже компактнее, чем классический bare-metal стек на C.
Вывод простой: аргумент «C быстрее и легче для прошивок» теперь звучит гораздо слабее.
Rust в embedded - это вполне рабочая альтернатива.
🔗 Подоробности: https://arxiv.org/abs/2604.25679
#Rust #RustLang #EmbeddedSystems #IoT #SystemsProgramming #C
Исследователи взяли промышленное IoT-железо и запустили на нём две реализации одной и той же функциональности.
Одна команда писала на C.
Другая - на Rust.
Системы работали параллельно несколько месяцев в реальных условиях, а не в синтетическом бенчмарке.
Итог оказался неприятным для старого аргумента «для embedded нужен только C».
Rust не проиграл C ни по памяти, ни по скорости выполнения. Более того, runtime на Ariel OS оказался даже компактнее, чем классический bare-metal стек на C.
Вывод простой: аргумент «C быстрее и легче для прошивок» теперь звучит гораздо слабее.
Rust в embedded - это вполне рабочая альтернатива.
🔗 Подоробности: https://arxiv.org/abs/2604.25679
#Rust #RustLang #EmbeddedSystems #IoT #SystemsProgramming #C
Обычно есть два подхода.
Первый - собрать всё дерево документа целиком. Так делают Wadler-style pretty printers. Это выразительно, но в Rust быстро упирается в память, аллокации и указатели.
Второй - стримить вывод по кускам. Так работает Oppen-style подход. Он легче по памяти, но часто принимает локально хорошие решения и не всегда находит глобально лучший layout.
Автор предлагает третий вариант: не хранить документ как рекурсивный enum, а описывать его через trait
Doc.То есть
Text, Concat, Group, Nest и другие элементы становятся отдельными типами, которые умеют сами себя рендерить через layout().Звучит как мелкая архитектурная правка, но эффект большой: меньше лишних аллокаций, меньше прыжков по памяти, гибче управление
Box, Rc и другими стратегиями хранения.В proof-of-concept реализации pye автор получил до 60x ускорения по сравнению с прямой Rust-реализацией алгоритма из paper “A Pretty Expressive Printer”. А в обновлённых тестах вариант с таким дизайном и greedy-алгоритмом местами обгонял
pretty и arena-версию больше чем в 10 раз.В Rust производительность часто ломается не только на алгоритме, но и на форме данных.
Иногда enum выглядит красиво, но trait-based дизайн лучше ложится на память, ownership и реальные оптимизации компилятора.
blog.wybxc.cc/blog/pretty-printer-pye/
#Rust #RustLang #Compilers #OpenSource #SystemsProgramming
Please open Telegram to view this post
VIEW IN TELEGRAM
Исследователи NVIDIA перенесли модель владения Rust в GPU-kernels.
Paper: “Fearless Concurrency on the GPU”. В нём представлен cuTile Rust.
Проблема была в том, что при написании кастомных GPU-ядер на Rust разработчикам фактически приходилось выходить за пределы гарантий безопасности Rust.
cuTile Rust пытается это исправить:
* mutable outputs разбиваются на непересекающиеся части
* запуск kernels сохраняет правила ownership от host до device
* при необходимости остаются локальные opt-out механизмы для низкоуровневого контроля
Производительность тоже держится на уровне:
* 7 TB/s для element-wise операций на NVIDIA B200
* 2 PFlop/s для GEMM, это 96% от cuBLAS
* результат сопоставим с cuTile Python в пределах погрешности измерений
Авторы также собрали Grout, inference engine поверх cuTile Rust, и прогнали реальные модели:
* 171 tokens/s для Qwen3-4B на RTX 5090
* 82 tokens/s для Qwen3-32B на B200
* конкурентный уровень рядом с vLLM и SGLang
Итог - безопасный и идиоматичный Rust почти на полной CUDA-производительности.
Для Rust в ML-инфраструктуре это большой шаг.
https://arxiv.org/abs/2606.15991
#Rust #RustLang #GPU #CUDA #MachineLearning #SystemsProgramming #NVIDIA
@data_analysis_ml
Paper: “Fearless Concurrency on the GPU”. В нём представлен cuTile Rust.
Проблема была в том, что при написании кастомных GPU-ядер на Rust разработчикам фактически приходилось выходить за пределы гарантий безопасности Rust.
cuTile Rust пытается это исправить:
* mutable outputs разбиваются на непересекающиеся части
* запуск kernels сохраняет правила ownership от host до device
* при необходимости остаются локальные opt-out механизмы для низкоуровневого контроля
Производительность тоже держится на уровне:
* 7 TB/s для element-wise операций на NVIDIA B200
* 2 PFlop/s для GEMM, это 96% от cuBLAS
* результат сопоставим с cuTile Python в пределах погрешности измерений
Авторы также собрали Grout, inference engine поверх cuTile Rust, и прогнали реальные модели:
* 171 tokens/s для Qwen3-4B на RTX 5090
* 82 tokens/s для Qwen3-32B на B200
* конкурентный уровень рядом с vLLM и SGLang
Итог - безопасный и идиоматичный Rust почти на полной CUDA-производительности.
Для Rust в ML-инфраструктуре это большой шаг.
https://arxiv.org/abs/2606.15991
#Rust #RustLang #GPU #CUDA #MachineLearning #SystemsProgramming #NVIDIA
@data_analysis_ml
⚡️ Один `static` - три разных смысла. Добро пожаловать в C.
В C ключевое слово
### 1.
Переменная имеет internal linkage - она доступна только внутри текущего
Это удобный способ спрятать детали реализации модуля.
### 2.
Он существует всё время работы программы и сохраняет значение между вызовами функции.
### 3.
Функция становится видна только внутри текущего translation unit.
Другой
Итого:
🔥 Поэтому
lifetime и linkage.
#C #Programming #SystemsProgramming #LowLevel #Cpp
В C ключевое слово
static меняет поведение в зависимости от того, где именно оно написано.### 1.
static у глобальной переменной
static int global;
Переменная имеет internal linkage - она доступна только внутри текущего
.c файла.Это удобный способ спрятать детали реализации модуля.
### 2.
static внутри функции
void foo(void) {
static int count;
count++;
}
count не создаётся заново при каждом вызове.Он существует всё время работы программы и сохраняет значение между вызовами функции.
foo(); // count = 1
foo(); // count = 2
foo(); // count = 3
### 3.
static у функции
static void bar(void) {
}
Функция становится видна только внутри текущего translation unit.
Другой
.c файл вызвать bar() напрямую уже не сможет.Итого:
static global variable -> скрыть символ внутри файла
static local variable -> сохранить состояние между вызовами
static function -> скрыть функцию внутри файла
🔥 Поэтому
static в C полезнее воспринимать не как одно конкретное поведение, а как подсказку проверить две вещи:lifetime и linkage.
#C #Programming #SystemsProgramming #LowLevel #Cpp
⚡ В SQLite есть кусок кода, который выглядит «грязно», но оставлен таким специально ради скорости.
Каждый SQL-запрос SQLite сначала компилируется в байткод, а затем выполняется собственной виртуальной машиной VDBE.
Внутри — большой цикл диспетчеризации с почти 200 opcode.
И вот интересный момент: SQLite использует обычные
В исходниках прямо написано:
«Код использует неструктурированные goto и выглядит не очень чисто. Но это сделано не из-за плохого стиля, так быстрее».
По замерам разработчиков, такой подход ускоряет
То есть здесь читаемость сознательно пожертвовали ради производительности.
Хорошее напоминание: в системном коде «красивее» не всегда значит «быстрее».
#SQLite #C #Databases #Performance #SystemsProgramming
Каждый SQL-запрос SQLite сначала компилируется в байткод, а затем выполняется собственной виртуальной машиной VDBE.
Внутри — большой цикл диспетчеризации с почти 200 opcode.
И вот интересный момент: SQLite использует обычные
goto, чтобы быстро прыгать между общими ветками выполнения.В исходниках прямо написано:
«Код использует неструктурированные goto и выглядит не очень чисто. Но это сделано не из-за плохого стиля, так быстрее».
По замерам разработчиков, такой подход ускоряет
sqlite3_step() примерно на 1,5%.То есть здесь читаемость сознательно пожертвовали ради производительности.
Хорошее напоминание: в системном коде «красивее» не всегда значит «быстрее».
#SQLite #C #Databases #Performance #SystemsProgramming