Интересная статья про оптимизации и про потенциальное развитие C++. Начинается с довольно меткого указания на отличия между программированием раньше и сейчас: раньше программы в основном покупались 1 раз и использовали ресурсы компьютера пользователя, поэтому важно было выпускать ПО без багов (потому что тяжело исправить) и с кучей фич (чтобы продать); сейчас же почти все крутится в облаке и компания платит за ресурсы (а новый релиз выпустить относительно просто). Соответственно, многие новые “убийцы” плюсов все еще пытаются решить старую проблему с безбажностью, вместо того, чтобы выжимать максимум производительности.

Но и с оптимизациями не все так просто: многое будет зависеть от конкретного чипа, поэтому одни и те же микрооптимизации могут давать рандомный выхлоп как в сторону улучшения, так и ухудшения. У автора, кстати, есть несколько викторин на эту тему.

Рассматриваются три интересных подхода: SPIRAL (хитрые эвристики), Numba (более высокоуровневый подход), ForwardCom (простейший набор команд + радикальные идеи об общем низкоуровневном наборе команд для всех CPU).

“Как-нибудь” продукт и шелл-скрипт соберет. А вот если надо “чтобы само” да еще и быстро — то тут начинается веселье:

1. Надо скачать зависимости, разрешить конфликты (а это может быть большой граф), подключить их правильно (банально — фреймворк для тестов не должен протекать в продакшн-код) и т.п.
2. Сборка должна быть быстрой, поэтому не надо каждый раз все собирать с нуля, а по максимуму переиспользовать предыдущие результаты — это инкрементальная компиляция (возможно со всякой черной магией, чтобы понять, были ли изменения бинарно совместимыми или нет) и/или корректный вызов компилятора, который, знаете ли, тоже тот еще комбайн. Это не очень тривиальная задача. А еще нужен кэш сборки (возможно удаленный).
3. Как следствие, процесс сборки (а так же его части, та же компиляция) делится на мелкие кусочки (чем мельче куски, тем больше потенциально закэшируется), которые зависят друг от друга — получается граф выполнения задач. Причем там могут быть циклы (у какого-нибудь линковщика, например) — со всеми вытекающими приколами.
4. Чтобы было еще быстрее, можно же параллельно выполнять независимые задачи.
5. Кэшировать можно не только результаты сборки, но инструкции для нее. И тоже гранулярно.
6. На мелкие кусочки можно делить не только процесс сборки, но и сами исходники — зачем вам каждый раз перекомпилировать форк библиотеки со своим фиксом, когда можно его изолировать от остального кода?
7. Если вы разработчик библиотеки, то надо еще тестировать под миллион окружений, и не всем охота это делать в CI.
8. А еще код на качество стоило бы как-нибудь проверить, желательно сразу при сборке.
9. Если у вас завелся пользователь Windows, то уже просто shell-скрипт не напишешь, нужно что-то кроссплатформенное для всякой фигни типа копирования файлов или выполнения HTTP-запроса.
10. Получается, что теперь нужна еще возможно писать какую-то кастомную логику и/или давать возможность расширять функциональность плагинами.
11. Даже если стараться, то теперь у вас есть DSL, который с очень большой вероятностью Тьюринг-полный.
12. Так что желательно, чтобы это все нормально интегрировалось с IDE.
13. Все перечисленное выше еще должно быть плюс-минус воспроизводимым, чтобы везде был одинаковый результат.
14. И животноводство! Какой только фигни не хотят “чтобы заодно” делал сборщик.

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

Некоторое время назад в случайном видосе услышал занятную аналогию. Директор цирка — это явно не самый крутой акробат, а если и так, то клоун из него так себе. Он может вообще не выступать на арене (как волк). Но при этом он должен разбираться и понимать работу своих сотрудников на достаточном уровне и разумеется, как-то управлять всем этим балаганом.

Сабж. Регулярно обновляется. Можно еще поразиться количеству некриптографических хэшей в дикой природе.

Операционной системой в браузере с учетом существования WASM тяжело удивить — тысячи их! И Linux, и Windows, и FreeBSD, и Kolibri, и QNX… 1, 2, 3. А уж эмуляторов MS DOS, в которых можно еще и в старые игрушки поиграть (верните мне мне мой 1996-й) — вообще миллион.

Недавно еще наткнулся на ОС, которая написана специально под браузер. В том числе в ней обнаружился полнофункциональный клон MS Paint — вернул себе свой 2000-й :)

Неплохая статья про IPv6 и основные заблуждения о нем.

Не все то безопасно, что без unsafe :)

https://github.com/Speykious/cve-rs

UPD: то же самое для питона.

Поисковая выдача компании по продаже рекламы (Google) ощутимо стала хуже — мочи нет. Яндекс не лучше.

Факторов дофига — отток контента в соц-сети и телегу, SEO-оптимизация, копирайтинг (“издревле люди варили макароны…”) data-driven говнизация, алгоритмизация, SPA, “умные” исправления поисковика, смерть RSS, сайты-помойки (копии StackOverflow в том числе), сгенерированные нейронками тексты и отзывы, paywall’ы и т.д.

Все как в мемчике про теорию мертвого интернета — в 2007 это хиханьки-хаханьки, а вот сегодня…

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

Народ изобретает разные костыли для борьбы со всем этим (и некоторыми я иногда пользовался): добавлять reddit к запросу, чтобы был ± жизненный опыт людей, а не реклама и прочий мусор, добавлять before:2022, чтобы снизить количество сгенерированного мусора в выдаче, uBlock-фильтры, чтобы отсеять сайты-помойки и т.п.. Иногда это даже работает!

Попробовал сменить поисковик на DuckDuckGo — не выдержал через пару дней, там все еще хуже. ChatGPT/Gemini по некоторым темам дают хоть какие-то результаты и не надо их искать в стоге говна, но это никак не отменяет галлюцинации и то что они иногда тупые как пробка.

Недавно открыл для себя Perplexity.ai — тоже GPT, но его киллер-фича — показ источников, на основе которых сгенерировалась информация. С ним вроде жить можно.

https://eprint.iacr.org/2024/555

https://github.com/spawnmason/randar-explanation

Годная статья про то, что хотя иметь много возможностей у языка — это круто, но должен быть “официальный стиль”, основа, на которую ориентируются по умолчанию.