Наталя Хандусенко Гаряченьке 12 листопада 2026, 11:00

Прискорення до 800 разів: український розробник створив ультрашвидку бібліотеку Corundum HFT для міжпроцесної взаємодії

Користувач Reddit під ніком SIIMUCH, а також Embedded Developer та Software Engineer, представив власний відкритий проєкт — бібліотеку Corundum HFT. Вона призначена для надшвидкої міжпроцесної взаємодії (IPC) у Linux і демонструє результати, що у сотні разів перевершують стандартні рішення ОС.

Залишити коментар

Додай у Google

Прискорення до 800 разів: український розробник створив ультрашвидку бібліотеку Corundum HFT для міжпроцесної взаємодії

Користувач Reddit під ніком SIIMUCH, а також Embedded Developer та Software Engineer, представив власний відкритий проєкт — бібліотеку Corundum HFT. Вона призначена для надшвидкої міжпроцесної взаємодії (IPC) у Linux і демонструє результати, що у сотні разів перевершують стандартні рішення ОС.

Навіщо знадобився новий інструмент

Розробник зіткнувся із завданням оптимізації передачі високочастотної телеметрії — наприклад, для надійного та швидкого зв’язку між фоновим демоном-монітором та графічним інтерфейсом (GUI).

Як зазначає автор у своєму дописі на Reddit, традиційні підходи на кшталт сокетів і звичайних каналів змушені постійно копіювати пам’ять через ядро операційної системи та виконувати велику кількість системних викликів. У сфері високих навантажень це створює відчутні затримки.

Як працює Corundum HFT

Архітектура бібліотеки повністю позбавлена цих недоліків завдяки низці технічних рішень.

Корінь системи базується на сегменті shm_open, який спільно відображають обидва процеси. Писар формує повідомлення (crd_reserve) прямо в спільній пам’яті, а читач (crd_read) використовує його на місці без жодних додаткових копіювань в обидва боки.

Використання бар'єрів пам’яті (memory_order_acquire / release) повністю виключає важкі мьютекси на гарячому шляху. Сторони узгоджуються через одне завантаження з acquire та один запис з release.

Гарячий шлях складається з кількох inline-функцій у заголовку. Бібліотека ніколи не викликає динамічне виділення пам’яті (навіть на етапі налаштування).

Для необов’язкового блокування (crd_wait) процес засинає на futex лише тоді, коли читач справді спить, тоді як crd_notify коштує лише один бар'єр пам’яті.

Продуктивність та можливості

Завдяки такій архітектурі затримка в одну сторону складає всього 25–75 наносекунд (для порівняння: у звичайних пайпів цей показник сягає ~22 мікросекунд, що робить нову розробку до 800 разів швидшою).

Технічні особливості та деталі реалізації:

одиниця буфера розрахована на схему «один писар — один читач»;
записи мають змінну довжину (до половини місткості буфера), вирівняні на 8 байтів і ніколи не перетинають кінець буфера (лежать єдиним суцільним блоком);
дозволяє готувати та публікувати (або читати й звільняти) кілька записів за один раз;
читач перевіряє заголовок кожного запису, захищаючи систему від помилкового чи зловмисного писаря. Слот непрацездатного писаря звільняється автоматично;
ядро написане на чистому C11, а для C++ розгорнуто зручну обгортку на C++17 із підтримкою RAII, побудовою об'єктів на місці (try_emplace<T>) та типізованим читанням без копіювання (msg.as<T>()).

Також у комплекті йдуть інструменти corundum-inspect (для перевірки заповненості буфера та підключених процесів) і corundum-bench (для порівняння продуктивності з pipe та Unix-сокетами).

Розробник зазначає, що проєкт повністю відкритий, має покриття тестами (CI для x86-64 та arm64) і супроводжується декількою документацією (включно з детальним обґрунтуванням порядку операцій у docs/DESIGN.uk.md).

Більше деталей та вихідний код проєкту доступні на GitHub.