Параллелизация с Rborist

Question

У меня есть большой набор данных n (> 1,000,000) с небольшим количеством функций для оценки (регрессии) случайного леса и были предназначены для реализации Rborist (in R). Я хотел бы распараллелить свою работу, но не нахожу много рекомендаций относительно того, как это будет сделано. У меня есть 16 процессоров для использования на компьютере, где он работает. Когда я использую doParallel с пакетом RandomForest, например, команда:

rf <- foreach(ntree=rep(32, 16), .combine=combine, .packages='randomForest') %dopar% randomForest(x, y, nodesize = 25, ntree=ntree) 

Он запускает 16 процессов R, и работает медленно, как RandomForest делает, но работает.

Аналогичная команда для Rborist:

rb <- foreach(ntree=rep(32, 16), .combine=combine, .packages='Rborist') %dopar% Rborist(x, y, minNode = 25, ntree=ntree) 

Выдает ошибку:

error calling combine function:

Warning message: In mclapply(argsList, FUN, mc.preschedule = preschedule, mc.set.seed = set.seed, : all scheduled cores encountered errors in user code

Кто-нибудь знает, как распараллелить с Rborist? Это не по всей видимости, происходит под капотом, как это только с использованием 1 процессора, когда я бегу:

rb <- Rborist(x, y, minNode = 25, ntree = 512) 

Answer 1

Rborist проходит параллельно сама по себе. Он использует все мои потоки на моей машине (выигрывает 10 64 бит). Но тогда я не загружал doParallel/foreach в первую очередь.

То же самое касается пакета рейнджеров, но в рейнджере вы можете установить количество потоков для использования.

Speedy реализация РЧА имеет в верхней части моей головы:

• Rborist (большой п, р) с низким
• рейнджера (ручки большого р, скромный п)
• случайного forest.ddr (не были проверены)
• распределенный случайный лес в H2O. очень быстро, но использует критерии остановки .

Answer 2

В настоящее время Rborist использует все доступные ядра. Было бы полезно предложить способ настроить это?

Вы пробовали последнюю версию на CRAN, 0.1-3? Это содержит изменение минимального размера узла по умолчанию для регрессии, в некоторых случаях повышение точности.

Мы делали некоторые шаги для улучшения производительности со скромным (в противовес маленькому) счетчику прогнозирования. Это также должно отразиться на изменениях в последней версии.

Large running След по памяти, вероятно, является следствием подхода, основанного на широте разделения. Один из способов сохранить память - это решить проблему на куски, но мы пока не получили ее.

Large final Размер памяти главным образом обусловлен кэшированием информации о листьях для последующего использования другими пакетами или для квантильной регрессии. Возможно, мы должны добавить опцию «noLeaf» для пользователей, которые не заинтересованы ни в одном из этих параметров.