#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.