Еще мне в go нравится тотальная нулабельность.

Вернее, не совсем так.

Меня бесит, что #LLM вставляют ненужные проверки на nil. Связано это с тем, что эти ленивые твари очень не любят рефакторить тесты, и то и дело норовят подсунуть nil в качестве нового поля, со всемы вытекающими. Борюсь с этим постоянно, устраиваю регулярные забеги на код, но увы.

Но мне очень в кайф то, что nil мапа/массив/chan/etc - это валидные состояния этих структур данных, со вполне определенными операциями над ними - можно разыменовать nil мапу на чтение, можно взять длину, и так далее.

Поэтому в go, если ты получил от аллокатора зануленный блок памяти под структуру (а в go он всегда занулен), то этот кусок памяти автоматически является валидным объектом любого типа! Это не случайное свойство, оно является частью дизайна языка и runtime.

Вы себе не представляете, какое это классное свойство для языка для разработки на нем высокопроизводительного кода!

Не верите - посмотрите как-нить на ассемблер сгенеренного С++ компилятором сложного конструктора, и сравните это с "чистым" (и очень быстрым!) memset от go!

Кстати, из этого свойства следует много других прикольных свойств, типа очень эффективные пулы "почти готовых" объектов, но не буду сейчас на этом останавливаться.

https://ria.ru/20260612/putin-2098660037.html

"Россия недавно вывела еще 16 аппаратов системы спутниковой группировки, которая лучше, чем Starlink, сообщил президент России Владимир Путин"

Продолжаем тему https://t.iss.one/itpgchannel/4165 "#LLM позволяют автоматизировать то, что раньше было автоматизировать невыгодно", и, одновременно тему "одна программа проводила 20% всего CPU time в работе с map"!

Я, знаете ли, performance freak. Могу задрачивать лишние пару процентов перфа неделями, если вижу профит в этом.

Perf оптимизациями я, так или иначе, занимаюсь последние лет 20, как на работе, так и для себя. Думаю, будет вполне уместно сказать, что в Я мало высокопроизводительного кода, к которому я когде-то не прилагал усилий.

Вот, #LLM позволяют погружаться в такие бездны perf оптимизации, которые раньше были out of scope, потому что удельная полезность их была невелика.

В своем крестовом походе против "20% всего CPU time в работе с map" я дошел совсем уже до мелочей.

Например, 50к лукапов было в таблицу парсеров по расширению файла. Понятная задача - найти для файла подходящий ему парсер.

Казалось бы, 50к не очень много, но с 40 миллионов лукапов я уже спустился до 500к лукапов на всю программу, и 50к стало уже заметно на общем фоне.

Раньше я бы на этом и остановился, потому что овчинка выделки не стоит.

А тут я просто написал клоде "так, строй perfect hash, первый диспатч по длине расширения, второй - по линейной комбинации букв расширения, брутфорс для поиска минимума операций. Скрипт с генератором положи в dev/, так же туда перенеси список всех расширений, чтобы его можно было менять только через regen".

Через 5 минут у меня был готов скрипт-генератор https://github.com/pg83/ay/blob/master/dev/gen_parsers.py, и очень быстрый лукап парсера по расширению файла - https://github.com/pg83/ay/blob/master/parsers_generated.go#L74, раза в 2 быстрее обычного поиска в таблице.

Мораль? Как обычно, ее нет!

#perf

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

"Зафиксирована массовая компрометация пакетов в репозитории AUR (Arch User Repository), применяемом в Arch Linux для распространения приложений от сторонних разработчиков. Атакующие получили контроль над 1577 пакетами и смогли внедрить в них вредоносный код для кражи паролей и ключей доступа с систем пользователей. Среди прочего, вредоносный код был интегрирован в поставляемый через AUR пакет ALVR, популярный у любителей компьютерных игр"

AUR изначально - literally система для запуска в своей системе произвольного скрипта от произвольного Васяна из интернета, поэтому это даже компрометацией назвать сложно.

Очень жаль, и это - леденящий душу пиздец.

Я, когда писал https://t.iss.one/itpgchannel/4156 "пока добровольно, но я уже, конечно, представляю, что по-настоящему сильный AI обычным работягам не достанется", не предполагал, что это случится так быстро.

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

Фабула крутая.

Прошлой осенью с sonnet я понял, что там есть профит - можно было дать задачу на кодинг, и она будет сделана.

С опусом стало понятно, что LLM может сама предложить достаточно вменяемые решения сложных задач, и следить за их исполнением.

С фабулой же я общался почти на равных.

https://www.rbc.ru/technology_and_media/13/06/2026/6a2d12da9a7947f7d5334aa0

Японский GlobalSign начал отзыв «цифровых паспортов» российских сайтов

Узнал сегодня новое слово от #LLM!

Понабрался в общении с #LLM, и вам дарю.

Если в общении XXX вызывает вопрос, то "XXX - deep dive". Работает гораздо лучше, чем "посмотри вот сюда, что тут и как".

gate - универсальный токен, работает как в "gate для прохождения PR - ...", "какой gate доступа к этому медленному коду" (в perf оптимизациях), да и просто "а чем это загейчено"?

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

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

"Дэниел Cтенберг (Daniel Stenberg), автор утилиты для получения и отправки данных по сети curl, объявил о приостановке приёма и обработки сообщений об уязвимостях с 1 июля по 3 августа. Исключение будет сделано только для отправителей, пользующихся платной поддержкой. В качестве причины называется необходимость передышки и отдыха после существенного повышения нагрузки по разбору отчётов о выявлении уязвимостей в последние четыре месяца"

В голове крутится что-то на тему "ебала жаба гадюку", и "приятно наблюдать, как блядей корежит".

В той же программе понадобился быстрый https://en.wikipedia.org/wiki/Longest_prefix_match. Обычно это решают с помощью trie, или погружением префиксов в хештаблицу (разными способами).

Мне захотелось выжать из этого максимум, и я попросил #LLM устроить мне deep dive в то, какие trie вообще бывают, и какие структуры данных еще бывают для LPM.

Вот, нашел Darts - https://dl.acm.org/doi/10.1109/32.31365.

Раньше никогда не приходилось встречаться с такой структурой данных, но именно она подошла лучше всего:

* У нее максимально cache friendly внутренние структуры - https://github.com/pg83/ay/blob/master/darts.go#L17

* Очень сжатый внутренний цикл - https://github.com/pg83/ay/blob/master/darts.go#L141

Через 15 минут я получил x10 по сравнению с reference implementation от LLM, и на том успокоился.

(В целом, структура данных напоминает open addressing hash table + streaming hash типа fnv, но с ранним остановом)

#perf

#LLM

Стандартная мантра "планируй опусом, реализуй сонетом" кажется все более и более ошибочной.

Все сложные процессы, которые я перевел с такой схемы на "всегда использовать модель на максималках", стали сходиться быстрее, и дешевле.

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

Начинаю склоняться к тому, что совет по умолчанию - "используйте самую мощную доступную модель, кроме как если задача заведомо совсем простая".

И это верно не только для моделей от антропиков, но, например, и для моделей от openai.

У меня нет конкретных цифр A/B, но, после того, как я прикрутил https://t.iss.one/itpgchannel/4119, я за этим наблюдаю. Я перестал выжирать недельную квоту за 2 дня, это фактический факт.