C++ Academy
По всем вопросам- @workakkk РКН: clck.ru/3FmxJF #VRHSZ
Mostrar más📈 Análisis del canal de Telegram C++ Academy
El canal C++ Academy (@cpluspluc) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 15 522 suscriptores, ocupando la posición 8 268 en la categoría Tecnologías y Aplicaciones y el puesto 42 183 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 15 522 suscriptores.
Según los últimos datos del 25 octubre, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de 14, y en las últimas 24 horas de -4, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 16.26%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 6.85% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 2 524 visualizaciones. En el primer día suele acumular 1 063 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 27.
- Intereses temáticos: El contenido se centra en temas clave como c++, github, linux, api, архитектура.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“По всем вопросам- @workakkk
РКН: clck.ru/3FmxJF
#VRHSZ”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 26 octubre, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.
uint32_t ring_index(uint32_t i, uint32_t n)
pre(n && (n & (n - 1)) == 0)
{
return i % n;
}
Для таких беззнаковых чисел i % n можно заменить на более дешёвое i & (n - 1). Однако в примере автора GCC 16 не выполняет эту оптимизацию автоматически.
Поддержка контрактов включается через -fcontracts. В режиме enforce нарушение вызывает обработчик и завершение программы. Поведение зависит от выбранного режима проверки. Документация GCC -https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html .
Атрибут C++23 [[assume(условие)]] даёт оптимизатору дополнительную информацию, но не проверяет условие. Если оно ложно, поведение программы не определено.Цель проекта – локальный запуск языковых моделей на потребительских видеокартах.Всё упаковано в одну библиотеку
libsonicboom.so, которую можно подключить из любого языка через стандартный интерфейс C, основным языком для работы с ней авторы выбрали Scheme в реализации GNU Guile.
SonicBoom загружает модели в GGUF, генерирует текст на процессоре или видеокарте и поднимает локальный сервер, совместимый с API OpenAI.
Если новый запрос начинается с того же текста, что и предыдущий, заново обрабатывается только добавленная часть, и результат до токена совпадает с полным пересчётом.
🟡Механика
Скорость вывода дают уровни над вычислительными ядрами, а не сами ядра. Умножение квантованных матриц и токенизаторы частично перенесены из llama.cpp.
Над ними работает планировщик, который до запуска переписывает граф модели целиком, сливает соседние операции и записывает весь шаг генерации токена в один CUDA Graph, т. е. в готовую последовательность команд для видеокарты.
Ещё выше стоит компилятор на базе MLIR. Он сам генерирует часть ядер для GPU, в том числе для механизма внимания, и при первом запуске подбирает самый быстрый вариант под конкретную карту.
🟡Тесты
На RTX 3050 с 8 ГБ памяти сравнили SonicBoom и llama.cpp на одних и тех же моделях.
Gemma 4 E4B через SonicBoom дала генерацию в 53 токена в секунду против 44,8 у llama.cpp.
У Qwen2.5-0.5B вышло 344,7 токена в секунду против 307,6.
Когда контекст дорастает до 512 токенов, SonicBoom на Qwen уже чуть отстаёт.
Единственный сторонний результат на RTX 4060 Ti оказался хуже llama.cpp, 73,6 токена в секунду против 78, но его получили на сборке, ещё не настроенной под эту видеокарту.
Пока проверены только две модели, Gemma 4 E4B-it и Qwen2.5-0.5B-Instruct, и только видеокарты серии RTX 30.Модель всегда выбирает самый вероятный токен, температуру и другие настройки случайности задать нельзя. Следующими в планах стоят модели Llama и Mistral, работа через Vulkan, генерация ядер для видеокарт других производителей и диффузионные модели. Дальше SonicBoom планирует вырасти в фреймворк в духе PyTorch, где модель пишут на Scheme и компилируют в граф вычислений. Прототип этого режима уже обучает небольшой трансформер. 📌Лицензирование: GPL-3.0 🖥Github @ai_machinelearning_big_data #AI #ML #LLM #InferenceEngine #SonicBoom
deltaDist = abs(1 / rayDir)
После попадания в стену используется не обычная длина луча, а перпендикулярное расстояние до стены — это убирает характерное fish-eye искажение.
Дальше всё почти классически:
* рассчитывается высота стены на экране;
* выбирается текстура;
* вычисляется точка попадания;
* рисуется вертикальная полоса пикселей.
Минимум кода и уже получается полноценная псевдо-3D графика в стиле первых Wolfenstein/Doom-подобных движков.
Отличный проект, чтобы реально понять raycasting, DDA и основы старой 3D-графики.deltaDist = abs(1 / rayDir)
После попадания в стену используется не обычная длина луча, а перпендикулярное расстояние до стены — это убирает характерное fish-eye искажение.
Дальше всё почти классически:
* рассчитывается высота стены на экране;
* выбирается текстура;
* вычисляется точка попадания;
* рисуется вертикальная полоса пикселей.
Минимум кода и уже получается полноценная псевдо-3D графика в стиле первых Wolfenstein/Doom-подобных движков.
Отличный проект, чтобы реально понять raycasting, DDA и основы старой 3D-графики.integer → string делают циклом:
/ 10 → берём цифру
% 10 → остаток
и повторяем снова.
SQLite идёт хитрее.
В исходниках есть строка на 200 символов, содержащая все пары от 00 до 99:
000102030405...979899
При преобразовании числа SQLite обрабатывает его по две цифры за раз и просто берёт нужную пару символов по индексу.
То есть вместо множества операций /10 и %10:
делим на 100 → получаем две цифры → копируем готовую пару.
Маленькая оптимизация, но именно из таких деталей и состоит быстрый системный код.
Исходник: sqlite/src/util.c
const Sofa mySofa;
Sofa newApartment = std::move(mySofa);
Кажется, диван должен «переехать». Но вызывается конструктор копирования 🤡
Подвох: `std::move` не перемещает объект и не снимает `const`. Здесь он даёт const Sofa&&, а конструктору перемещения Sofa(Sofa&&) нужна ссылка без const.
Зато конструктор копирования Sofa(const Sofa&) подходит.
Даже компилятор знает: переезд без неожиданных расходов не бывает.xorshift32 достаточно буквально трёх операций:
state ^= state << 13;
state ^= state >> 17;
state ^= state << 5;
Новое значение state становится следующим псевдослучайным числом.
Почему это интересно:
- почти нет вычислительных затрат;
- используются только битовые сдвиги и XOR;
- период для ненулевого state — до 2³² − 1;
- отлично подходит для игр, симуляций и других задач, где важна скорость.
Но есть важный нюанс: Xorshift не криптографически стойкий. Для токенов, паролей и security-задач его использовать нельзя.
Красивый пример того, как всего несколько битовых операций превращаются в полноценный генератор псевдослучайных чисел.std::weak_ptr может удерживать память даже при expired() == true.
Причина в std::make_shared: обычно он размещает объект и управляющий блок в одной аллокации.
В примере на скриншоте массив на 16 МиБ находится прямо внутри Blob. После удаления последнего shared_ptr:
* деструктор объекта вызывается;
* expired() возвращает true;
* общий блок памяти остаётся выделенным, пока существует хотя бы один weak_ptr.
После сброса последней слабой ссылки блок можно освободить.
Что делать: удалять протухшие ссылки из долгоживущих кешей. Для крупных объектов также можно рассмотреть отдельную аллокацию через std::shared_ptr<Blob>(new Blob()).
Нюанс касается размера самого объекта. Если данные хранятся в обычном std::vector, его отдельный буфер освобождается при вызове деструктора.
[Разбор от Microsoft](https://devblogs.microsoft.com/oldnewthing/20230815-00/?p=108602)
void inspect(char data[3]) {
printf("%zu\n", sizeof(data));
}
Но параметр здесь становится указателем. На платформе с 64-битными указателями увидите 8, а не 3. Длина массива в функцию не передаётся.
Ещё несколько сюрпризов:
• C-строки заканчиваются \0, а strlen() ищет этот байт, проходя по памяти.
• long обычно занимает 64 бита в 64-битных Unix-системах и 32 бита в Windows.
• malloc() может вернуть NULL, а язык не заставит проверить результат.
• Вместо ссылок с проверкой заимствований работают сырые указатели.
Полезное чтение для тех, кто пишет FFI или хочет понять, какие гарантии привычно получает от Rust.
https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/
@rust_codeutf8d выполняет две задачи:
* определяет класс очередного байта;
* выбирает следующее состояние автомата.
`ACCEPT` означает, что кодовая точка полностью прочитана. `REJECT` - обнаружена ошибка. Остальные состояния означают, что нужны дополнительные байты.
Подход удобен для потоковой обработки: если символ разорван между двумя сетевыми пакетами, достаточно сохранить состояние и накопленное значение.
Нюанс: после последнего байта тоже нужно проверить состояние. Если оно не ACCEPT, строка некорректна - например, оборвалась посреди символа.
i = 0x5f3759df - (i >> 1); // what the fuck?
Комментарий настоящий. Эта строка помогает вычислить 1/√x, не извлекая квадратный корень. В графике такая операция нужна для нормализации векторов: привести их длину к единице, сохранив направление.
Как работает трюк?
У float внутри есть показатель степени и дробная часть. Если прочитать биты положительного нормализованного числа как целое, получится величина, которая примерно соответствует его логарифму с масштабом и смещением.
А дальше используется свойство:
log₂(1/√x) = −½ × log₂(x)
Сдвиг >> 1 делит целое число на два. Вычитание из подобранной константы меняет знак и компенсирует смещение. Полученные биты снова читаются как float: это уже приближение к ответу.
Один шаг метода Ньютона доводит относительную погрешность примерно до 0,18%. В историческом тесте Криса Ломонта функция работала примерно в четыре раза быстрее прямого вычисления 1.0 / sqrt(x).
А закомментированная строка на картинке? Это второй шаг Ньютона: ещё больше точности за дополнительные вычисления.
💡 Красота алгоритма в том, что само представление числа в памяти становится частью вычисления.
https://github.com/id-Software/Quake-III-Arena/blob/master/code/game/q_math.c