#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

#godmother

"Известный специалист по компьютерным наукам Фэй-Фэй Ли (Fei-Fei Li), которую называют «крёстной матерью искусственного интеллекта», основала стартап World Labs, который всего за четыре месяца своего существования достиг оценки более миллиарда долларов.

Фэй-Фэй Ли известна своим вкладом в компьютерное зрение — область ИИ, посвящённую помощи машинам в интерпретации и понимании визуальной информации. Она возглавляла разработку ImageNet — обширной визуальной базы данных, используемой для исследований в области распознавания визуальных объектов. С 2017 по 2018 год Ли руководила отделом ИИ в Google Cloud, а в настоящее время консультирует рабочую группу Белого дома по ИИ."

Чего? Кто её называет «крёстной матерью искусственного интеллекта»? Впервые слышу это ФИО. А вы?

https://3dnews.ru/1108120/noviy-startap-kryostnoy-materi-ii-otsenili-v-1-milliard-dollarov

#opticloud #mlperf #tabularml

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

Улучшил парсинг dmidecode и lscpu. Добавил сохранение battery_info, power_plan, large_pages_support (всё кросс-платформенно).

Начал крутить тесты, и тут вылезли интересные детали. Как меня и предупреждали, тайминги обучения модели (даже относительные, например, катбуст CPU vs катбуст GPU) оказались сильно зависимы не только от типа задачи (к примеру, регрессия vs мультирегрессия), но и от размера датасета (разница от 2 до 5 раз).

(Кстати, пришлось некоторые гиперпараметры жёстко прописать, типа border_count= 128,learning_rate=0.1 для катбуста, если этого не сделать, по умолчанию в CPU-режиме border_count будет назначен вдвое выше, и будет казаться, что CPU-версия еще медленнее, чем она есть. а learning_rate при её неуказывании вообще подбирается адаптивно и во многом случайно.)

Скорее всего, обнаружатся такие гиперпараметры, которые будут сильно сдвигать соотношения таймингов CPU vs GPU, но тут ничего не сделать, кроме как запускать тест в 3 вариантах (small, medium, big) и, возможно, в нескольких наиболее часто используемых конфигах (но каких?).

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

#hardware #benchmarking #dl

"Deep learning is a field with intense computational requirements, and your choice of GPU will fundamentally determine your deep learning experience. But what features are important if you want to buy a new GPU? GPU RAM, cores, tensor cores, caches? How to make a cost-efficient choice? This blog post will delve into these questions, tackle common misconceptions, give you an intuitive understanding of how to think about GPUs, and will lend you advice, which will help you to make a choice that is right for you."

Не знал про Tensor Memory Accelerator (TMA). Кстати, весьма странно, что Nvidia не даёт возможности программно запросить количество набортных Tensor Cores и RT cores (хотя десятки других параметров доступны через Cuda API). Зажрались!

https://timdettmers.com/2023/01/30/which-gpu-for-deep-learning/

#cloud #aws #tuning

Оказывается, некоторые облачные машины можно затюнить под конкретную вычислительную задачу по P- и C- состояниям.

"In this example, vCPUs 21 and 28 are running at their maximum Turbo Boost frequency because the other cores have entered the C6 sleep state to save power and provide both power and thermal headroom for the working cores. vCPUs 3 and 10 (each sharing a processor core with vCPUs 21 and 28) are in the C1 state, waiting for instruction.

In the following example, all 18 cores are actively performing work, so there is no headroom for maximum Turbo Boost, but they are all running at the "all core Turbo Boost" speed of 3.2 GHz.

You can reduce the variability of processor frequency with P-states. P-states control the desired performance (in CPU frequency) from a core. Most workloads perform better in P0, which requests Turbo Boost. But you may want to tune your system for consistent performance rather than bursty performance that can happen when Turbo Boost frequencies are enabled.

Intel Advanced Vector Extensions (AVX or AVX2) workloads can perform well at lower frequencies, and AVX instructions can use more power. Running the processor at a lower frequency, by disabling Turbo Boost, can reduce the amount of power used and keep the speed more consistent. For more information about optimizing your instance configuration and workload for AVX."

https://docs.aws.amazon.com/linux/al2/ug/processor_state_control.html