#animals #fun

https://www.youtube.com/shorts/NS-_skIItvc

#chess

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

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

#writing #thinking

Классная статья о том, как изложение мысли в письменном виде помогает кристаллизовать идею. Signposting прикольная техника.

"Writing is the “last mile” of your data science work. None of your stakeholders will read your SQL query or look at your Jupyter Notebook (a lot of engineers and data scientists would like believe the opposite but trust me, they likely won’t). If you want your work to be understood by others and influence decisions, then you need to do the final step of packaging it in an effective write-up. If you skip this step, it’s like leaving the package in the warehouse instead of delivering it to the customer."

https://towardsdatascience.com/the-most-undervalued-skill-for-data-scientists-e0e0d7709321

#wisdom

If writing down your ideas always makes them more precise and more complete, then no one who hasn’t written about a topic has fully formed ideas about it. And someone who never writes has no fully formed ideas about anything nontrivial.

— Paul Graham

#uplift

Оказывается, для аплифта А/Б тест должен содержать 3 группы.

https://youtu.be/EkmH_ghjvjA?si=dE-38LAprKAMNlIA

#music #deutsch

Stellt die Uhren auf NULL )

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

#physics

"Принцип работы атомных часов основан на подсчёте колебаний атомов — это крайне предсказуемые события. Например, атомы цезия-133 совершают 9 192 631 770 колебаний в секунду, и с 1967 года это используется для официального определения секунды. Атомные часы на основе этого элемента сбиваются на одну секунду за 300 млн лет.

Учёные JILA построили атомные часы, которые намного точнее. Проект основан на нескольких разработках, которые исследователи создали за последние годы. В приборе используются атомы не цезия, а стронция, которые колеблются 429 трлн раз в секунду; а измерения производятся при помощи не микроволн, а видимого света, волна которого имеет более высокую частоту.

Десятки тысяч атомов стронция заключаются в мягкую «световую решётку», которая помогает значительно повысить точность атомных часов, потому что отсутствуют два источника ошибок: влияние лазерного излучения и столкновения атомов друг с другом. В результате точность прибора составляет 8,1 единицы к 10 квинтиллионам. Другими словами, такие часы дадут сбой на одну секунду, проработав 30 миллиардов лет — это более чем вдвое превосходит текущий возраст Вселенной.

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

https://3dnews.ru/1107518/postroeni-samie-tochnie-atomnie-chasi-oni-sbivayutsya-na-1-sekundu-za-30-milliardov-let

#security #pandas #cryptography #cryptpandas

Интересно, как куски зашифрованного файла прогоняют через энтропийный анализ, чтоб уточнить алгоритмы шифрования:

"In CyberChef, we can also save the artifacts (refer to the aged-diskette icon) and it will save the file as a raw binary (sans the base64 encoding we tested it with). We then can throw that into Kali and run some tests on both the base64 version and the raw version and check to see what their entropy values are."

Вообще использование cryptpandas может быть хорошей идеей для облачных вычислений.

https://eforensicsmag.com/forensic-fun-with-cryptographic-dataframes-using-python/

#mlperf #aws #opticloud

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

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

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

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

Мне захотелось реализовать сервис mlperf в облаке AWS, так что пока архитектура выглядит как API Gateway->Lambda->ElastiCache/Redis->DocumentDB:

0) пользователь, желающий внести вклад в тестирование железа, запускает скрипт mlperf в командной строке или делает вызов benchmark(...) из питон-кода.
1) пользователь вводит код аутентификации от гугл (перейдя в браузере по ссылке, напечатанной скриптом)
2) скрипт выполняет тестирование и передаёт полезную инфу+код в json по https на url приложения mlperf.
3) запускается lambda-функция, проверяющая размеры переданной информации, извлекающая емэйл пользователя из auth кода.
4) попадание в рэйтлимиты проверяется с помощью развёрнутого ElastiCache/Redis (INCR/EXPIRE)
5) если проверки пройдены, инфа сохраняется в основную таблицу DocumentDB.
6) клиенту возвращается статус операции.

7) некий демон (Максвелла?) в виде очередной Lambda периодически отбрасывает аномалии и аггрегирует все результаты в лидерборд.

Предложения/замечания?

#mlperf #aws #opticloud

Что конкретно тестировать?

