#cplpl_doomed

В С++ есть фича, которая описана не совсем так, как описаны большинство фич С++(с помощью понятия "наблюдаемое поведение"), а с помощью описания трансформации AST. Речь идет про range-based for loop.

Вот преобразование AST: #abi

{
    auto && __range = range-expression ;
    auto __begin = begin_expr ;
    auto __end = end_expr ;
    for ( ; __begin != __end; ++__begin) {
        range-declaration = *__begin;
        loop-statement
    }
}

Это приводит к очень печальным проблемам, например, вот в таком случае:

for (auto& v : return_temporary().return_reference_to_temporary_subobject())

Коллеги из комитета по стандартизации сегодня рассказали, что С++ комитет отказался чинить эту фичу, потому что нет общего решения для С++, его надо придумать до C++26, но придумать никто не может.

Теперь и в твитторе: https://twitter.com/NicoJosuttis/status/1443267749854208000?s=19

С++ doomed. С этими старперами из IBM/Google/Microsoft, которые заинтересованы лишь в том, как бы ничего не сломать, у руля, C++ скоро превратится в Cobol.

Лично я об этом не жалею, для души буду писать на Rust, зато безбедная старость и образование для детей обеспечено.

Кстати, про M1.

Хороший текст про то, как в цикле заменять деление умножением(компиляторы давно это делают в compile-time, но в runtime, понятное дело, приходится руками). https://ridiculousfish.com/blog/posts/benchmarking-libdivide-m1-avx512.html

Цифры сравнения в рамках одной платформы интересны, но немного предсказуемы. А вот внимания заслуживает следующий факт:

"The M1 is 10x faster than the Xeon at 64 bit divides. It’s…just wow."

M1 - какое-то совершенно невероятное железо.

PS: текст про то, как заменить остаток от деления на умножение в хеш-таблицах: https://lemire.me/blog/2016/06/27/a-fast-alternative-to-the-modulo-reduction/

Серия статей про peg parser от Гвидо. https://medium.com/@gvanrossum_83706/peg-parsing-series-de5d41b2ed60

#fast_python

От "смотрите, какую клевую штуку я вчера прочитал в википедии", через "а вы знаете, я вдруг понял, что парсер в Питоне сосет"(а то это не было очевидно и до?), до "я переписал парсер Питона!".

Вообще, местами тошно смотреть, что делают былые крутаны со своими проектами. Тот же Гвидо со командой в течении ряда лет отвергал огромное число оптимизаций в интерпретатор Питона:

1) Потому что есть PyPy
2) Потому что jit сделает интерпретатор нечитаемым
3) Со скоростью и так все норм
4) Потому что нельзя менять API модулей

Чтобы не быть голословным, Гвидо on tail recursion:
http://neopythonic.blogspot.com/2009/04/tail-recursion-elimination.html

jit-компиляторы Питона можно найти в большом количестве, но до mainline CPython не дошло ничего.

И тут, ВНЕЗАПНО, после перехода в Microsoft, Гвидо решает заняться скоростью Питона, и обещает ускорить его в несколько раз. (https://github.com/faster-cpython/ideas, https://thenewstack.io/guido-van-rossums-ambitious-plans-for-improving-python-performance/) Конечно, сколько лет сам этому мешал, там непаханое поле, в несколько раз - это даже не начать приближаться к javascript(https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python.html)

И ускорит, будьте уверены. И напишет еще 10 клевых постов. А вот то, что это могло сделать 2 - 3 хорошо мотивированных студента, просто возможности не было, никто и не вспомнит.

https://www.opennet.ru/opennews/art.shtml?num=55897 #openssl

Никогда такого не было, и вот опять. Блеск и нищета open source. Вы смотрели на исходники openssl? Я смотрел, больше не хочу.

"Проблемы также затронули библиотеку LibreSSL, разработчики которой не учли прошлый опыт, связанный со сбоями, возникшими после устаревания корневого сертификата AddTrust удостоверяющего центра Sectigo (Comodo)."

"Суть ошибки в том, что старые версии OpenSSL и GnuTLS разбирали сертификат как линейную цепочку, в то время как в соответствии с RFC 4158 сертификат может представлять ориентированный распределённый циклический граф с несколькими якорями доверия, которые нужно учитывать."

PS: а вот все эти удостоверяющие центры действительно несут пользу для web(я не говорю про банковские транзакции)? Насколько сложно получить сертификат у того же Let's Encrypt?

PPS: в современно мире я бы использовал или libtomcrypt(low-level), или mbedtls, или wolfssl(там, кстати, работает разработчик curl, и она сильно совместима с openssl по API)

PPPS: про качество кода openssl от конкурента(автора libtom*): https://www.libtom.net/about/
"For some reason, folk like the GPG and OpenSSL folk assume that completely abhorrent and messy source code is ok, so long as it works."

Long read. #bootstrap

Я думаю, не секрет, что мне очень интересны системы сборки, в самом разнообразном виде. Настолько, что у меня есть:

1) Своя система сборки для С++ кода
* https://github.com/pg83/zm
* https://github.com/pg83/zm/blob/master/tp/libs/python/src/z.make

