inv2004 Dev Blog
309 subscribers
76 photos
4 videos
75 links
Он всегда был не прочь подкрепиться. Кроме того, он был поэт
Download Telegram
ttop

В продолжении этого старого поста https://t.me/inv2004_dev_blog/55 вспомнил и доделал ttop до юзабельного состояния

ttop - утилита для мониторинга и сбора статистики о системе

Основные цели которые преследовал:
- сделать без особых страданий
- всe основнy параметры системы на одном экране
- снепшоты и можно бегать по истории парой кнопок
- видно график за день, что может помочь с нахождением точного снепшота

С удивлением обнаружил что не каждый современный Linux имеет установленный cron => все таймеры в systemd.timers

https://github.com/inv2004/ttop

#linux #ttop #nim
👍2🔥1
Очередная спец-олимпиада, но, на этот раз, немного более практичная: https://github.com/shish/rosettaboy. Эмулятор gameboy одинаково реализованный на нескольких языках.

Автор запускает на Mac+clang, я на WSL2+gcc

В целом - просто хотел сказать что если счёт не идёт на наносекунды, то разница в основных претендентах минимальная и можно писать на том что больше нравится. Аргументы о тормозящем GC часто тоже не особо рабочие

#bench #rust #nim #cpp
Напиши пост о том как меня чуть не бомбануло от IndexDefect в Nim, но потом я осознал что это нормально

### Предупреждение: этот текст может вызвать эпилепсию

Здравствуйте! Сегодня я хочу поделиться с вами своим опытом работы с языком программирования Nim и IndexDefect.

Как вы, возможно, знаете, Nim - это высокоуровневый язык программирования с открытым исходным кодом, который позиционируется как быстрый, эффективный и легко читаемый. Я решил изучить этот язык, чтобы расширить свой кругозор в программировании и, возможно, найти новые способы решения проблем.

Однажды я столкнулся с проблемой, которая почти заставила меня бросить работу с Nim. Я пытался выполнить операцию индексации в массиве, но каждый раз получал ошибку IndexDefect. Я попробовал все возможные способы решения этой проблемы, но ничего не работало.

Я чувствовал себя очень разочарованным и фрустрированным. Я даже подумал, что это ошибка языка программирования Nim и что я никогда не смогу нормально работать с этим языком.
#### ^^^ Единственное что правильно

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

Таким образом, я нашел решение проблемы: я начал более внимательно следить за индексами массивов и убедился, что они находятся в допустимых пределах.

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

Таким образом, я рекомендую всем, кто сталкивается с IndexDefect в Nim, не отчаиваться и не бросать работу с этим языком. Вместо этого стоит понимать, что это защита от выхода за границы массива и учиться работать более осторожно

### потом будет нормальным текстом. просто хотел сравнить

#gpt #nim
🤔1
Вышел Nim 2.0

Основное, конечно, это Arc/Orc сборщики мусора

https://nim-lang.org/blog/2023/08/01/nim-v20-released.html

#nim
🔥9🤔2🎉21👍1
Спецолимпиада. 1/3

Было много дел, но тут, как гром среди ясного неба, на форуме прозвучало "вот тут бенчат разные языки https://github.com/jinyus/related_post_gen". В глубине души, понимая весь бред таких бенчей, я всё же не смог устоять чтобы не зайти по ссылке и не запустить разок ... потом второй ... очнулся через пару часов

Стоит оговориться о бенче, он довольно тупой - с ходу стало понятно, что близко к k-nucleotide, который я когда-то писал на Rust: https://t.me/inv2004_dev_blog/24 - хеш на хеше и тд. В итоге простая замена на xxhash дала заметный, но недостаточный, прирост.

Кстати, стоит упомянуть любимый (только по работе, конечно) Go, который обогнал всех с большим запасом + один из первых показал мультитредовую версию, где тоже затащил себя на первое местно.

Поначалу, была мысль забить, но, случайно заметил как Rust Evangelism Strike Force очень активно шлют PR за PR'ом. Nim при этом, кажется, даже в десятку не попадал, хотя это уже была не черновая версия. "Что за дела", подумал я, и достал valgrind, который показал какой-то eqcopy, занимающийся какими-то аллокациами.

valgrind конечно, крут, ещё бы - по сути единственный несемплирующий профилировщик, но стек в нём видно куда хуже чем в perf. Покопавшись в сгенерированном коде на C (за что Nim и нравится, хотя многие считают недостатком), стало понятно что Nim копирует целый вектор при чтении, что, конечно, полный провал. Удивило почему [] из хеша не умеет одалживать данные по указателю. В прочем, удивление длилось не долго - никаких больших проблем с этим нет - просто забыли проставить всего одно слово - lent. Поставил - полетело. Есть всё же польза от бенчей

