Hacker News Digest

Я написал What the Fork — кроссплатформенный визуализатор сборки C/C++ (и не только).
Запуск: wtf make, wtf cargo build, wtf gradle build, wtf -x для Xcode и т.д.

Инструмент показывает все процессы, включая скрытые вызовы ld, и ищет типичные проблемы:

• отсутствие -j у make,
• однопоточная компиляция,
• повторяющиеся cmake/make-шаги,
• непараллельные CI-сборки.

Как работает
Сборка = дерево команд. Чтобы увидеть всё, ловим системные вызовы fork/exec/exit:

• macOS — Endpoint Security API,
• Linux — ptrace,
• Windows — Event Tracing (самое мерзкое API).

Что уже нашли

• cargo собирал зависимость одним потоком вместо 10× ускорения.
• ninja при сборке LLVM держит 12 задач на 10 ядрах — почти идеал.
• CMake 85 раз подряд вызывает xcode-select, sw_vers, cmake/make → clang, не используя параллелизм.

Инструмент открыт для тестов — попробуйте на своём проекте.

• Пользователи восторженно реагируют на новый визуализатор сборки, особенно те, кто застрял на CMake/GCC/Make без clang/ninja и не может понять, почему сборка тормозит.
• Просят сразу показать GIF-демонстрацию под заголовком статьи и спрашивают, будет ли macOS-версия и открытый код.
• Некоторые делятся опытом: strace/dtruss, ninjatracing, vcperf, cargo --timings, Instruments и другие инструменты уже решали похожие задачи.
• Предложения расширить функциональность: добавить flame-графы процессов, поддержку fork(), интеграцию с Bazel Build Event Protocol, оценку «осталось времени» по историческим данным.
• Отдельные комментарии касаются маркетинга (сменить название), сравнения с VS/Xcode, а также шуток про TEEP/OEE завода и «LLVM, завари кофе».

SIMD-поиск подстроки в Zig

Автор реализовал алгоритм, который на 60 % быстрее std.mem.indexOf.
Идея: сравниваем 32-байтовые блоки текста с первым и последним символом искомого слова, используя AVX2.

1. Берём первый и последний байт needle (first, last).
2. Загружаем 32 байта haystack в вектор Block = @Vector(32, u8).
3. Создаём маски совпадений:

   const eq_first = first == block;
   const eq_last  = last  == block_shifted;
   const mask = @bitCast(eq_first & eq_last);
   

4. Для каждого установленного бита проверяем полное совпадение подстроки.
5. Хвост обрабатываем обычным indexOf.

Код (сокращённо):

const Block = @Vector(32, u8);
const first = @splat(needle[0]);
const last  = @splat(needle[k-1]);

while (i + k + 32 <= n) : (i += 32) {
    const f = haystack[i..][0..32].*;
    const l = haystack[i+k-1..][0..32].*;
    var mask: u32 = @bitCast((first == f) & (last == l));
    while (mask != 0) {
        const bit = @ctz(mask);
        if (mem.eql(u8, haystack[i+bit+1..][0..k-1], needle[1..]))
            return i + bit;
        mask &= mask - 1;
    }
}
return mem.indexOf(u8, haystack[i..], needle) orelse null;

Тест: поиск слова «newsletter» во всём «Моби Дике» (~1.2 МБ).
Сборка: zig build -Doptimize=ReleaseFast.

• Подход с SIMD-ускорением поиска подстроки популярен, но в худшем случае остаётся квадратичным O(m·n), поэтому нужен «откат» на линейный алгоритм (KMP/BM).
• Участники отмечают, что большинство реализаций опираются на 10-летние AVX/NEON, игнорируя AVX-512, SVE и RVV, которые дают больший выигрыш, но пока редки на десктопах и в облаках.
• Zig пока не предоставляет прямых intrinsics, хотя LLVM-бекенд позволяет вызывать нужные инструкции; это тормозит портирование низкоуровневых оптимизаций.
• Есть идея дальнейшего SIMD-фильтра: проверять не только первый/последний байт иглы, но и второй/предпоследний и т.д., накладывая маски.
• Вопросы Unicode: алгоритм работает на байтах, поэтому для UTF-8/16 потребуется дополнительная обработка переменной длины кодов.

A really good accompaniment to this is Carruth's "C++, bounds checking, performance, and compilers" [1]:> ... strong belief that bounds checks couldn’t realistically be made cheap enough to enable by default. However, so far they are looking very affordable. From the above post,