Gputools for R: ¿cómo interpretar el procedimiento experimental?

Question

El siguiente artículo describe una implementación de R en paralelo en una unidad de procesamiento gráfico (GPU).

• Buckner y otros, El paquete de gputools permite la computación de la GPU en R, BIOINFORMATICS, Vol. 26 no. 1 2010, páginas 134-135

En la sección experimental, en un ordenador de 4 núcleos, comparan el rendimiento del programa que se ejecuta en la GPU con el rendimiento sin la GPU. Escriben lo siguiente:

Elegimos usar un solo hilo del entorno R en nuestra prueba, ya que es la forma en que la mayoría de los usuarios interactúan con R.

Por lo tanto, los autores encuentran la línea de base ejecutando sus experimentos con un solo núcleo (ejecutado en serie).

Pero, las condiciones experimentales para el lado de la GPU no están claras (para mí). Cuando se utiliza una GPU, para la eficiencia debemos hacer uso simultáneamente de las CPU. Si los autores utilizaran las CPU restantes del ordenador (lo que sería sensato hacer en un algoritmo optimizado), entonces el aumento de la velocidad se basaría en CPU adicionales así como en GPU sobre la línea de base (y por lo tanto se inflaría artificialmente por un factor ligeramente inferior a 4).

¿Cómo debe interpretarse este experimento?

En particular, me gustaría saber si mi interpretación anterior es la correcta, y si es así, qué nos dice realmente este experimento.

Answer 1

Hay una diferencia fundamental entre la computación paralela en las CPU y las GPU. Esencialmente, el CPU ha sido diseñado para hacer cosas inteligentes en nombre del programador. Por ejemplo, Paralelismo del nivel de instrucción . El GPU por otro lado, elimina esta cosa útil y en su lugar contiene muchos más núcleos. Es un intercambio entre el procesador que te ayuda y el que te da más núcleos. Por lo tanto, para usar la GPU de manera efectiva, necesitas enviar tantos hilos (como la memoria lo permita). La razón de esto es porque la GPU no hace ninguna programación inteligente. Así que cuando solicita datos para un hilo, quieres tener otro en la cola de hilos esperando para hacerse cargo.

Ejemplo

Supongamos que tienes un for que quieres hacer en paralelo:

#f(i) does not depend on f(j)
#for any j != i
for(i in 1:100000)
    w[i] = f(i)

Puedes enviar N=1000000 hilos (repartidos en los núcleos de números) a la GPU. Ahora puedes pensar que podrías dejar que se hagan n hilos en la CPU multi-núcleo, pero:

1. Hay mucho equipaje de programación extra para, como mucho, poco beneficio. La programación de la GPU es dura (al menos eso creo), así que combinarla con CPUs multi-core es algo que quieres evitar.
2. La f(i) que se somete a la GPU tiende a ser una función muy simple, digamos la multiplicación de dos elementos de una matriz juntos.
3. Tendrás una penalización de tiempo si utilizas la GPU y la CPU juntas, ya que ambas tienen que preguntarse si han terminado.
4. Reduciendo el número de hilos utilizados en la GPU, se podría reducir fácilmente la eficiencia, es decir, ¡se tarda el mismo tiempo en realizar las operaciones de N-n que en las de N!

Por supuesto que hay situaciones en las que puede querer usar tanto la GPU como la CPU, pero normalmente no las usa para la misma operación.

---

Desafortunadamente, no tengo acceso al periódico en este momento. Está en mi (larga) lista de cosas para leer. Así que lo anterior es más una discusión general sobre la CPU y las GPU. Intentaré leerlo en uno o dos días.

Answer 2

Pero, las condiciones experimentales para el lado de la GPU no están claras (para mí). Cuando se utiliza una GPU, para la eficiencia debemos hacer uso simultáneamente de las CPU.

Eso no es cierto en general, y en particular no es cierto para el gputools Paquete R que ofrece un modo "todo a la GPU" con nuevas funciones gpuMatMult() , gpuQr() , gpuCor() etc. En otras palabras, le ofrece nuevas funciones que desplazan los cálculos completamente a la GPU.

Pero tu intuición es buena. Debería haber un modo mixto con operaciones híbridas entre la GPU y la CPU y el Magma La biblioteca pretende ofrecer precisamente eso. Mejor aún, la magma El paquete R lleva esto a R.

Además, tengo un papel de referencia / viñeta / pequeño paquete casi terminado que compara estos así como varios BLAS como Atlas, Goto y el MKL. Actualizaré esta entrada con una URL en un par de días.

Editado el 16 de septiembre : El documento que mencioné está ahora en el CRAN con su propio paquete gcbd Yo y yo escribimos un breve entrada en el blog sobre eso también.