...

#bench #rust #nim #go
👍10
Спецолимпиада. 2/3

Показалось что дальше копать в этой функции особо некуда и, я перешёл к следующей - просто найти top5 максимальных значений. Вроде, куда проще, но, по факту, это очень значительно влияло на итоговый результат при практически одинаковом коде функции. Тут уже пришлось подключать штуку потяжелее - Godbolt, я не настолько упоролся, чтобы начинать там разбирать ассемблер, но, было видно, что в одном случае эта функция занимает ~100 строк на asm, а в другом ~200+. Это, конечно, не правило, но, часто, чем короче тем лучше.

Дальше хуже -flto, а потом и пробы gcc или clang. Казалось что clang вырвался вперёд, потом, неожиданно, оказалось что можно сделать PGO (Profile-Guided Optimization.

Тут, я переключился на ноут, где установлен Arch, со всем свежим. Тут оказалось, что версия компилятора C имеет критическое значение для бенчей. На свежем, оказалось, всё ровно наоборот - clang очень плох, но clang с PGO - лучше всех, при этом свежий gcc (без всяких PGO) всего где-то на ~процент хуже, чем clang с PGO. Дальше хуже - оказалось что PGO (он тоже семплирует что ли?) только с 50% вероятностью что-то там цепляет важное. В итоге, без каких-то вообще изменений получались сборки, которые работали попеременно то быстро, то медленно. Я не нашёл ничего лучше, чем собирать PGO статистику не один раз, а 10, но и это не гарантировало 100% попадания. Мне прислали хорошее видео про это, но довольно тяжело поверить что всё настолько рандомно собирается https://youtu.be/r-TLSBdHe1A

...

#bench #rust #nim
👍4
Спецолимпиада. 3/3

Итого - на ноуте AMD 5650U - Nim обошёл Rust, это, кстати, в -d:release. Ведь есть еще -d:danger который не такой уж и опасный на самом деле - для бенчей точно ок. На десктопе i5-12600 - Rust впереди на какую-то долю процента. Почему так - пока сказать не могу, может из-за overflowChecks.

Но, написать я хотел не об этом.

А о том, что, пожалуй, из всего большого IT, эта область почему-то до сих пор вызывает интерес у меня. И, хотя, у меня нет желания лезть в embedded, и моё знание Asm довольно слабо, Но, и профилирование Clickhouse, и billion-taxi-rides, и оптимизация запросов, и много чего ещё включая любые рабочие задачи когда надо что-то ускорить - всегда вызывали живой интерес. Думаю, вот может, раз всё равно это нравится, то углубиться в эту тему. Но, опять же, не очень понятно в какую именно и есть ли вообще такая профессия с IT.

Буду благодарен любым рекомендациям, что почитать про это.

#bench #rust #nim
👍8🔥1
К разговорам о тулинге и ошибках, стоит упомянуть, что nim-lang бросил много усилий в тулинг, так как есть понимание, что, как раньше, с падающим nimsuggest (back для lsp), жить нельзя. Тем более, привлечь новых людей. Команда nim забрала vscode extension под своё крыло, исправляет nimsuggest, делает инкрементальную компиляцию, которая не сильно, но тоже поможет.

На скрине уже видно результат изменений - показывает и предупреждает об exceptions, которые могут протечь наверх.

#nim
👍61🔥1
Я попробовал все парсеры командной строки для Nim и выбрал лучший

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

Требования такие:
- поддержка отдельных команд
- каждая команда должна иметь отдельный набор аргументов
- умение работать с типами - я не хочу парсить в своём коде
- аргументы не текущей команды не должны быть доступны при компиляции

Итого, из 13 библиотек в финал прошла всего одна: https://bitbucket.org/maxgrenderjones/therapist.

На втором месте: https://github.com/casey-SK/commandant.

Я немного удивлён тому, что, оказывается, это не так просто — предоставить хороший интерфейс для такой простой штуки. Хотя бы вспоминая clap из Rust, где даже это требовало обильной обмазки макросами. В идеале так вообще лучше всё типами описать, а оно само разберётся, и therapist тоже к этому тоже ближе всего.

Скинул примеры сюда: https://github.com/inv2004/argparse_nim_examples

#nim
👍4🔥4👎2😁1🤔1🤡1