Основная идея была в тестировании 3 современных библиотек градиентного бустинга - CatBoost, LightGBM, XGBoost, причём только на задаче обучения и на одном датасете с фиксированным размером, гиперпараметрами и сидами. Даже нет, не 3 бустингов, а 1 - катбуста, т.к. казалось, что сравнительные результаты 2 остальных не будут отличаться.

Потом появилось понимание, что между библиотеками/реализациями могут быть нюансы. К примеру, катбуст может из коробки использовать несколько GPU. LightGBM вообще самый проблемный в плане использования GPU, там на *nix надо танцевать с бубнами.

В случае катбуста и мульти GPU пересылка данных может стоить слишком дорого и даже ухудшать результаты по сравнению с 1 GPU, так что, похоже, надо предусмотреть несколько вариантов размера данных. И при multigpu делать тесты начиная с одного устройства и далее 2, 4, 8...

Также пришла идея замерять инференс (возможно, опционально с интеловским ускорением). Опять же, некоторые либы поддерживают инференс на GPU (XGBoost точно).

Нужен ли RAPIDS, им кто-то вообще пользуется?

DL бенчмарки по идее можно раскопать, и я не думал их добавлять, но всё же... Надо ли кому-то? Скажем, Pytorch Lightning на CPU/GPU, с разными стратегиями шардирования и точностями (float 64/32/16 etc)? если добавлять нейросети, то тогда нужен тест архитектуры со свёртками, т.к. для свёрток сильно докидывают тензорные ядра.

Еще не совсем ясно, что делать, если у пользователя на момент запуска бенчмарка уже загружены некоторые ядра/видеокарты. Морду кирпичом и гнать тесты? Не запускать тесты, пока все не освободятся? Запускать, но с уменьшенным количеством ресурсов?

По поводу инфы о железе: думаю собирать полную, т.е. не только названия моделей CPU/GPU/RAM, но и частоты, характеристики.

С частотами неясно, как их лучше мониторить. Если замерять до запуска скрипта, на машинах с энергосбережением они ведь окажутся заниженными. Получается, надо в отдельном потоке как-то собирать каждую секунду и потом брать средние за время работы скрипта? Возможно, то же самое придётся делать с показателями nvidia-smi.

По софтовой части, обязательно фиксировать версии бустингов, cuda, runtime (python), os, opencl (?).

#news

"Многие аналитики не раз подчёркивали, что до сих пор от так называемого бума искусственного интеллекта с точки зрения капитализации выигрывала преимущественно Nvidia, тогда как выпускающая по её заказу чипы для ускорителей вычислений TSMC до сих пор оставалась в тени. На днях, однако, капитализация TSMC преодолела планку в $1 трлн."

https://3dnews.ru/1107070/catl-rasschitivaet-chto-eyo-akkumulyatori-pozvolyat-k-2027-godu-sozdat-samolyoti-preodolevayushchie-bez-podzaryadki-do-3000-km

#opticloud #mlperf #fun

Family: 179 😅

#opticloud #mlperf #tabularml

Немного новостей по грядущей утилитке tabular ml benchmark.

Закончил написание сборщиков информации о системе, CPU, GPU для Windows и Linux. MacOS пока не поддерживается.

Собирается очень много информации: все флаги способностей центрального процессора (спасибо cpuinfo), детальные cuda capabilities каждого GPU (спасибо numba.cuda).
Еще больше детализированной информации (RAM, Board, Bios, Cache, OS) собирается через os-специфичные способы доступа: wmi для Windows, dmidecode для Linux.

Завершил тестирование мониторинга загрузки железа. Эта штука запускается в отдельном потоке, ждёт 1 секунду и начинает каждую секунду замерять загрузку процессора, памяти, и выбранных GPU.
По прекращении теста данные усредняются. Пример выдачи (без реальной нагрузки):

Average hardware Utilization: {'cpu_utilizaton_percent': 2.725, 'cpu_clocks_mhz': 2601.0, 'own_ram_used_gb': 0.164, 'total_ram_used_gb': 17.538, 'total_ram_free_gb': 110.409, 'gpu_ram_free_gb': 7.61, 'gpu_ram_used_gb': 0.231, 'gpu_clocks_mhz': 82.25, 'gpu_utilizaton_percent': 12.75, 'gpu_power_draw_watt': 7.83, 'gpu_temp_celsius': 39.0}

