Продолжаем тему https://t.me/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
Я, знаете ли, 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