2) И своя система сборки OSS пакетов. Для Darwin и для Linux, для последнего это не только система пакетов, но и полноценный дистрибутив:
* https://github.com/pg83/mix
* https://github.com/pg83/mix/blob/main/pkgs/dev/lang/python3/package.sh (самый большой сборочный пакет, потому что собрать статически слинкованный Питон - совершенно нетривиальная задача)

Об этих проектах я еще буду рассказывать, особенно про второй. Сейчас я их привел для понимания того, что тема сборки, дистросроения, бутстрапа, мне очень интересны.

Сегодня я хочу поговорить про задачу бутстрапа.

Что это такое? Представьте себе, что вы попали на необитаемый остров, у вас есть пустой компьютер(без ОС), и компакт-диск с исходниками программ. Нужно из этого получить рабочую ОС, чтобы на необитаемом острове было не так скучно(стюардесса на необитаемый остров с нами не попала).

Эта задача имеет следующие аспекты:

1) Исторический. Как вообще проходил путь от компьютера с перфокартами до современных рабочих станций и планшетов?
2) Сугубо практический - как развернуть дистрибутив, имея максимально малый возможный бинарный seed. Вот очень интересное исследование, как проложить путь от минимального гипервизора в 200 инструкций до современного дистрибутива Linux - https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst
3) Безопасность. Воспроизводимая сборка с минимальным бинарным seed нужна, чтобы быть уверенным, что в софте нет закладок. Например, небезызвестная атака Томпсона: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf . Очень смешной вариант - https://www.quora.com/What-is-a-coders-worst-nightmare/answer/Mick-Stute?share=1 Да и просто понимать, что твоя сборка Alacritty собрана из исходников с github, и не содержит в себе трояна или какой другой жести, очень ценно.

Я стараюсь не держать у себя софта, для которого нельзя протянуть вот такую вот цепочку from ground truth.

В интернетах есть несколько community, которых эта задача тоже беспокоит:

1) https://bootstrappable.org/
2) https://guix.gnu.org/ (очень сильно упарываются по bootstrap)
3) https://nixos.org/ (в меньшей степени, не стесняются использовать бинарные сборки Rust, например)

Товарищи из Guix даже разработали пару специализированных языков для первоначального bootstrap(https://www.gnu.org/software/mes/, https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/) У guix, правда, есть другие свои заморочки, поэтому не могу его рекомендовать для повседневного использования. Nix в этом отношении интереснее, я его использовал как пакетный менеджер для любого Linux, Darwin, пока не завершил задачу bootstrap своего дистрибутива.

Что стоит еще рассказать про тему bootstrap:
* Далеко не все языки можно bootstrap. Это значит, что для некоторых языков нужен большой изначальный blob неизвестного качества. Я такие языки стараюсь не использовать(https://elephly.net/posts/2017-01-09-bootstrapping-haskell-part-1.html).
* Java бутстрапнули совсем недавно(https://bootstrappable.org/projects/jvm-languages.html). Систему сборки для нее(gradle) до сих пор не.
* Rust, с моей точки зрения, с натяжкой bootstrapable. Потому что: #mrustc
1) Для сборки n-ой версии нужна n-1 версия. Это очень сильно увеличивает длину цепочки bootstrap. Порядка 20 сборок на текущий момент?
2) Исходники первых версий на standard ml лежат неизвестно где. Bootstrap возможен только с сиспользованием стороннего продукта(https://github.com/thepowersgang/mrustc)
3) На Apple M1 цепочку пока повторить не получается
* У Go с bootstrap все хорошо, авторы поддерживают версию 1.4, последнюю на С. С ее помощью можно собрать современный Go. Так же существует gccgo.
* У Lisp все тоже очень хорошо. Скажем, цепочку от интерпретируемого ECL до компилируемого SBCL на Apple M1 я протянул за час.

Короче, по тексту про Гвидо я понял, что шок-контент нам интереснее... Ну ОК, вот вам Столлман ест какую-то хрень с ног:

https://www.youtube.com/watch?v=I25UeVXrEHQ

Когда я читаю что-то подобное https://habr.com/ru/post/579490/, меня охватывают два чувства: #abi #cplpl_doomed #cppcom

1) Презрение к тем, кто последние 15 лет занимается развитием С++, потому что их коллективный разум не смог родить ничего похожего на https://doc.rust-lang.org/book/ch19-06-macros.html. На минуточку, constexpr в С++ может посчитать какое-то значение в compile time, когда в нормальных языках можно породить любое AST, не только константу.

