GLM-5.1 придумал для меня новый алгоритм

Перепроверил, полностью используемый вариант на AVX-2 для вычисления сумм выглядит вот так

    __m256i ps = _mm256_shuffle_epi8(vdelta, nibbles);
    ps = _mm256_add_epi8(ps, _mm256_slli_si256(ps, 1));
    ps = _mm256_add_epi8(ps, _mm256_slli_si256(ps, 2));
    ps = _mm256_add_epi8(ps, _mm256_slli_si256(ps, 4));
    ps = _mm256_add_epi8(ps, _mm256_slli_si256(ps, 8));

    __m128i ps_lo = _mm256_castsi256_si128(ps);
    __m128i ps_hi = _mm256_extracti128_si256(ps, 1);
    __m128i carry = _mm_set1_epi8((int8_t)_mm_extract_epi8(ps_lo, 15));
    ps_hi = _mm_add_epi8(ps_hi, carry);
    ps = _mm256_inserti128_si256(_mm256_castsi128_si256(ps_lo), ps_hi, 1);

Тут мой косяк как автора, а не AI, дополню статью. По поводу pdep AI при анализе всю ту же информацию про Zen 2 выдал и предлагал фолбэк на несколько умножений. Здесь есть еще один нюанс касающийся и 128-битных регистров: excess принимает значения [-128; 128] и не влезает в байт, поэтому надо что-то с этим делать, но и тут как-будто всё аккуратно сведено

GLM-5.1 придумал для меня новый алгоритм

Прошу прощения за неточность, Исходный вариант где использовался pdep, работал с SSE, не AVX. Соответственно проблемы с переносом по 128битым лейнам там не было

GLM-5.1 придумал для меня новый алгоритм

Она не переносит биты/байты через границу 128 бит. Это значит, что на 16-м байте (начало старшего лейна) префиксная сумма начнется заново с нуля, полностью проигнорировав накопленный excess из младшей половины регистра.

Я перепиоверю, но вроде как с этим проблемы не было, разве что в варианте с AVX-512.

ИИ здесь не изобрёл ничего нового (это классический Broadword Computing / Parallel LUT, который лет 10 используется в биоинформатике и парсерах вроде simdjson)

Иллюзия новизны комбинации vpshufb как параллельного LUT для 4-битных нибблов, это стандартный паттерн (так работает, например, подсчет popcount по алгоритму Мулы или валидация строк).

С этим я и не спорю, это прям даже в промпт было “применить именно этот метод, потому что он универсальный”

ИИ просто взял готовый паттерн из одной области (парсинг/сжатие) и перенёс в задачу RMQ/LCA

Когда вы комбинируете уже известные алгоритмы неизвестным до этого способом, разве вы не получаете новый алгоритм? Тогда болтшинство научных статей не содержат новизны

Код требует полной переработки межлейнового обмена и избавления от скалярного pdep в пользу чистого SIMD-маскирования.

Исходный вариант применялся к блокам по 64 бита и указанной проблемы быть не должно. Впоследствии пдеп я убрал и писал об этом в статье

Вариация на тему Рида-Соломона

Насколько я понимаю, основной подход к реализации этого умножения оснван на использовании табличного метода — либо простая таблица всех попарных умножений, либо совместное использование таблицы логарифма/степени базового элемента. К сожалению, табличные методы не векторизуются на esp32-s3

Эти таблицы не векторищуются нигде, но специально под симд есть табличный аналог fma https://www.ssrc.us/media/pubs/c9a735170a7e1aa648b261ec6ad615e34af566db.pdf

Можно глянуть реализацию вот тут https://github.com/catid/gf256

А у вас на принимающей стороне известно какие данные испортились? Если да, то берите вот эту реализацию: лучше в открытом доступе не найдёте, а чтобв сделать быстрее придётся много математики разобрать https://github.com/catid/leopard

«Я ща его ударю». Полтора года собирала жалобы на нейросети от нытиков и классифицировала

Ну или ставите правило отвечать ёбко и не растекаться.

Сформулировано хорошо, в целом в духе caveman

Я удалил backpropagation из нейросети. Она обучилась методами XIX века

Плюс в карму за то, что написали про Поляка. В общем то большая часть рассуждений в статье как раз сводится к его идеям и, собственно, методу тяжёлого шарика откуда термин “momentum” и возник в контексте градиентного спуска.

