#global #optimization #benchmarks

Дали ссылку на такое вот иллюстрированное сравнение численных оптимизаторов

https://infinity77.net/go_2021/thebenchmarks.html

#optimization #global #benchmarks #python #cuckolds

Набрёл на вот какое классное питоновское сравнение оптимизаторов! Оказывается, не гипероптом и оптуной едиными! )
Открылись питоновские оптимизаторы, о которых никогда раньше не слышал: Facebook Ax, PySOT, PyMoo, Platypus, pattern.

Автор бенчмарка тоже не в восторге от поведения функций глобальной оптимизации scipy, но он себя успокаивает, что там по-другому, наверное, просто нельзя было сделать:
Evaluating "naughty" optimizers. In this discussion, a naughty optimizer is one that does not limit function evaluations to precisely what the user might desire. As an aside, this isn't a critique. Often the optimizers cycle through parameters, or perform some other subroutine that involves multiple function evaluations - so they only stop periodically to see whether the user-supplied maximum has been exceeded. It may not be sensible to do otherwise, depending on the details of the algorithm.

Я же ответственно вам заявляю, что можно было. Даже если у тебя внутри вложенные процедуры, никаких проблем передать в них максимальное и текущее количество оценок и выйти по условию НЕТ, в процедуре более высокого уровня можно проверку повторить. Это просто мудаки-разработчки. Если параметр у тебя называется max_evals, будь добр, обеспечь, чтобы это количество не превышалось, иначе ты мудак. Хм, или куколд? ) На твои параметры можно только смотреть, они все равно ни хрена не делают )

Кстати, странно, что автор не нашёл идеи нормализовать результаты на реальное количество оценок функции, он же вместо этого для куколдовских алгоритмов scipy итеративно подбирал max_evals так, чтобы реальное max_evals примерно подходило. Также большой недостаток, что у оптуны и гиперопта не проверялись разные сэмплеры и параметры (как их назвать-то? метапараметры?), видимо, всё взяли по дефолту. И шакала оценок совершенно непонятная, если честно, в таблицах не найденные экстремумы, как я думал, а какие-то странные скоры с привязкой ко времени поиска. А, или в основной таблице скоры, а в куколдовских средние найденные экстремумы...

Но ближе к делу, факт в том, что очень хорошо себя показали pysot, pattern из pymoo и shgo+powell из scipy. А значит, их надо затестить тоже.

https://www.microprediction.com/blog/optimize

#optimization #global #benchmarks #python #humpday

Продолжение оптимизационного банкета от того же автора. Он подготовил единый интерфейс для сравнения работы алгосов из доброго десятка оптимизационных пакетов. Я даже не имел понятия, что их СТОЛЬКО, реально под полсотни.

Ну и я посмотрел, что он в итоге советует. В топ-10 автора вошли optuna-cmaes и skopt-gp_minimize, которые на моей одномерной задаче сработали вообще хуже всего... Неужели они так раскрываются с повышением мерности?

https://www.microprediction.com/blog/humpday

#hardware #cpu #amd #benchmarks

Не успел я порадоваться выходу новых процессоров threadripper и threadripper pro, как выяснилось странное. Судя по тестам, AMD ухитрились полностью угробить производительность в DS-приложениях. Что же они там такого накуролесили, интересно, что стало хуже своих же старых моделей? И вообще, почему в разделе AI бенчат только тензорфлоу, на него ведь сами разработчики, как мы знаем, положили уже с индусским прибором? Я бы хотел включения в тесты бустингов. И где, блин, тесты в Стокфише!!

https://3dnews.ru/1096266/vishli-obzori-amd-ryzen-threadripper-7000-samie-bistrie-protsessori-dlya-renderinga-no-ne-dlya-ii

#amd #nvidia #benchmarks

Неужели Нвидия смухлевала в тестах?

"По словам AMD, свои данные NVIDIA приводит:
на основе тестов H100 с библиотеками TensorRT-LLM вместо библиотек vLLM, которые использовались для тестов ускорителей AMD;
сравнивает производительность ускорителей AMD Instinct MI300X в вычислениях на числах FP16, а для тестов своих H100 использует данные типа FP8;
в графиках инвертировала данные AMD об относительной задержке в показатель абсолютной пропускной способности.

Согласно новым тестам AMD, её ускорители MI300X, работающие с библиотеками vLLM, на 30 % производительнее ускорителей NVIDIA H100, даже если последние работают с библиотеками TensorRT-LLM. "

https://3dnews.ru/1097567/amd-otvetila-na-zayavleniya-nvidia-uskoriteli-mi300x-bistree-h100-na-30-dage-v-optimizirovannih-sredah-ispolzovaniya

#hardware #benchmarks #mlperf #opticloud

Постараюсь прояснить идею с либой ML бенчмарка. Зачастую непонятно, какой сервер лучше взять под конкретную ML-задачу. Если дело касается нейросетей, то вроде бы есть бенчмарки dlperf. Также при выходе новых CPU/GPU указывают производительность в Stockfish, WinZip, Pytorch/Tensorflow.

А если у вас табличные данные? Брать ли сервер на AMD Rome с 112 vcores, Xeon Gold с 80 vcores, или одна RTX 4090 их легко зарулит? А две RTX 3090? А насколько быстрее/медленнее будет одна H100? А может, вообще стоит посмотреть в сторону GPU от AMD?

У меня одного такие проблемы выбора, или отсутствие подобной информации и, как следствие, выбор наобум по принципу ХЗ всех смущает?

Может, есть какие-то сводные таблицы перформанса, которые вы смотрите и по которым принимаете решение? Или как-то пытаетесь экстраполировать результаты существующих бенчмарков?

На текущий момент у меня есть идея разработки простенькой питон либы с открытым исходным кодом, на базе, скажем, catboost, с методами

run_ml_benchmarks(tabular=True,training=True,inference=True,nreps=10)
get_ml_rankings(query='rtx 3090')
get_ml_leaderboard()

которая сможет автоопределять ваше железо, запускать несколько задач с фиксированными сидами и гиперпараметрами, прогонять nreps раз, и сохранять результат в общее облако. ну и, конечно, показывать лидерборд и результаты конкретного железа (медиану, дисперсию). При наличии такой либы все вопросы выше отвечаются pip install-ом + одним вызовом get_ml_leaderboard.

#hpo #hpt #benchmarks #cv

Кажется важной темой, т.к. я частенько вижу, что сделанный тюнинг модели не приводит к практическим улучшениям OOS.

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

#benchmarks #sota

Я не согласен с автором, что надо забить на бенчмарки в сфере интерпретабельности. "Просто" нужны хорошие синтетические бенчмарки.

"The obsession with benchmarks and SOTA runs deep:

Creation of benchmark islands.
People on social media arguing over which ML algorithm is better.
Difficulties in publishing new approaches that don’t beat the state-of-the-art.
LLM evaluation based on benchmarks even when they start memorizing them.

The hope is that the performance on these benchmark tasks and datasets are predictive of performance on new datasets. Ideally, the benchmark datasets are representative of the typical dataset you would work on in the future. But it’s not like we can sample from the distribution of datasets. Benchmarks are guided by what datasets are openly available (huge selection bias already) and which datasets are convenient to use (for example in clean CSV format and not in some wild Excel construct). Benchmarks are not representative samples, they are arbitrary samples."

https://mindfulmodeler.substack.com/p/we-are-obsessed-with-benchmarks