2015-09-08 2 views
1

Я играл с сервером rstudio на старом ноутбуке с установленным linux mint (debian).неправильный вариант использования mclapply?

Я всегда работал на окнах, поэтому я никогда не воспользовался parallel или multicore пакетов, и моя цель состояла в том, чтобы узнать rstudio server, а также R linux и как многоядерной обработки может ускорить свои процессы.

Одним из основных использование lapply, что я использую на ежедневной основе выглядит следующим образом:

f <- function(x) { 
    x1 <- data[1:50, x] 
    x2 <- data[51:100, x] 

    line <- c(paste0(mean(x1), " (", sd(x1), ")"), 
      paste0(mean(x2), " (", sd(x2), ")"), 
      t.test(x1, x2)$p.value) 
    return(line) 
} 

data <- data.frame(matrix(rnorm(2600, 85, 19), nrow=100, ncol=26)) 
names(data) <- letters 

do.call(rbind, lapply(letters, f)) 

microbenchmark(
    do.call(rbind, lapply(letters, f)) 
) 

Среднее время 21.8 миллисекунды

В качестве альтернативы:

library(parallel) 
microbenchmark(
    do.call(rbind, mclapply(letters, f)) 
) 

Среднее время 120.9 миллисекунды ,

Почему эта огромная разница?

Машина представляет собой двухъядерный динозавр. Разве вы не видите преимущества, пока не будете работать с> = 4-ядерными машинами? Является ли мой вариант использования (расчеты по столбцам data.frame) неправильным, чтобы увидеть преимущества?

Спасибо!

ответ

1

Ваши данные мал, чтобы иметь преимущество против накладных расходов, попробуйте

f <- function(x) { 
    x1 <- data[1:50000, x] 
    x2 <- data[50001:100000, x] 

    line <- c(paste0(mean(x1), " (", sd(x1), ")"), 
      paste0(mean(x2), " (", sd(x2), ")"), 
      t.test(x1, x2)$p.value) 
    return(line) 
} 

data <- data.frame(matrix(rnorm(2600, 85, 19), nrow=100000, ncol=26)) 

вместо этого и проверьте результат. Ваш пример взял мой ноутбук с 7 и 17 срединными miliseconds, но мой больший пример меняет это на 120 и 80. Так что, на мой взгляд, это (не только) количество ядер, но больше размер ваших данных в этом случае.

+0

Я просто попробовал это и на своем 2-ядерном процессоре. Зазор закрылся примерно на 4 десятых миллисекунды, поэтому ничего близкого к изменению вы не получили, но это было по крайней мере в правильном направлении. Я решил настроить систему в обоих направлениях, удвоив количество переменных для вычисления (до 52), после чего я наконец нашел, что mclapply имеет более быстрое среднее время вычисления. Благодаря! –

 Смежные вопросы

  • Нет связанных вопросов^_^