2) Чувство беспомощности, потому что я прекрасно осознаю, что не могу сделать ничего, чтобы предотвратить неминуемый закат С++.

Вы вот знаете, как происходит голосование в комитете по стандартизации С++? Насколько я знаю: голосование там идет от компаний, и от стран. От американских компаний, Яндекс там голосовать не может, например. Посчитайте, какой перевес в комитете имеют представительства условного MS + IBM + G + FB.

И что можно сделать, если эти люди решили, что им важнее ABI compatibility с кодом, который собрали еще под Borland C++ под DOS? Вопрос риторический.

Вместо того, чтобы регулярно ломать ABI(не вижу в этом проблем, всегда можно новые версии делать в новом namespace), и избавляться от груза накопленных ошибок, С++ тащит их за собой(just to name a few - locale, iostreams).

(про locale, ABI, и std::format можно почитать тут - https://thephd.dev/binary-banshees-digital-demons-abi-c-c++-help-me-god-please, начиная с "A Brief History of fmt")

Из-за боязни проблем с ABI почти весь современный код С++(и его стандартная библиотека) живет в header-only режиме. Это отдельная, очень больная, тема, потому что скорость разработки складывается из отдельных кирпичиков, и скорость компиляции кода один из них.

BTW, Rust очень правильно делает, что не спешит со стандартизацией. Развивать реализацию гораздо, гораздо проще, чем стандарт. Реализация развивается через pull request на gihub, а не письмами на деревню дедушке.

Короче, к чему это я? Я очень надеюсь, что какая-нибудь реализация С++(например, clang) пошлет стандарт(вместе с дедами, что его пишут) нахер, и начнет развивать С++ сама. А что, Apple(главный стейкхолдер clang) не боится ломать вещи, не боится ломать ABI и backward compatibility, они смогут, при желании. Проблема в том, что желания у них нет, С++ для них это побочный продукт жизнедеятельности clang(который для Apple является компилятором objective-c, в первую очередь, и базой для Swift, во вторую). На gcc и msvc надежды нет, это главные апологеты совместимости с залежалым говном мамонта.

И, BTW, насколько упрощает жизнь и ускоряет развитие жестко прошитая в язык статическая линковка...

Блин, вот даже у этого поделия https://terralang.org/ возможностей к метапрограммированию больше, чем во всем С++

Прекрасный пост про статическую линковку, from Hacker News. https://gavinhoward.com/2021/10/static-linking-considered-harmful-considered-harmful/

Список интересов автора поста, гм, впечатляет.

#gavin

И перепалка разработчиков #glib и musl(про статическую линковку), https://bugzilla.gnome.org/show_bug.cgi?id=768215#c16 . #GNOME

В какой-то момент времени мне показалось, что развитие компрессоров остановилось, и что нам остались только lz4 + zstd + lzma, но коллеги меня поправили. Оказывается, это совершенно не так. https://habr.com/ru/post/570694/

Очень жаль, что в свободном доступе нет большинства кодеков из статьи :(

Ну и хозяйке на заметку:

Обычно нас учат, что применять один компрессор после другого не имеет смысла. Это верно почти всегда. Но не всегда.

pg@:~/sources time cat ./qw.tar | xz -z -5 -c | wc -c
34261804

real    0m52,716s
user    0m52,411s
sys     0m0,327s

pg@:~/sources time lz4 -c -5 ./qw.tar - | xz -9 -c | wc -c
19972356

real    0m25,642s
user    0m25,704s
sys     0m0,691s

pg@:~/sources wc -c ./qw.tar
137738240 ./qw.tar

Мне ивестно несколько пар таких связок:
* lz4 - lz4
* lz4 - lz4hc
* lz4 - lzma/xz/lzip

Хорошего объяснения этому я не знаю. Объяснение, которое я случайно увидел на просторах интернетов, много лет тому назад, звучало примерно так - "у lz4 не хватает размера окна для сжатия, поэтому второй проход может эффективно за ним доесть", и "второй проход получает меньше данных, потому работает быстрее".

Кому отдавать credits за эту историю я тоже не знаю - потому что нигде больше не встречал такого хака. Конечно, это все очень специфично для конкретных данных. В примере я использовал tar от бинарной сборки glib(.a, exe, include/, src/).

Чот ржу

https://www.opennet.ru/opennews/art.shtml?num=55903

Только не могу понять, там наши побеждают, или не наши?

Как в Microsoft ловят data race в ядре(hint - c помощью профайлера бедного человека): https://www.usenix.org/legacy/events/osdi10/tech/full_papers/Erickson.pdf #debug

И, собственно, как сделать профайлер бедного человека своими руками: https://programmer.group/x86_-principle-and-example-of-single-step-debugging-for-64-platform.html

Я уже рассказывал, что я люблю странных людей. Все самое лучшее делают странные и упоротые люди.

Сегодня у нас в гостях Michael Forney(https://mforney.org/, не футболист!).

Человеку настолько надоел binary bloat, что он, в одну харю, запилил:

1) Статически слинкованный Oasis Linux. https://github.com/oasislinux/oasis К сожалению, тут мне с ним не по пути, потому что С++ он тоже считает bloat. https://git.sr.ht/~mcf/oasis

2) Переписал выполнитель графов Ninja на C. https://github.com/michaelforney/samurai Используется много где, я в своем дистрибутиве тоже использую как замену Ninja.

3) Переписал coreutils. Coreutils написаны на С, но на особом диалекте от GNU(это такой диалект, где все нужно делать в 10 раз длиннее по коду, чем нужно). Тут я его горячо поддерживаю, сам использую sbase в процессе бутстрапа свего дистрибутива. https://github.com/michaelforney/sbase

