2013-11-23 7 views
1

Я пытаюсь использовать GotoBLAS2 на R 3.0 на Unix. Я загрузил исходный код GotoBLAS2 с веб-сайта TACC, скомпилировал его и заменил libRblas.so на libgoto2.so, следуя инструкциям по ссылке http://www.rochester.edu/college/gradstudents/jolmsted/files/computing/BLAS.pdf. Простые матричные операции в R, такие как «определитель», в 20 раз быстрее, чем раньше (я использую огромные матрицы), что хорошо. Тем не менее, я не могу использовать многие ядра параллельно.GotoBLAS2 с несколькими ядрами

Например, ниже код работает вечно. Но если я использую прокомментированный вариант «for» вместо «foreach», это займет всего секунду. Когда я использовал по умолчанию библиотеки BLAS R в, я мог бы работать ниже код (используя несколько ядер) (но это заняло больше времени, так как BLAS не было оптимизировано, конечно) ..

library("foreach") 
library("doParallel") 

registerDoParallel(cores=2) 
set.seed(100) 

foreach (i = 1:2) %dopar% { 
# for (i in 1:2) { 
a = replicate(1000, rnorm(1000)) 
d = determinant(a) 

Так, можно использовать много ядер одновременно с GotoBLAS2, есть ли у вас какие-либо идеи?

Большое спасибо.

ответ

0

Скорее всего, GotoBLAS уже использует несколько ядер, поэтому нет никакой пользы в использовании %dopar%. Я также ожидал бы замедление от %dopar%, поскольку вы используете больше потоков, чем количество ядер процессора, которые у вас есть.

Все еще не ожидал, что код будет «работать вечно», только медленнее, чем for.

+0

Моя машина имеет 24 ядер, и я обычно использую% dopar% с 10 ядрами, что делает вещи действительно быстрее. – user2503950

+0

Я выполняю операцию над разными файлами независимо, поэтому я бы предпочел параллельную работу. Для этого начального задания мне вообще не нужен BLAS, но я должен применить детерминант к результату этой операции, где мне нужна оптимизированная BLAS, поэтому я должен включить определитель внутри «foreach». И что я подразумеваю под «навсегда»: «все еще работает через 24 часа, и я его убил». Итак, с «for», это 1 секунда, а с «forach» - более 24 часов. Вероятно, проблема связана не с количеством потоков, а с ошибкой в ​​GotoBLAS2, или, может быть, не соответствует R3.0.2. – user2503950

+0

Если вы хотите использовать параллельные операции с использованием R, я бы предложил отключить его для GotoBLAS через среду «OMP_NUM_THREADS» или «GOTO_NUM_THREADS». Надеюсь, это может решить проблему. –

1

Вы должны убедиться, что количество рабочих элементов doParallel раз превышает количество потоков, используемых вашей библиотекой BLAS, не больше количества ядер, если параллельные задачи будут выполнять многопоточную операцию. Но вы можете столкнуться с другой проблемой, вызванной GotoBLAS2.

Стандартная сборка GotoBLAS2 и OpenBLAS по умолчанию задает близость процессора к процессу R таким образом, что дочерние процессы обрабатываются на одном ядре процессора. Это создает серьезные проблемы для пакетов, таких как parallel/doParallel, поскольку все рабочие вынуждены использовать одно ядро.

Вы можете решить эту проблему с помощью новой функции «mcaffinity», которая была добавлена ​​в параллельный пакет в R 3.0.0 специально для решения этой проблемы. Вы также можете использовать его, чтобы убедиться, что это ваша проблема. Вот выход из R сеанса, который был первоначально ограниченного для запуска на одном ядре:

> library(parallel) 
> mcaffinity() 
[1] 1 
> mcaffinity(1:128) 
[1] 1 2 3 4 5 6 

После выполнения этого, все шесть ядер могут быть использованы. Для вашего примера просто добавьте mcaffinity(1:128) перед выполнением цикла foreach.

Но так как вы построили GotoBLAS2 от источника, вы можете также отключить эту функцию, установив NO_AFFINITY в «1» в Makefile и Перестройка:

# If you want to disable CPU/Memory affinity on Linux. 
NO_AFFINITY = 1 
Смежные вопросы