XGBoost - как мне установить параметр nthread?

Question

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

months # set of months
for test_month in months:
    sample_list = generate_different_samples([months - test-months])
    for sample in sample_list:
         xgb.train(sample)
         xgb.predict(test_month)
         # evalutaion after

На практике у меня на каждый месяц почти 100 различных тренировочных образцов. Я запускаю свой код на машине с 16 ядрами и 64 ГБ оперативной памяти. Память не является проблемой (набор данных содержит миллионы экземпляров, но они не заполняют память). В настоящее время я распараллеливаюсь на уровне «test_month», создавая, таким образом, ProcessPool, который выполняется все 9 месяцев вместе, однако я изо всех сил пытаюсь установить параметр nthread в xgboost. На данный момент 2, таким образом, каждый поток будет работать на одном ядре, но я читаю в Интернете разные мнения (https://github.com/dmlc/xgboost/issues/3042). Стоит ли увеличивать это число? Я знаю, что вопрос может быть немного расплывчатым , но я искал систематический способ выбора наилучшего значения на основе структуры набора данных.

Answer 1

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

Существует совет в lightgbm, который является инструментом GBM конкурента, где они говорят :

для лучшей скорости установите это количество реальных ядер ЦП, а не количество потоков (большинство ЦП используют гиперпоточность для создания 2 потоков на ядро ​​ЦП)

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

Самый глубокий бенчмаркинг инструментов GBM, который я видел, это этот от Лоры . Он показывает, помимо прочего, масштабирование производительности как функцию количества потоков. Помните, что он действительно продвинут и выводы из него могут не применяться напрямую, если только не будут выполнены те же подготовительные действия на уровне ОС.