Я бы отдельно отметил, что у Поляка (да и в последующем в теории оптимизации) инерция возникает совершенно не как средство выхода из локального минимума. Наоборот инерция ускоряет сходимость для плохо обусловленных функций и работает в основном для локального анализа. Упрощенный анализ можно есть тут. Про то, что момент помогает бороться с локальными минимумами – это миф, по крайней мере никакого математического обоснования этого я никогда не видел (именно математическое обоснование, а не размахивание руками с картинками). Если знаете где такое есть – с удовольствием почитаю!

Поиск по коду: почему просто проиндексировать все коммиты — плохая идея

Я сейчас веду проект по succinct структурам, у меня есть студенты, которым нужна практика, но нет реальных бизнес задач, под которое это можно было бы подвязать. У меня ощущение, что для поисковых задач может быть пересечение, не хотели бы обсудить?

Semantic terminal: AI-генератор однострочников по описанию на естественном языке

Каждый вызов – это новая сессия, в которой только системный промт + текущий запрос. В этом и был смысл, что больше ничего нет. Если хочется, чтобы учитывался контекст сессии – cursor, roo code, opencode, claude code итп

Semantic terminal: AI-генератор однострочников по описанию на естественном языке

Ничего не делаю – мне такого ответа ни разу не было. Дизайн утилиты предполагает, что вы сначала генерируете команду, смотрите на неё, а потом выполняете. Есть возможность это пропустить, но для этого нужно целенаправленно указать флаг и тут уже сами виноваты.

Отдельно отмечу промт

Semantic terminal: AI-генератор однострочников по описанию на естественном языке

Закиньте в issues!

Поиск по коду: почему просто проиндексировать все коммиты — плохая идея

Подскажите, я так и не понял, а что у вас за базовый индекс то? Если вы ищете строки, разве там не должно быть чего-то в духе суффиксного дерева?

Аудит сайта, который навайбкодил CEO Y Combinator

C недавних пор сам тоже так делаю. Технически часть с копированием иллюстраций можно пропустить.

GDB для тех, кто думает, что отладка — это фантастика

Это верно, но статья была про то как использовать gdb из консоли, а не в qtcreator.

GDB для тех, кто думает, что отладка — это фантастика

Это понятно, вот только я готов использовать gdb с интерфейсом в vscode, но не готов использовать чистый gdb из терминала, вопрос в этом

GDB для тех, кто думает, что отладка — это фантастика

Хорошая и полезная статья.

А вы пользуетесь отладчиклм из терминала? Есть ли какие-то преимущества над плагиами в ide, для меня вот интерфейс терминала для отладки почти бесполезен и не ускоряет посравнению “отладкой принтами”

Введение в высокопроизводительные вычисления на С++ для CPU

Да, это "тернарный оператор", в С/С++ он отоже есть. Честно говоря не знаю есть ли в нем большой смысл с современными компиляторами, как синтаксический сахар точно полезен.

Введение в высокопроизводительные вычисления на С++ для CPU

Чтож вы мучаетесь то
https://godbolt.org/z/177jcYKc4

P. S. Для личного опыта интересно потыкаться, но для прода я бы не выпендривался и использовал std::copy или std::ranges::copy

Введение в высокопроизводительные вычисления на С++ для CPU

Разница в первую очередь в наборах инструкций, AMD64 и x86-64 в этом плане примерно одно и тоже, но у AMD поддержка новых расширений частенько с запозданием. ARM и RISC-V -- это семейство RISC, у ARM свои SIMD (ссылка есть в статье), с RISC-V совсем не работал, поэтому гадать не буду -- лучше поищите сами.

Референсные значения по таймингам доступа к кэшам/регистрам схожи, но если вы оптимизируете под конкретное устройство, то нужно смотреть референс этого конкретного устройства.

Введение в высокопроизводительные вычисления на С++ для CPU

Вроде как раз для таких случаев godbolt.org полезен чтобы посмотреть что будет с -O2/-O3

Введение в высокопроизводительные вычисления на С++ для CPU

Я думал, что имелось в виду

for (int i = 0; i < N; ++i) {
  *(dst + i) = *(src + i);
}

и

while (src < end) {
  *dst++ = *src++;
}