4) Вишенка на торте - пилит ажно 2 компилятора C.
* https://github.com/michaelforney/cproc - на базе https://c9x.me/compile/ - это такой очень lightweight аналог LLVM. Кстати, очень многообещающая вещь, когда оно сможет компилировать musl, я еего встрою в свой процесс бутстрапа. https://git.sr.ht/~mcf/cproc Список того, что в его дистрибутиве уже собирается с cproc - https://github.com/oasislinux/oasis/issues/13 (на самом деле, очень впечатляющий список!). Хочет собрать ядро Linux eventually, пожелаем ему успехов.
* Зачем-то учавствует в разработке scc - это еще один многообещающий компилятор С, товарищи пишут его с какой-то дикой скоростью, но заставить его работать у меня пока не вышло. https://git.simple-cc.org/scc/log.html

Какой мой интерес во всем этом? Я ищу простой компилятор для stage0 бутстрапа, чтобы в binary seed класть не 200мб clang, а 2 - 3мб cproc.

TinyCC, хоть и работает(у меня даже получилось собрать с его помощью патченый musl), внутри выглядит хуже, чем GCC. Но это как раз понятно, учитывая, как он начинался(Фабрис Беллард выиграл с его помощью контест на самый обфусцированный компилятор C https://bellard.org/tcc/)

https://twitter.com/alyssarzg/status/1443349503113846785

Еще раз повторю, Apple делает волшебное железо.

Для меня прямо очень удивительно видеть, что у clang больше красных квадратиков, чем у gcc. https://en.cppreference.com/w/cpp/compiler_support

Новый тектонический сдвиг?

Прекрасное от того же автора, что и текст про статическую линковку: #gavin

https://news.ycombinator.com/item?id=28737554
https://yzena.com/yzena-copyleft-license/ (пункт 16)

#copilot

Товарищ заодно еще и автор новой лицензии на OSS, основная фишка которой - запрет на использование исходных текстов под этой лицензией для обучения Copilot. Запасаемся попкорном, наблюдаем за тем, как подобного рода лицензии будут появляться на github. Подумываю тоже присоединиться к инициативе. Не то чтобы я зажал свои исходники для обучения несчастной машины, но интересно же, как GitHub(Microsoft) будет справляться с таким движением.

FSF тоже интересуется, не тырит ли ее бесценный GPL код Copilot: https://www.fsf.org/blogs/licensing/fsf-funded-call-for-white-papers-on-philosophical-and-legal-questions-around-copilot

https://lwn.net/Articles/871195/

Вообще, жить близко к транку - это хорошая идея. Но не в случае ядра.

Любое свежеизготовленное ядро - это, извините, кусок говна. Вы видели процессы разработки ядра линукс? Вы знаете, как оно тестируется?

Обычно разработчики ядра говорят, что тестировать ядро можно только наживую. Это, конечно, не так. Где, скажем, юниттесты на базовые контейнеры и примитивы синхронизации? Где фаззитесты на файловые системы? FS, вообще говоря, элементарно мокается посредством мока блочного устройства, и не менее элементарно фаззится. Где покоммитные тесты на стабильность ABI? Я знаю только про существование интеграционных тестов(когда ядро целиком запускается в чем-то типа qemu, но в живую их не видел).

Мое текущее понимание модели разработки ядра - что за FS отвечает мейнтейнер этой FS, который принимает в нее патчи, и мержит их в mainline. У кажого мейнтейнера свои подходы к тестированию, и они далеки от идеальных. Кто отвечает за то, что изменения в mmu не поломают какое-то изменение в FS, я не понимаю. Это явно не мейнтейнер MMU, и явно не мейнтейнер FS. По моему, Linus, то есть, никто.

Короче, обычно, ядро можно выпускать на некрасноглазых людей где-то через полгода - год после релиза. Пока оно не обкатается во всяких Arch Linux.

Поэтому что там собирается ловить Гугл, для "a near-mainline kernel for development and testing", я не очень понимаю. Ну, то есть, я совершенно понимаю задачу "сократить число патчей с 9000 до 2000", совершенно понятный ход "выкладывать смерженные ядра на 1000 хостов по мере готовности, а не раз в 2 года". Но вот как они будут отделять баги своих патчей от багов свежеиспеченного ядра - вопрос открытый. Хотя это, в любом случае, улучшит качество свежеиспеченных версий ядра, что хорошо для индустрии. По крайней мере, тестов Гугл на ядро наваяет.

https://blog.cloudflare.com/branch-predictor/

Хороший пост про branch predictor.

Long story short(с заметными упрощениями!):

// branch
if (x) {
    // not taken
} else {
    // taken
}

Branch Predictor = HashMap<Instruction Pointer, N="10011100">, где N - паттерн taken/not taken для последних прыжков по этому IP.

Размер этой таблицы - несколько тысяч элементов(зависит от архитектуры, и от того, что предсказываем(jmp/call))

Можно считать, что not taken branch не стоит почти ничего(кроме паталогических случаев, когда все плотненько забито jmp).

Если не играть с likely/unlikely, код лучше оформлять так(это напрямую не следует из статьи, так говорит опыт):

if (x) {
    // hot code

    if (y) {
        // hot code
    } else {
        // cold code
    }
} else {
    // cold code
}

Паттерн

if (error) {
    return error;
}

// hot code

не самый лучший, потому что бранч будет чаще taken.

Важно смотреть ассемблер, чтобы понимать, что компилятор правильно понял про ветки if, taken они, или нет.

В компиляторах есть атрибуты hot, cold, ими можно размечать код.

Одной строкой:

* до чего довел планету этот фигляр ПЖГвидо.

https://brmmm3.github.io/posts/2019/07/28/python_and_lua/
https://github.com/scoder/lupa

Люди делают offload cpu intensive нагрузки из Питона в Lua, потому что:
- lua параллелится
- lua имеет jit, и в разы быстрее per core.

В Lua, Карл! Даже не в С!

* На просторах интернетов нашел блог создателя musl. Мне зашли два поста:

http://ewontfix.com/18/. Читаем ассемблерные листинги, больше никогда не смотрим в сторону .so
http://ewontfix.com/17/. Legacy в Linux. В Linux треды это процессы, поэтому uid/gid там, на самом деле, пертредные. Рассказ про то, как сложно сделать атомарное изменение setuid для пачки тредов одного процесса(которые, на самом деле, тоже процессы).

* Красивое про musl и #glibc. Сам баг не очень интересен, а вот разница подходов к разработке очень даже.

https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html

* musl, на самом деле, тоже упыри с бесценным мнением. Уже много лет как очень настойчиво отказываются заводить макрос, который бы идентифицировал, что мы сейчас собираемся с musl. Из-за этого нам такой макрос приходится делать самим, и мы не можем апстримить некоторые изменения в некоторые OSS проекты.

https://wiki.musl-libc.org/faq.html

Ждем libc от LLVM! https://llvm.org/docs/Proposals/LLVMLibC.html

https://www.tiobe.com/tiobe-index/ - python-то ого-го! Правда, дельта примерно 0, прост остальные упали.