Думаю об эффективном хранении результатов тестов. Пока идея такая: юзер запускает скрипт, скрипт фиксирует железо и передаёт полную опись в облако. Железо попадает в табличку user_sessions, обратно отдаётся session_uuid. Скрипт начинает прогонять различные тесты, каждые N секунд сбрасывая в облако накопленные результаты со своим session_uuid. Тем самым обеспечивается компактность таблицы результатов (и хотя бы частичная сохранность данных в случае какого-то железного крэша).

Как планирую хранить инфу о железе: описание каждого CPU/GPU имеет сотни полей. Думаю при получении новой записи сортировать словарь и считать хэш от его текстового представления (удалив переменные поля типа name). Если такого хэша в таблице hw_info ещё нет - добавлять запись. В таблице же user_sessions хранить массивы hw_hashes. Помимо очевидной экономии места, это позволит распознавать процессоры, для которых не указана модель (в контейнерах и инженерных образцах и не такое встречается).

По поводу архитектуры - возможно, добавлю еще слой SQS, куда будут быстро складироваться результаты тестов (а потом уже пакетно забираться в базу).

Перехожу к обновлению ассортимента ML-тестов. Решил добавлять все 3 градиентных бустинга в CPU и GPU режиме. lightgbm в GPU режиме работает через opencl, в cuda-режиме мне его скомпилировать не удалось.
XGBoost хочу ещё попробовать в Dask-версии.

Возможно, еще добавлю что-то из Rapids/cuml - лес и опорные вектора?

Ах да, и будет pytorch-lightning.

#series #from

Ага, осенью 3-й сезон From!

https://www.imdb.com/video/vi3781411609

#featureselection

Классная идея применения коэффициентов Шэпли для отбора признаков!

Задача FS вообще NP-сложная и сводится к выбору оптимального значения бинарного вектора длины n_features (n_features это количество признаков-кандидатов в исходной выборке). Строго говоря, для её точного решения нужно оценить OOS-метрики моделей, обученных на всех возможных сочетаниях признаков от 1 до n_features (2^n_features комбинаций).

Автор же показывает, как, используя свойство аддитивности индивидуальных shap values признаков, можно заменить дорогое обучение модели и выдачу прогноза на комбинации признаков на... просто суммирование shap values этих признаков в большой модели (обученной один раз на всех признаках).

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

PS. Тут надо провести дописследование. Как бы не вытащить себя самих за волосы из болота, как известный барон )

А вообще, конечно, сразу приходят в голову возможные улучшения для этого подхода:

1) обучать вместо одной N больших моделей (с разными HPT и вообще разными алгоритмами
2) обучать вместо одной большой модели на всех признаках M моделей на случайной части 1/M от всех признаков. Потом при оценке комбинаций, полностью попадающих в бакет i=1..M, брать не общую модель, а более конкретную i (ну или взвешенное среднее).
3) комбинация 1 и 2
4) а точно ли не нужно никакое масштабирование частичных сумм значений Шэпли?

Если эта идея рабочая, она позволит расширить область применения полного перебора (а это самый точный метод FS) с 5 (32 честные комбинации) до примерно 40 факторов (1.1 трлн аппроксимированных комбинаций).

Ну и, практически говоря, это поможет и в частичном переборе. Например, получили мы какой-то перспективный список предикторов - от эксперта, RFECV, или как-то ещё. Ну и берём 20-30-40 лучших признаков из списка, насколько потянет железо, и применяем полный аппроксимированный перебор уже к этому сокращённому списку. Профит? Профит.

Посоветовался с чат гпт, после нескольких пинков она даже сама распознала, что

Using SHAP values to approximate the predictions of models trained on specific subsets of features is an innovative approach. The idea is to use the contributions of individual features (as captured by SHAP values) to estimate the predictions of a model that would have been trained on a subset of those features.

Предложила использовать среднее сумм shap values предикторов-кандидатов для коррекции base value, и Interaction-aware SHAP Values.

Через год что, эти чёртовы языковые модели нас полностью превзойдут уже и в научной креативности? )

https://towardsdatascience.com/approximate-predictions-make-feature-selection-radically-faster-0f9664877687

#astronomy

Фига себе пингвинчик!

https://3dnews.ru/1108006/na-yubileynom-snimke-dgeymsa-uebba-poziruyut-dve-stalkivayushchiesya-galaktiki-pingvin-i-yaytso